This is the second post in the Policy-Based VPN series. In our first post we configured a policy-based VPN using security policies tied to the UNTRUST interface. For this post, we will be using a route-based configuration that allows interoperability to the remote side configured as a policy-based VPN. This will also allow us to define a dedicated security zone for the VPN, hence helping to increase security. What we will be using in this post are proxy IDs to define local and remote networks.
The first part of this post is the setup of the labs, just like we did last time. If you want, you can skip down to where we delete the old configuration to see how the new configuration is done.
To recap, there are four different VPN configurations in this series:
- Uni-directional policy-based VPN (1st post)
- Bi-directional policy-based VPN (1st post)
- IPSEC proxy-identity route-based (Covered in this post)
- IPSEC Traffic selectors route-based (Coming soon)
Again, I will be using Juniper vLabs IPSEC VPN Policy-based lab for these posts. Feel free to head on over there and spin the lab up yourself when you are ready and kick the tires on these different configurations. Below is our diagram for the lab topology.
Just like last time, we will only be looking at vSRX1 for our configurations and using the vMX to test our connectivity. To connect to the console on the devices, hover over the device and click on the down-arrow that appears and then select SSH. Once you do that you should have a new tab opened up that has the CLI of the SRX open.
Once you are connected, feel free to look around as this lab is preconfigured. Yet for the sake of this blog and learning, I would suggest that you just delete the security ike, IPsec, and policy sections entirely and re-create it with me. Please note that for this post we will also delete routing-options as we need to route the interesting traffic differently.
jcluser@vSRX1> edit
Entering configuration mode
[edit]
jcluser@vSRX1# delete security ike
[edit]
jcluser@vSRX1# delete security ipsec
[edit]
jcluser@vSRX1# delete security policies
[edit]
jcluser@vSRX1# delete routing-options
jcluser@vSRX1# commit
commit completeThe IKE and IPSEC information for this lab is as follows:
IKE:
main mode
proposal default
pre-shared key password
peer IP 10.100.12.2
IPSEC:
proposal default
Tunneled Networks:
local: 10.100.11.0/24
remote: 10.100.22.0/24So now we can create our IKE and IPSEC policies for this lab. We will use the same initial IKE and IPSEC policy as our last lab.
set security ike proposal IKE-PROP authentication-method pre-shared-keys
set security ike policy IKE-POL mode main
set security ike policy IKE-POL proposals IKE-PROP
set security ike policy IKE-POL pre-shared-key ascii-text password
set security ike gateway vSRX2 ike-policy IKE-POL
set security ike gateway vSRX2 address 10.100.12.2
set security ike gateway vSRX2 external-interface ge-0/0/1
set security ipsec proposal IPSEC-PROP
set security ipsec policy IPSEC-POL proposals IPSEC-PROP
set security ipsec vpn VPN-to-vSRX ike gateway vSRX2
set security ipsec vpn VPN-to-vSRX ike ipsec-policy IPSEC-POL
set security ipsec vpn VPN-to-vSRX establish-tunnels immediatelyHere is where things start to be different between policy-based and route-based. VPNs. We will need to use proxy-IDs for the tunnel.
Since we are not using a security policy with a tunnel action, we need to specify the proxy-id in the configuration. These are the interesting networks that are to be sent over the encrypted tunnel. Remember, these need to match exactly on both sides in order for the tunnels to come up.
This configuration is done under ipsec vpn [VPN-NAME] ike proxy-identity. The local keyword specifies the local subnet ( 10.100.11.0/24 ) and remote is the remote subnet ( 10.100.22.0/24 ).
set security ipsec vpn VPN-to-vSRX ike proxy-identity local 10.100.11.0/24
set security ipsec vpn VPN-to-vSRX ike proxy-identity remote 10.100.22.0/24Now that we have configured that, we need to also bind the VPN to an st (standard tunnel) interface. These all start at st0.x and are configured like any other interface in Junos. For this lab, we will just use st0.0.
set security ipsec vpn VPN-to-vSRX bind-interface st0.0You do not need to assign an IP address to the interface (you can if you want) yet you do need to configure it with family inet. If you do not configure family inet and try to pass traffic over it, you will go crazy trying to figure out what is wrong. Trust me – I know.
set interfaces st0 unit 0 family inetThe next step is to tell the SRX how to get to the remote network, here we will use a static route for the 10.100.22.0/24 subnet. We will point the route at the st0.0 interface (the interface bound for this VPN). If you used an IP address, you would set the next-hop to the interface IP.
set routing-options static route 10.100.22.0/24 next-hop st0.0Like the policy-based VPN, we do need to configure security policies as well as a security zone. You could place the st0.0 interface in the UNTRUST zone and use those policies if you wanted to, yet all the deployments I have seen, the st0.0 interfaces are placed in a dedicated VPN or common VPN zone. Common zones are used for same company VPNs whereas dedicated are usually Business to Business (B2B) VPNs. For this lab, we will create a dedicated VPN zone just for this traffic.
The first thing we need to do is create the zone and assign the st0.0 interface to that zone. Here we will use the VPN zone.
set security zones security-zone VPN interfaces st0.0As with any other Junos based zone-to-zone traffic, we need to create the appropriate security policies. For this lab that is trust to VPN and VPN to trust.
Now if you recall, the lab has some pre-configured address-books for the local and remote subnets (Site-A and Site-B). If you look at the configuration provided, you will see that Site-B is attached to the zone untrust.
set security address-book Site-A address Site-A-Net 10.100.11.0/24
set security address-book Site-A attach zone trust
set security address-book Site-B address Site-B-Net 10.100.22.0/24
set security address-book Site-B attach zone untrust
Since we are now going to access Site-B over a different zone, we will need to attach that address-book entry to the VPN zone as well.
set security address-book Site-B attach zone VPNNow we can configure our policy from the trust zone to the VPN zone. We will match our local subnet, remote subnet, and all traffic to keep it simple.
set security policies from-zone trust to-zone VPN policy PERMIT-ALL match source-address Site-A-Net
set security policies from-zone trust to-zone VPN policy PERMIT-ALL match destination-address Site-B-Net
set security policies from-zone trust to-zone VPN policy PERMIT-ALL match application any
set security policies from-zone trust to-zone VPN policy PERMIT-ALL then permitNow if we want to permit return traffic, we need to create another policy that is from the VPN zone to the trust zone.
set security policies from-zone VPN to-zone trust policy PERMIT-ALL match source-address Site-B-Net
set security policies from-zone VPN to-zone trust policy PERMIT-ALL match destination-address Site-A-Net
set security policies from-zone VPN to-zone trust policy PERMIT-ALL match application any
set security policies from-zone VPN to-zone trust policy PERMIT-ALL then permitOnce that is all committed, the VPN should establish and you should see a route for the 10.100.22.0/24 subnet in your inet.0 table
jcluser@vSRX1> show route 10.100.22.0
inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.22.0/24 *[Static/5] 00:48:25
to 10.100.12.2 via ge-0/0/1.0
> via st0.0
jcluser@vSRX1> Once we have the route confirmed, we can try and PING from vMX1
jcluser@Host1> ping 10.100.22.2 rapid
PING 10.100.22.2 (10.100.22.2): 56 data bytes
!!!!!
--- 10.100.22.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.324/2.014/3.659/0.843 ms
jcluser@Host1> Success! Now we can go look at our ike sa and ipsec sa.
jcluser@vSRX1> show security ike sa
Index State Initiator cookie Responder cookie Mode Remote Address
1108874 UP 7af171370e5b1695 a5a200361cf0520a Main 10.100.12.2
jcluser@vSRX1> show security ike security-associations detail
IKE peer 10.100.12.2, Index 1108874, Gateway Name: vSRX2
Role: Initiator, State: UP
Initiator cookie: 7af171370e5b1695, Responder cookie: a5a200361cf0520a
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 10.100.12.1:500, Remote: 10.100.12.2:500
<--- OUTPUT REMOVED TO MAKE IT EASIER TO READ --->
Local: 10.100.12.1:500, Remote: 10.100.12.2:500
Local identity: 10.100.12.1
Remote identity: 10.100.12.2As you can see from the IPSEC SA detail output, we show the local identities for the tunnel (10.100.11.0/24 and 10.100.22.0/24).
jcluser@vSRX1> show security ipsec sa
Total active tunnels: 1 Total Ipsec sas: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<131073 ESP:3des/sha1 5a61551e 3519/ unlim - root 500 10.100.12.2
>131073 ESP:3des/sha1 570b201 3519/ unlim - root 500 10.100.12.2
jcluser@vSRX1> show security ipsec sa detail
ID: 131073 Virtual-system: root, VPN Name: VPN-to-vSRX
Local Gateway: 10.100.12.1, Remote Gateway: 10.100.12.2
Local Identity: ipv4_subnet(any:0,[0..7]=10.100.11.0/24)
Remote Identity: ipv4_subnet(any:0,[0..7]=10.100.22.0/24)
Version: IKEv1
<--- OUTPUT REMOVED TO MAKE IT EASIER TO READ --->Now one nice thing with route-based VPNs is that it is easier to see the traffic over the VPN. Since we have a dedicated interface assigned to this VPN, we can check the flows on that interface and see what is going over the tunnel – here we have SSH traffic (port 22).
jcluser@vSRX1> show security flow session interface st0.0
Total sessions: 0
jcluser@vSRX1> show security flow session interface st0.0
Session ID: 80, Policy name: PERMIT-ALL/8, Timeout: 1796, Valid
In: 10.100.11.2/57448 --> 10.100.22.2/22;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 15, Bytes: 2733,
Out: 10.100.22.2/22 --> 10.100.11.2/57448;tcp, Conn Tag: 0x0, If: st0.0, Pkts: 11, Bytes: 2261,
Total sessions: 1If you have more then one interesting network that needs to go over the same IKE/IPSEC pair, you will need to create just ipsec vpn portion of the config for each subnet pair. While it will not work in this lab, the configuration for 10.100.111.0/24 and 10.100.222.0/24 would look like:
vpn VPN-to-vSRX-Tunnel-2 {
bind-interface st0.0;
ike {
gateway vSRX2;
proxy-identity {
local 10.100.111.0/24;
remote 10.100.222.0/24;
}
ipsec-policy IPSEC-POL;
}
}
routing-options {
static {
route 10.100.222.0/24 next-hop st0.0;
}
} The next post will cover the preferred way of configuring policy-based VPNs on Juniper, traffic-selectors.
The complete output for what this post covered is below.
security {
ike {
proposal IKE-PROP {
authentication-method pre-shared-keys;
}
policy IKE-POL {
mode main;
proposals IKE-PROP;
pre-shared-key ascii-text "$9$V.bgJGUHm5FjHBEyKx7jHq.PQ"; ## SECRET-DATA
}
gateway vSRX2 {
ike-policy IKE-POL;
address 10.100.12.2;
external-interface ge-0/0/1;
}
}
ipsec {
proposal IPSEC-PROP;
policy IPSEC-POL {
proposals IPSEC-PROP;
}
vpn VPN-to-vSRX {
bind-interface st0.0;
ike {
gateway vSRX2;
proxy-identity {
local 10.100.11.0/24;
remote 10.100.22.0/24;
}
ipsec-policy IPSEC-POL;
}
}
}
address-book {
Site-A {
address Site-A-Net 10.100.11.0/24;
attach {
zone trust;
}
}
Site-B {
address Site-B-Net 10.100.22.0/24;
attach {
zone untrust;
zone VPN;
}
}
}
policies {
from-zone trust to-zone VPN {
policy PERMIT-ALL {
match {
source-address Site-A-Net;
destination-address Site-B-Net;
application any;
}
then {
permit;
}
}
}
from-zone VPN to-zone trust {
policy PERMIT-ALL {
match {
source-address Site-B-Net;
destination-address Site-A-Net;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
ge-0/0/1.0;
}
}
security-zone VPN {
interfaces {
st0.0;
}
}
}
}
interfaces {
st0 {
unit 0 {
family inet;
}
}
}
routing-options {
static {
route 10.100.22.0/24 next-hop st0.0;
}
}