This is the part 2 of my Juniper SRX IPsec LAN-to-LAN VPN posts. In part 1 we had a simple LAN-to-LAN VPN with only one subnet in each site. In this post we have two subnets in Their Site to illustrate the VPN configuration options.
Here is the topology for this post.
Their Site is already configured with a policy-based VPN with two security policy pairs: one pair for 172.21.1.0/24 <-> 10.30.1.0/24 and one pair for 172.21.1.0/24 <-> 10.30.2.0/24.
Policy-based VPN
Let’s first configure the policy-based VPN on My Site. To keep this post to the point I only show here the new configurations compared to the policy-based VPN in part 1, so check that out if needed.
set security address-book global address NET_10.30.2.0/24 10.30.2.0/24 set security policies from-zone TRUST to-zone UNTRUST policy TEST_2_OUT match source-address NET_172.21.1.0/24 set security policies from-zone TRUST to-zone UNTRUST policy TEST_2_OUT match destination-address NET_10.30.2.0/24 set security policies from-zone TRUST to-zone UNTRUST policy TEST_2_OUT match application any set security policies from-zone TRUST to-zone UNTRUST policy TEST_2_OUT then permit tunnel ipsec-vpn VPN_TEST set security policies from-zone TRUST to-zone UNTRUST policy TEST_2_OUT then permit tunnel pair-policy TEST_2_IN insert security policies from-zone TRUST to-zone UNTRUST policy TEST_2_OUT after policy TEST_OUT set security policies from-zone UNTRUST to-zone TRUST policy TEST_2_IN match source-address NET_10.30.2.0/24 set security policies from-zone UNTRUST to-zone TRUST policy TEST_2_IN match destination-address NET_172.21.1.0/24 set security policies from-zone UNTRUST to-zone TRUST policy TEST_2_IN match application any set security policies from-zone UNTRUST to-zone TRUST policy TEST_2_IN then permit tunnel ipsec-vpn VPN_TEST set security policies from-zone UNTRUST to-zone TRUST policy TEST_2_IN then permit tunnel pair-policy TEST_2_OUT insert security policies from-zone UNTRUST to-zone TRUST policy TEST_2_IN after policy TEST_IN
After these configurations there are two IPsec SAs up:
markku@srx210> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 6185192 UP 3150639546069bb2 c37a561409da1705 Main 198.51.100.10 markku@srx210> show security ipsec security-associations Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <2 ESP:aes-cbc-256/sha256 616334bf 2432/ unlim - root 500 198.51.100.10 >2 ESP:aes-cbc-256/sha256 baab14a6 2432/ unlim - root 500 198.51.100.10 <4 ESP:aes-cbc-256/sha256 bc430d5a 3439/ unlim - root 500 198.51.100.10 >4 ESP:aes-cbc-256/sha256 c0c66b2d 3439/ 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#: 3, Fail#: 0, Def-Del#: 0 Flag: 0x600829 Last Tunnel Down Reason: Delete payload received Direction: inbound, SPI: 616334bf, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2414 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 1776 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: baab14a6, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2414 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 1776 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 ID: 4 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.2.0/24) Version: IKEv1 DF-bit: clear Policy-name: TEST_2_IN Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600829 Last Tunnel Down Reason: SA config deactivated Direction: inbound, SPI: bc430d5a, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3421 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2835 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: c0c66b2d, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3421 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2835 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
Successful traffic:
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=8.80 ms 64 bytes from 10.30.1.24: icmp_req=2 ttl=252 time=8.81 ms ... markku@testcomputer:~$ ping 10.30.2.93 PING 10.30.2.93 (10.30.2.93) 56(84) bytes of data. 64 bytes from 10.30.2.93: icmp_req=2 ttl=61 time=8.06 ms 64 bytes from 10.30.2.93: icmp_req=3 ttl=61 time=9.08 ms
Route-based VPN
For route-based VPN we configured the proxy identities manually in part 1. However, it is not possible to set two different proxy identities for a single VPN with the “proxy-identity” statement. To be able to set up two different proxy identity combinations we need to create two different VPNs for these networks:
# Two VPN tunnel interfaces are created: set interfaces st0 unit 1 description "VPN tunnel for 10.30.1.0/24" set interfaces st0 unit 1 family inet set interfaces st0 unit 2 description "VPN tunnel for 10.30.2.0/24" set interfaces st0 unit 2 family inet # The tunnel interface st0.1 is bound to the first VPN: set security ipsec vpn VPN_TEST bind-interface st0.1 # The IPsec SA identities are set manually for the first VPN: 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 # The second VPN is created for the other subnet: set security ipsec vpn VPN_TEST_2 bind-interface st0.2 set security ipsec vpn VPN_TEST_2 df-bit clear set security ipsec vpn VPN_TEST_2 ike gateway GATEWAY_TEST set security ipsec vpn VPN_TEST_2 ike ipsec-policy VPN_POLICY_SHA256_AES256_DH14 set security ipsec vpn VPN_TEST_2 ike proxy-identity local 172.21.1.0/24 set security ipsec vpn VPN_TEST_2 ike proxy-identity remote 10.30.2.0/24 set security ipsec vpn VPN_TEST_2 ike proxy-identity service any set security ipsec vpn VPN_TEST_2 establish-tunnels immediately # So everything else is copied from VPN_TEST but the bind-interface and proxy-identity are changed # A new security zone is created for the VPN: set security zones security-zone VPN interfaces st0.1 set security zones security-zone VPN interfaces st0.2 # The old VPN policies are deleted: delete security policies from-zone TRUST to-zone UNTRUST policy TEST_OUT delete security policies from-zone TRUST to-zone UNTRUST policy TEST_2_OUT delete security policies from-zone UNTRUST to-zone TRUST policy TEST_IN delete security policies from-zone UNTRUST to-zone TRUST policy TEST_2_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 destination-address NET_10.30.2.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 # The static routes for the remote site, one route for each tunnel interface: set routing-options static route 10.30.1.0/24 next-hop st0.1 set routing-options static route 10.30.2.0/24 next-hop st0.2
To be sure what happened to the IPsec configuration, let’s show it:
markku@srx210# show security ipsec ... vpn VPN_TEST { bind-interface st0.1; df-bit clear; ike { gateway GATEWAY_TEST; proxy-identity { local 172.21.1.0/24; remote 10.30.1.0/24; service any; } ipsec-policy VPN_POLICY_SHA256_AES256_DH14; } establish-tunnels immediately; } vpn VPN_TEST_2 { bind-interface st0.2; df-bit clear; ike { gateway GATEWAY_TEST; proxy-identity { local 172.21.1.0/24; remote 10.30.2.0/24; service any; } ipsec-policy VPN_POLICY_SHA256_AES256_DH14; } establish-tunnels immediately; }
There they are, two VPN tunnels, one for both IPsec SAs.
Status of the VPN tunnels:
markku@srx210> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 6185192 UP 3150639546069bb2 c37a561409da1705 Main 198.51.100.10 markku@srx210> show security ipsec security-associations Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <131073 ESP:aes-cbc-256/sha256 3b01fb83 3323/ unlim - root 500 198.51.100.10 >131073 ESP:aes-cbc-256/sha256 bbb9810c 3323/ unlim - root 500 198.51.100.10 <131074 ESP:aes-cbc-256/sha256 26f45252 3323/ unlim - root 500 198.51.100.10 >131074 ESP:aes-cbc-256/sha256 6bf73d54 3323/ 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#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 Last Tunnel Down Reason: SA config deactivated Direction: inbound, SPI: 3b01fb83, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3321 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2697 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: bbb9810c, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3321 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2697 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 ID: 131074 Virtual-system: root, VPN Name: VPN_TEST_2 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.2.0/24) Version: IKEv1 DF-bit: clear Bind-interface: st0.2 Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 Last Tunnel Down Reason: SA not initiated Direction: inbound, SPI: 26f45252, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3321 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2699 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: 6bf73d54, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3321 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2699 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 *[Static/5] 00:04:46 > via st0.1 10.30.2.0/24 *[Static/5] 00:04:46 > via st0.2 markku@srx210> show interfaces terse Interface Admin Link Proto Local Remote ... st0.1 up up inet st0.2 up up inet
As you can see, this method of configuring the VPN tunnel does not scale very conveniently as you need separate VPN tunnels for each pair of source and destination networks in the LAN-to-LAN connection. For example, two networks in each site requires four VPNs to be configured for full reachability. Managing all those st0.x configurations requires additional work.
To overcome this configurational burden related to route-based VPNs Juniper added traffic selectors in Junos 12.1X46 for the branch SRX devices.
Route-based VPN with Traffic Selectors
The traffic selectors can be used instead of “proxy-identity” statements in the VPN configurations. With traffic selectors you get rid of the additional VPN tunnel interfaces.
Let’s replace our VPNs with the traffic selector configuration:
# First delete the second tunnel interface: delete interface st0.2 delete security zones security-zone VPN interfaces st0.2 # Delete the static routes (I'll explain it below): delete routing-options static route 10.30.1.0/24 delete routing-options static route 10.30.2.0/24 # Delete the second VPN tunnel configuration: delete security ipsec vpn VPN_TEST_2 # Delete the proxy-identity statements from the original VPN: delete security ipsec vpn VPN_TEST ike proxy-identity # Now configure two traffic selectors for the VPN: # First for 172.21.1.0/24 <-> 10.30.1.0/24 set security ipsec vpn VPN_TEST traffic-selector TS_1 local-ip 172.21.1.0/24 set security ipsec vpn VPN_TEST traffic-selector TS_1 remote-ip 10.30.1.0/24 # Second for 172.21.1.0/24 <-> 10.30.2.0/24 set security ipsec vpn VPN_TEST traffic-selector TS_2 local-ip 172.21.1.0/24 set security ipsec vpn VPN_TEST traffic-selector TS_2 remote-ip 10.30.2.0/24
Here is the new IPsec configuration to be clear:
markku@srx210# show security ipsec
...
vpn VPN_TEST {
bind-interface st0.1;
df-bit clear;
ike {
gateway GATEWAY_TEST;
ipsec-policy VPN_POLICY_SHA256_AES256_DH14;
}
traffic-selector TS_1 {
local-ip 172.21.1.0/24;
remote-ip 10.30.1.0/24;
}
traffic-selector TS_2 {
local-ip 172.21.1.0/24;
remote-ip 10.30.2.0/24;
}
establish-tunnels immediately;
}
Let’s see the VPN status:
markku@srx210> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 6185192 UP 3150639546069bb2 c37a561409da1705 Main 198.51.100.10 markku@srx210> show security ipsec security-associations Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <268173313 ESP:aes-cbc-256/sha256 4dbc28de 3213/ unlim - root 500 198.51.100.10 >268173313 ESP:aes-cbc-256/sha256 3a566364 3213/ unlim - root 500 198.51.100.10 <268173314 ESP:aes-cbc-256/sha256 74a8ca33 3281/ unlim - root 500 198.51.100.10 >268173314 ESP:aes-cbc-256/sha256 3e26f77c 3281/ unlim - root 500 198.51.100.10 markku@srx210> show security ipsec security-associations detail ID: 268173313 Virtual-system: root, VPN Name: VPN_TEST Local Gateway: 203.0.113.2, Remote Gateway: 198.51.100.10 Traffic Selector Name: TS_1 Local Identity: ipv4(172.21.1.0-172.21.1.255) Remote Identity: ipv4(10.30.1.0-10.30.1.255) Version: IKEv1 DF-bit: clear Bind-interface: st0.1 Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x2c608b29 Last Tunnel Down Reason: SA config deactivated Direction: inbound, SPI: 4dbc28de, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3211 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2585 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: 3a566364, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3211 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2585 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 ID: 268173314 Virtual-system: root, VPN Name: VPN_TEST Local Gateway: 203.0.113.2, Remote Gateway: 198.51.100.10 Traffic Selector Name: TS_2 Local Identity: ipv4(172.21.1.0-172.21.1.255) Remote Identity: ipv4(10.30.2.0-10.30.2.255) Version: IKEv1 DF-bit: clear Bind-interface: st0.1 Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x2c608b29 Last Tunnel Down Reason: SA config deactivated Direction: inbound, SPI: 74a8ca33, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3279 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2641 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: 3e26f77c, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 3279 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2641 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 *[Static/5] 00:06:33 > via st0.1 10.30.2.0/24 *[Static/5] 00:05:25 > via st0.1
Looks good, there are two IPsec SAs, created with the traffic selectors. Proof:
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.37 ms 64 bytes from 10.30.1.24: icmp_req=2 ttl=252 time=9.04 ms ... markku@testcomputer:~$ ping 10.30.2.93 PING 10.30.2.93 (10.30.2.93) 56(84) bytes of data. 64 bytes from 10.30.2.93: icmp_req=1 ttl=61 time=8.16 ms 64 bytes from 10.30.2.93: icmp_req=2 ttl=61 time=9.10 ms
An interesting detail about the traffic selectors is that the static routes to the other site are added automatically. This is especially convenient as that removes one step to remember when configuring a VPN connection. In the “show route” output above the timestamps are different because I first added only the traffic selector TS_1, and then added TS_2 a minute later.
Conclusions
For me the route-based VPN with traffic selectors is the way to configure VPN tunnels on Juniper SRX when Junos 12.1X46 or newer is available.
One more detail: If you are configuring VPN between two Juniper SRX devices you can also just set up one static “proxy-identity” pair between the devices, regardless of the number of subnets you have on each site. The devices will then happily negotiate the SA and use it for whatever traffic you throw at the tunnel. Just cross-match the proxy identities between the devices and you are fine.
More information about the traffic selectors in juniper.net:
- Understanding Traffic Selectors in Route-Based VPNs (Junos 12.1X47)
- Understanding Reverse Route Insertion (Junos 12.1X47)
- Junos OS Release Notes 12.1X46
hello .for you first solution . could you share the confiugration on SRX240 .
if you also create st0.1, st0.2 on SRX 240. how do you configure route for 172.21.1.0/24. nexthop is st0.1 or st0.2 . thanks
Hi caulfiedd, as mentioned in part 1 of the posting, there was a policy-based VPN configuration on SRX240, so there were no st0.x interfaces present.
Hello,
some remarks :
1) traffic-selector is a good thing as far as you don’t use IKEV2 :
see https://www.juniper.net/documentation/en_US/junos12.1×47/topics/concept/ipsec-vpn-traffic-selector-understanding.html :
“Traffic selectors cannot be configured with the following features: IKE version 2”
2) it would be simpler if Juniper allowed to code group name (address-set) in the local/remote proxy (as CISCO does in Crypto map) and as it is now possible to do in to NAT source and dest via source-address-name
3) in some cases, either because IKEV2 is used or because the number of local and remote subnets results into an important number of local/remote pairs of addresses (even if it is simpler/shorter with traffic selector), it might be better to create a Policy-based VPN where you don’t have to care about coding those pairs ;
the only question about this Policy-based VPN is related to the fact that, if you have multiple sources or dest or address-sets coded in some Policy rules, the following Juniper document indicates that the resulting generated Proxy Id (Local and Remote) will be 0.0.0.0 :
see https://kb.juniper.net/InfoCenter/index?page=content&id=KB29364&actp=RSS at the last section “Policy using multi-cell address objects”
In such a case, the question is to know how will the VPN peer box (at the other side of the tunnel, which can be of any kind, not only Juniper) react ? will it reject those 0.0.0.0 Proxy Ids if they are coded with the concerned real subnets on its side or will it allow them ?
Any idea is welcome
Hi celtic_rasta, thanks for commenting. You are correct, with IKEv2 you cannot use traffic selectors. When I implemented a VPN tunnel from SRX to Microsoft Azure Virtual network gateway with IKEv2, I used route-based VPN, left out the traffic selectors, and used static routes to the VPN tunnel interface (10.12.34.0/24 next-hop st0.99). As far as I remember right now, the proxy IDs were just 0.0.0.0 on SRX, meaning that it would crypt whatever traffic was routed to the interface.