In this post I will show two flavours of configuring a LAN-to-LAN IPsec VPN tunnel with Juniper SRX: policy-based and route-based. I have been under impression that those ways are mutually exclusive so that only one way is valid for a given endpoint in the opposite side. How wrong have I been.
Here is the topology I am using.
In part 2 I will configure a bit more complicated scenario with two subnets in a site. Here I only have one subnet in each site.
Policy-based VPN
First, let’s set up a policy-based VPN tunnel. You will need to scroll the commands and outputs sideways to see all of the long lines. I’m only configuring the SRX210 on My Site. The SRX240 on Their Site has already been configured with policy-based VPN.
set security ike proposal IKE_SHA256_AES256_DH14 authentication-method pre-shared-keys set security ike proposal IKE_SHA256_AES256_DH14 dh-group group14 set security ike proposal IKE_SHA256_AES256_DH14 authentication-algorithm sha-256 set security ike proposal IKE_SHA256_AES256_DH14 encryption-algorithm aes-256-cbc set security ike proposal IKE_SHA256_AES256_DH14 lifetime-seconds 86400 set security ike policy TEST mode main set security ike policy TEST proposals IKE_SHA256_AES256_DH14 set security ike policy TEST pre-shared-key ascii-text myPassw0rd set security ike gateway GATEWAY_TEST ike-policy TEST set security ike gateway GATEWAY_TEST address 198.51.100.10 set security ike gateway GATEWAY_TEST external-interface fe-0/0/2.0 set security ipsec proposal IPSEC_SHA256_AES256_ESP protocol esp set security ipsec proposal IPSEC_SHA256_AES256_ESP authentication-algorithm hmac-sha-256-128 set security ipsec proposal IPSEC_SHA256_AES256_ESP encryption-algorithm aes-256-cbc set security ipsec proposal IPSEC_SHA256_AES256_ESP lifetime-seconds 3600 set security ipsec policy VPN_POLICY_SHA256_AES256_DH14 perfect-forward-secrecy keys group14 set security ipsec policy VPN_POLICY_SHA256_AES256_DH14 proposals IPSEC_SHA256_AES256_ESP set security ipsec vpn VPN_TEST df-bit clear set security ipsec vpn VPN_TEST ike gateway GATEWAY_TEST set security ipsec vpn VPN_TEST ike ipsec-policy VPN_POLICY_SHA256_AES256_DH14 set security ipsec vpn VPN_TEST establish-tunnels immediately set security address-book global address NET_172.21.1.0/24 172.21.1.0/24 set security address-book global address NET_10.30.1.0/24 10.30.1.0/24 set security zones security-zone UNTRUST interfaces fe-0/0/2.0 host-inbound-traffic system-services ike set security policies from-zone TRUST to-zone UNTRUST policy TEST_OUT match source-address NET_172.21.1.0/24 set security policies from-zone TRUST to-zone UNTRUST policy TEST_OUT match destination-address NET_10.30.1.0/24 set security policies from-zone TRUST to-zone UNTRUST policy TEST_OUT match application any set security policies from-zone TRUST to-zone UNTRUST policy TEST_OUT then permit tunnel ipsec-vpn VPN_TEST set security policies from-zone TRUST to-zone UNTRUST policy TEST_OUT then permit tunnel pair-policy TEST_IN set security policies from-zone UNTRUST to-zone TRUST policy TEST_IN match source-address NET_10.30.1.0/24 set security policies from-zone UNTRUST to-zone TRUST policy TEST_IN match destination-address NET_172.21.1.0/24 set security policies from-zone UNTRUST to-zone TRUST policy TEST_IN match application any set security policies from-zone UNTRUST to-zone TRUST policy TEST_IN then permit tunnel ipsec-vpn VPN_TEST set security policies from-zone UNTRUST to-zone TRUST policy TEST_IN then permit tunnel pair-policy TEST_OUT # Also note to disable source NAT for this traffic if you are running source NAT from # TRUST to UNTRUST as commonly is the case! set security nat source rule-set TRUST_TO_UNTRUST from zone TRUST set security nat source rule-set TRUST_TO_UNTRUST to zone UNTRUST set security nat source rule-set TRUST_TO_UNTRUST rule NO_NAT match source-address 172.21.1.0/24 set security nat source rule-set TRUST_TO_UNTRUST rule NO_NAT match destination-address 10.30.0.0/16 set security nat source rule-set TRUST_TO_UNTRUST rule NO_NAT then source-nat off
Note that you have to create matching “in” and “out” security policies for the pair-policy to function. This makes it cumbersome (if not impossible) to make strict control on which traffic to allow in and out of your site.
Also note that these security policies need to be listed before any other policies that match to the same flows because the security policies have first-match logic. Use the “insert” command if needed to reorder the policies.
The VPN tunnel is up and running:
markku@srx210> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 6185177 UP 3754a1c10b79ee42 9cf77c1c4598d9e7 Main 198.51.100.10 markku@srx210> show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <2 ESP:aes-cbc-256/sha256 2dae52f6 2878/ unlim - root 500 198.51.100.10 >2 ESP:aes-cbc-256/sha256 963e5b95 2878/ unlim - root 500 198.51.100.10 markku@srx210> show security ipsec security-associations detail ID: 2 Virtual-system: root, VPN Name: VPN_TEST Local Gateway: 203.0.113.2, Remote Gateway: 198.51.100.10 Local Identity: ipv4_subnet(any:0,[0..7]=172.21.1.0/24) Remote Identity: ipv4_subnet(any:0,[0..7]=10.30.1.0/24) Version: IKEv1 DF-bit: clear Policy-name: TEST_IN Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600829 Last Tunnel Down Reason: Delete payload received Direction: inbound, SPI: 2dae52f6, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2876 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2255 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64 Direction: outbound, SPI: 963e5b95, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2876 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2255 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64
and there is traffic going between the sites:
markku@testcomputer:~$ ping 10.30.1.24
PING 10.30.1.24 (10.30.1.24) 56(84) bytes of data.
64 bytes from 10.30.1.24: icmp_req=1 ttl=252 time=9.07 ms
64 bytes from 10.30.1.24: icmp_req=2 ttl=252 time=9.42 ms
64 bytes from 10.30.1.24: icmp_req=3 ttl=252 time=8.69 ms
Note the proxy identities in the IPsec output above: 172.21.1.0/24 (local) and 10.30.1.0/24 (remote). They were set automatically according to the security policies.
Route-based VPN
Now let’s modify the configuration to route-based VPN:
# VPN tunnel interface st0.1 is created: set interfaces st0 unit 1 description "VPN tunnel" set interfaces st0 unit 1 family inet # The tunnel interface is bound to the VPN: set security ipsec vpn VPN_TEST bind-interface st0.1 # The IPsec SA identities are set manually because there is no VPN policy anymore: set security ipsec vpn VPN_TEST ike proxy-identity local 172.21.1.0/24 set security ipsec vpn VPN_TEST ike proxy-identity remote 10.30.1.0/24 set security ipsec vpn VPN_TEST ike proxy-identity service any # A new security zone is created for the VPN (you could also use UNTRUST if wanted): set security zones security-zone VPN interfaces st0.1 # The old VPN policies are deleted: delete security policies from-zone TRUST to-zone UNTRUST policy TEST_OUT delete security policies from-zone UNTRUST to-zone TRUST policy TEST_IN # Access is permitted from TRUST to VPN: set security policies from-zone TRUST to-zone VPN policy VPN_OUT match source-address NET_172.21.1.0/24 set security policies from-zone TRUST to-zone VPN policy VPN_OUT match destination-address NET_10.30.1.0/24 set security policies from-zone TRUST to-zone VPN policy VPN_OUT match application any set security policies from-zone TRUST to-zone VPN policy VPN_OUT then permit # You can use whatever policies you like, inbound and outbound # In this case there is no access inbound from the VPN tunnel # The static route is set up for the remote site: set routing-options static route 10.30.1.0/24 next-hop st0.1
As the name implies, the routing decides which traffic will be encrypted, and the proxy identities will take care of assigning the correct IPsec SA in the VPN. Here are the status outputs:
markku@srx210> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 6185178 UP b03b9c7910e44843 d3f7a6485836c37f Main 198.51.100.10 markku@srx210> show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <131073 ESP:aes-cbc-256/sha256 870edae3 3426/ unlim - root 500 198.51.100.10 >131073 ESP:aes-cbc-256/sha256 8da31e98 3426/ unlim - root 500 198.51.100.10 markku@srx210> show security ipsec security-associations detail ID: 131073 Virtual-system: root, VPN Name: VPN_TEST Local Gateway: 203.0.113.2, Remote Gateway: 198.51.100.10 Local Identity: ipv4_subnet(any:0,[0..7]=172.21.1.0/24) Remote Identity: ipv4_subnet(any:0,[0..7]=10.30.1.0/24) Version: IKEv1 DF-bit: clear Bind-interface: st0.1 Port: 500, Nego#: 3, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 Last Tunnel Down Reason: Initial contact received Direction: inbound, SPI: 870edae3, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3424 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2841 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64 Direction: outbound, SPI: 8da31e98, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3424 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2841 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64 markku@srx210> show route 10.30.1.0/24 ... 10.30.1.0/24 *[Static/5] 00:04:28 > via st0.1 markku@srx210> show interfaces st0.1 terse Interface Admin Link Proto Local Remote st0.1 up up inet
I didn’t change anything on Their Site, the setup just worked right after committing the configuration.
In some testing scenarios I had to manually clear the security associations with “clear security ike security-associations” or “clear security ipsec security-associations” before the new configurations worked. Also, in some cases I had to deactivate and activate the VPN security policies for the SAs to come up after making lots of changes. I guess that was due to swapping between policy-based and route-based configurations, and the software didn’t like it every time.
Conclusions
As you can see, it is possible to implement the identical VPN tunnel in both ways.
For me the route-based VPN makes sense as it makes it possible to make more granular security policies. It also enables you to use dynamic routing between the sites and NAT for the tunneled traffic (not illustrated above).
In policy-based VPN the security policies affect the IPsec SAs and it may cause problems.
Note that for the route-based VPN you can select the SA identities freely with the “proxy-identity” statement, as long as you cross-match them between the tunnel endpoints.
If you have more than one tunneled network per site in the route-based VPN tunnel scenario (and there is something else than Juniper SRX in the other side) you will need to do more configurations. More about that in part 2.
The Junos versions in this example were 12.1X47-D15.4 (SRX210 on My Site) and 11.4R11.4 (SRX240 on Their Site).
Documentation for Junos 12.1X47 in juniper.net:
Markku, this is a very good tutorial! I am totally new to junos and vsrx…so I’d prefer if you could post the initial configuration of the interfaces.
I have two questions for you:
1)in the Route Based scenario you don’t setup or mention anywhere in your configuration the public ip of SRX240 (198.51.100.10) in order to speak to each other
2)(In the route based again) As you publish only the configuration of SRX210, I assume the same/similar configuration to the SRX240 in order to communicate -just with different ips? Correct? Site-to-Site is not something like speak-listen model….right?
If you so kind, could you please reply to the comment?
Hi Henry
1) In the route-based scenario in this post I only showed the modifications that were needed in the configuration, so the original IKE gateway configuration from the policy-based VPN is still present.
2) In the route-based scenario in this post SRX210 is using route-based configuration and SRX240 is still using the original policy-based configuration (“I didn’t change anything on Their Site, the setup just worked right after committing the configuration.”). This is a good demonstration that it is possible to get policy-based and route-based VPN configurations to cooperate. Either party can bring the IPsec tunnel up as the communication need arises. In these examples SRX210 was configured with “establish-tunnels immediately” however, so the tunnel is up right away.