This is the third and final 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. In our second post we used IPSec proxy-ids to define the tunneled traffic. This post will be covering the preferred method of Juniper policy-based VPNs, traffic-selectors.
The first part of this post is the setup of the labs, just like we did in the last post. 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 (2nd post).
- IPSEC Traffic selectors route-based (This post).
Like last time, I will be using Juniper vLabs IPSEC VPN Policy-based lab for this post. 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. For this lab, we will be using traffic-selectors to define the interesting traffic. They are configured very much like the proxy-identities are.
Like with the proxy identity, we need to bind an interface to our VPN, as well as define our local and remote networks. Again we will use st0.0 as our bind interface. After that we can configure our traffic-selector, here called NET-1, with our local and remote ip specified.
set security ipsec vpn VPN-to-vSRX bind-interface st0.0
set security ipsec vpn VPN-to-vSRX traffic-selector NET-1 local-ip 10.100.11.0/24
set security ipsec vpn VPN-to-vSRX traffic-selector NET-1 remote-ip 10.100.22.0/24
Now we can quickly configure our st0.0 interface – remember we need to assign family inet to the interface or we won’t be able to pass traffic.
set interfaces st0 unit 0 family inetNow we need to assign the interface to a security zone. Like I mentioned in my last post, all the deployemets I have seen have the st0.0 Biz-to-Biz interfaces placed in their own security zone to keep security policies straight and simple.
set security zones security-zone VPN interfaces st0.0If you recall, the address book for Site-B is already configured, we just need to attach it to the VPN zone.
set security address-book Site-B attach zone VPNOnce attached to the zone, we can create our normal security policies.
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 permit
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 permit
Now we should be able to ping across.
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.025/1.400/2.183/0.411 msIf you noticed, we did not configure a static route for this traffic, yet we are routing over the VPN. This is because the static route is automatically created for the traffic over the tunnel when the VPN is up.
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:23:03
> via st0.0Now if you want to re-advertise this connection to remote sites via BGP, OSPF, etc, you could create a static route pointing to the st0.0 interface and redistribute the static route.
set routing-options static route 10.100.22.0/24 next-hop st0.0 Another perk with Traffic-Selector is that it shows up in the IPSEC SA. If you look at the SA below, you can see the Traffic Selector Name: NET-1. This can be helpful when you need to troubleshoot a VPN.
jcluser@vSRX1> show security ipsec sa detail
ID: 67108866 Virtual-system: root, VPN Name: VPN-to-vSRX
Local Gateway: 10.100.12.1, Remote Gateway: 10.100.12.2
Traffic Selector Name: NET-1
Local Identity: ipv4(10.100.11.0-10.100.11.255)
Remote Identity: ipv4(10.100.22.0-10.100.22.255)
Version: IKEv1The configuration we just did 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$8knL-wY2aUi.4a9pBEeK4aZGDk"; ## 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;
ipsec-policy IPSEC-POL;
}
traffic-selector NET-1 {
local-ip 10.100.11.0/24;
remote-ip 10.100.22.0/24;
}
establish-tunnels immediately;
}
}
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;
}
}