Policy-based VPNs are a pain most of the time, especially when compared to route-based VPNs. Many of the policy-based VPNs I run across today are legacy configurations dealing with ASA or interop between vendors where the one side only supported policy-based VPNs.
With Junos, there are four ways to configure VPNs to support policy-based VPN requirements. Two are a true policy-based VPN and the other two are actually route-based VPNs that support policy-based VPNs.
The four different VPN configuration options are:
- Uni-directional policy-based VPN (Covered in this post)
- Bi-directional policy-based VPN (Covered in this post at the end)
- IPSEC proxy-identity route-based (Coming soon)
- IPSEC Traffic selectors route-based (Coming soon)
There will be four posts in this series. The first post will cover the first two items listed above, the second will cover proxy-identity, the third will cover traffic-selectors, and the last post will be a wrap-up recap with pros and caveats to each option.
I will be using Juniper vLabs IPSEC VPN Policy-based lab for all these posts. We will only be working with one SRX to emulate what setting up a VPN would really be like. 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.
For the unidirectional lab, 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.
jcluser@vSRX1> edit
Entering configuration mode
[edit]
jcluser@vSRX1# delete security ike
[edit]
jcluser@vSRX1# delete security ipsec
[edit]
jcluser@vSRX1# delete security policies
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 our first step here will be to create our IKE and IPsec policies. First, we will configure our IKE proposal, policy, and gateway configuration.
Configure our IKE proposal to use pre-shared keys
set security ike proposal IKE-PROP authentication-method pre-shared-keysConfigure our policy for mode main, reference our proposal, and set the pre-shared key to password.
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 passwordNow we configure our IKE peer gateway connection using our IKE policy, external interface, and peer address.
set security ike gateway IKE-GW ike-policy IKE-POL
set security ike gateway IKE-GW address 10.100.12.2
set security ike gateway IKE-GW external-interface ge-0/0/1Now we can configure our IPSEC proposal, policy, and VPN connection.
Configure our IPSEC proposal
set security ipsec proposal IPSEC-PROPConfigure our IPSEC policy to reference our proposal
set security ipsec policy IPSEC-POL proposals IPSEC-PROPConfigure our VPN referencing our IKE-GW, IPSEC policy and have it establish tunnels on-traffic. You could also do establish-tunnels immediately if you did not want to wait for traffic to initiate.
set security ipsec vpn VPN-to-vSRX ike gateway IKE-GW
set security ipsec vpn VPN-TO-vSRX ike ipsec-policy IPSEC-POL
set security ipsec vpn VPN-TO-vSRX establish-tunnels on-trafficBelow is what our IKE and IPSEC stanzas currently look like.
security {
ike {
proposal IKE-PROP {
authentication-method pre-shared-keys;
}
policy IKE-POL {
mode main;
proposals IKE-PROP;
pre-shared-key ascii-text "$9$E9ahlM8LNbYoxNmT39OBxNdVwg"; ## SECRET-DATA
}
gateway IKE-GW {
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 {
ike {
gateway IKE-GW;
ipsec-policy IPSEC-POL;
}
establish-tunnels on-traffic;
}
}
}Once we have that we can now configure our uni-directional VPN policies. These are configured under the security policies and use a then permit tunnel option to specify the tunnel IPSEC VPN. Please note that the address-books have been pre-configured on the devices for this lab and we will reference these for our policies.
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 untrustNow we can configure a policy that matches our subnet (Site-A) and the remote subnet (Site-B) and permit any application.
set security policies from-zone trust to-zone untrust policy VPN-OUT match source-address Site-A-Net
set security policies from-zone trust to-zone untrust policy VPN-OUT match destination-address Site-B-Net
set security policies from-zone trust to-zone untrust policy VPN-OUT match application anyNow for the permit portion of the policy, we will specify that the permit action is to tunnel the traffic using VPN-TO-vSRX that we configured before.
set security policies from-zone trust to-zone untrust policy VPN-OUT then permit tunnel ipsec-vpn VPN-TO-vSRXNow we can go to vMX1 and test ping to vMX2 (10.100.22.2).
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.266/1.501/1.890/0.212 msAs you can see we can ping the remote side!
Now, if we want to allow the remote side to be initiate and ping our vMX, we would need to create a return policy. As you can see we are currently unable to ping vMX1 from vMX2.
jcluser@Host2> ping 10.100.11.2 rapid
PING 10.100.11.2 (10.100.11.2): 56 data bytes
.....
--- 10.100.11.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
jcluser@Host2> For this policy, we need to allow it from untrust to trust and set the permit action to tunnel ipsec-vpn.
set security policies from-zone untrust to-zone trust policy VPN-IN match source-address Site-B-Net
set security policies from-zone untrust to-zone trust policy VPN-IN match destination-address Site-A-Net
set security policies from-zone untrust to-zone trust policy VPN-IN match application any
set security policies from-zone untrust to-zone trust policy VPN-IN then permit tunnel ipsec-vpn VPN-TO-vSRXAnd once we do that we should be able to ping vMX1 from vMX2.
jcluser@Host2> ping 10.100.11.2 rapid
PING 10.100.11.2 (10.100.11.2): 56 data bytes
!!!!!
--- 10.100.11.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.065/1.337/1.709/0.235 msIf you want to check to make sure IKE and IPSEC are up, you can use the commands show security ike sa and show security ipsec sa.
jcluser@vSRX1> show security ike sa
Index State Initiator cookie Responder cookie Mode Remote Address
5525802 UP b2320fe37d997102 74e3e18c614bbfd0 Main 10.100.12.2
jcluser@vSRX1> show security ipsec sa
Total active tunnels: 1 Total Ipsec sas: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<2 ESP:3des/sha1 50932b85 3478/ unlim - root 500 10.100.12.2
>2 ESP:3des/sha1 29c7f7a6 3478/ unlim - root 500 10.100.12.2 The full security configuration stanza is below.
ike {
proposal IKE-PROP {
authentication-method pre-shared-keys;
}
policy IKE-POL {
mode main;
proposals IKE-PROP;
pre-shared-key ascii-text "$9$E9ahlM8LNbYoxNmT39OBxNdVwg"; ## SECRET-DATA
}
gateway IKE-GW {
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 {
ike {
gateway IKE-GW;
ipsec-policy IPSEC-POL;
}
establish-tunnels on-traffic;
}
}
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;
}
}
}
policies {
from-zone trust to-zone untrust {
policy VPN-OUT {
match {
source-address Site-A-Net;
application any;
}
then {
permit {
tunnel {
ipsec-vpn VPN-TO-vSRX;
}
}
}
}
}
}
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;
}
}
}
An alternate way to configure this same policy would be to add a term to the security policy called pair-policy. This term is used to help reduce the number of proxy ids on a tunnel as it allows the SRX to combine the pair together (see this Juniper link for more info).
For the policy, each one references the other as seen below. The VPN-OUT has a pair-policy of VPN-IN, and VPN-IN has a pair-policy of VPN-OUT.
set security policies from-zone trust to-zone untrust policy VPN-OUT then permit tunnel pair-policy VPN-IN
set security policies from-zone untrust to-zone trust policy VPN-IN then permit tunnel pair-policy VPN-OUT
The complete stanza configuration for this is below
jcluser@vSRX1> show configuration security policies
from-zone trust to-zone untrust {
policy VPN-OUT {
match {
source-address Site-A-Net;
destination-address Site-B-Net;
application any;
}
then {
permit {
tunnel {
ipsec-vpn VPN-TO-vSRX;
pair-policy VPN-IN;
}
}
}
}
}
from-zone untrust to-zone trust {
policy VPN-IN {
match {
source-address Site-B-Net;
destination-address Site-A-Net;
application any;
}
then {
permit {
tunnel {
ipsec-vpn VPN-TO-vSRX;
pair-policy VPN-OUT;
}
}
}
}
}