SRX

Hello experts,

I have the following scenarios related to SRX implementation of traffic selectors vs proxy identities. I am running this experiment using vSRX 12.1X47-D15.4. I am using IKEv1 as for this version only IKEv1 supports multiple traffic selectors and proxy identities. 

I have two route-based site-to-site VPN tunnels using ESP. Both endpoints are SRX running same OS. 
The encrypted traffic is as follows.

VPN1: 100.100.100.250/32 <-> 10.10.10.101/32

VPN2: 100.100.100.250/32 <-> 10.10.10.102/32

Each VPN has its own st0 tunnel interface. I have experimented two scenarios for each of the VPNs, one using proxy identities and other one using traffic selectors. 

Scenario 1: Proxy Identities on both ends.

SRX1:

set security ipsec vpn IPSEC_VPN1 bind-interface st0.101
set security ipsec vpn IPSEC_VPN1 df-bit copy
set security ipsec vpn IPSEC_VPN1 ike gateway IKE_GW
set security ipsec vpn IPSEC_VPN1 ike proxy-identity local 100.100.100.250/32
set security ipsec vpn IPSEC_VPN1 ike proxy-identity remote 10.10.10.101/32
set security ipsec vpn IPSEC_VPN1 ike ipsec-policy IPSEC_POL
set security ipsec vpn IPSEC_VPN2 bind-interface st0.102
set security ipsec vpn IPSEC_VPN2 df-bit copy
set security ipsec vpn IPSEC_VPN2 ike gateway IKE_GW
set security ipsec vpn IPSEC_VPN2 ike proxy-identity local 100.100.100.250/32
set security ipsec vpn IPSEC_VPN2 ike proxy-identity remote 10.10.10.102/32
set security ipsec vpn IPSEC_VPN2 ike ipsec-policy IPSEC_POL

root@SRX1> show route 10.10.10.101/32
10.10.10.101/32    *[Static/5] 1d 01:22:09
                    > via st0.101
root@S2> show route 10.10.10.102/32
10.10.10.102/32    *[Static/5] 01:09:18
                    > via st0.102
root@SRX1> 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 2a1b4e14 824/ unlim - root 500 10.10.34.4
>131073 ESP:aes-cbc-256/sha256 8e50e421 824/ unlim - root 500 10.10.34.4
<131074 ESP:aes-cbc-256/sha256 76639d3 830/ unlim - root 500 10.10.34.4
>131074 ESP:aes-cbc-256/sha256 efc0e472 830/ unlim - root 500 10.10.34.4

SRX2:

set security ipsec vpn IPSEC_VPN1 bind-interface st0.1
set security ipsec vpn IPSEC_VPN1 ike gateway IKE_GW
set security ipsec vpn IPSEC_VPN1 ike proxy-identity local 10.10.10.101/32
set security ipsec vpn IPSEC_VPN1 ike proxy-identity remote 100.100.100.250/32
set security ipsec vpn IPSEC_VPN1 ike ipsec-policy IPSEC_POL
set security ipsec vpn IPSEC_VPN2 bind-interface st0.2
set security ipsec vpn IPSEC_VPN2 ike gateway IKE_GW
set security ipsec vpn IPSEC_VPN2 ike proxy-identity local 10.10.10.102/32
set security ipsec vpn IPSEC_VPN2 ike proxy-identity remote 100.100.100.250/32
set security ipsec vpn IPSEC_VPN2 ike ipsec-policy IPSEC_POL

root@SRX2> show route 100.100.100.250/32
100.100.100.250/32 *[Static/5] 00:39:40
                    > via st0.1
                      via st0.2
root@SRX2> 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 8e50e421 816/ unlim - root 500 10.10.23.2
>131073 ESP:aes-cbc-256/sha256 2a1b4e14 816/ unlim - root 500 10.10.23.2
<131074 ESP:aes-cbc-256/sha256 efc0e472 822/ unlim - root 500 10.10.23.2
>131074 ESP:aes-cbc-256/sha256 76639d3 822/ unlim - root 500 10.10.23.2

The results is that ping is working both from 100.100.100.250 to 10.10.10.101 and to 10.10.10.102. Ignore the source IP addresses on the router. Both 10.10.10.1 and 10.10.10.2 are PATed to 100.100.100.250 on SRX1. SRX1 is the one initiating the traffic. 

R1#ping 10.10.10.101 source 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.101, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/15/20 ms
R1#ping 10.10.10.102 source 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.102, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 13/19/26 ms

Scenario 2: Proxy identity on SRX1 and Traffic Selectors on SRX2

The configuration on SRX1 remains the same as above. The configuration SRX2 has been changed to include traffic selectors and is now also using ARI.

set security ipsec vpn IPSEC_VPN1 bind-interface st0.1
set security ipsec vpn IPSEC_VPN1 ike gateway IKE_GW
set security ipsec vpn IPSEC_VPN1 ike ipsec-policy IPSEC_POL
set security ipsec vpn IPSEC_VPN1 traffic-selector TS1 local-ip 10.10.10.101/32
set security ipsec vpn IPSEC_VPN1 traffic-selector TS1 remote-ip 100.100.100.250/32
set security ipsec vpn IPSEC_VPN2 bind-interface st0.2
set security ipsec vpn IPSEC_VPN2 ike gateway IKE_GW
set security ipsec vpn IPSEC_VPN2 ike ipsec-policy IPSEC_POL
set security ipsec vpn IPSEC_VPN2 traffic-selector TS2 local-ip 10.10.10.102/32
set security ipsec vpn IPSEC_VPN2 traffic-selector TS2 remote-ip 100.100.100.250/32

root@SRX2> show security ipsec security-associations
Total active tunnels: 2
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<268173315 ESP:aes-cbc-256/sha256 13b8f1bb 3582/ unlim - root 500 10.10.23.2
>268173315 ESP:aes-cbc-256/sha256 6313a8a5 3582/ unlim - root 500 10.10.23.2
<268173316 ESP:aes-cbc-256/sha256 6230bb09 3586/ unlim - root 500 10.10.23.2
>268173316 ESP:aes-cbc-256/sha256 6ef6e192 3586/ unlim - root 500 10.10.23.2

root@SRX2> show route 100.100.100.250/32

inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100.100.100.250/32 *[Static/5] 00:03:21
                    > via st0.1
                    [Static/5] 00:03:21
                    > via st0.2
                    [Static/5] 00:57:22
                    > via st0.1
                      via st0.2

The IPsec SA's are up on both ends same as before. St0.1 is the preffered interface on SRX2 same as before. The only difference now is that the encrypted traffic is not working for VPN2.

R1#ping 10.10.10.101 source 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.101, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 18/22/37 ms
R1#ping 10.10.10.102 source 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.102, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.2
.....
Success rate is 0 percent (0/5)
R1#

 I know that Juniper explicitly says that this scenario is not supported.
https://www.juniper.net/documentation/en_US/junos12.1x46/topics/concept/ipsec-vpn-traffic-selector-overlapping-ip-address-understanding.html#jd0e58

My question is why traffic for VPN2 not working in the second scenario and it is working in the first ? I'm explicitly asking about the mechanism behind the scenes, so to speak. Does the traffic selector knob also use some sort of data plane filtering for the source and destination IPs which is not the case for the proxy ID ? 

 Using packet captures I can see that traffic in scenario 2 is egressing from the SRX2 device. It is the return traffic from SRX2 that is having an issue. Furthermore, since both routing and the IPsec SA are up in both scenario 1 and scenario 2, I suspect this is a dataplane issue and not a control plane issue (my suspicion is some sort of traffic filtering). Are there any show commands or traceoptions for me to view this ? 

Yes, There is an additional filtering/check when using traffic selectors. When traffic selector is used, only the traffic matches the configured traffic selector is permitted through that tunnel. 

In this case on SRX2, 100.100.100.250 is reachble via st0.1 interface as it is the selected active route and hence the return traffic from 10.10.10.102/32 will go via st0.1 interface. But as per the configured traffic selector, traffic from 10.10.10.101/32 is only permitted via st0.1 interface. So the return traffic will be dropped. This additional check is not there when you use proxy identity. 

You can verify this behavior using flow trace. 

set security flow traceoptions file vpnflow.log
set security flow traceoptions file size 20m
set security flow traceoptions file files 20
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter temp1 source-prefix 100.100.100.250/32
set security flow traceoptions packet-filter temp1 destination-prefix 10.10.10.102/32
set security flow traceoptions packet-filter temp2 source-prefix 10.10.10.102/32
set security flow traceoptions packet-filter temp2 destination-prefix 100.100.100.250

Hello Nellikka,

Indeed you are correct. I have configuted flow tracing on SRX2 and I have run 1 ICMP echo request from 100.100.100.250 -> 10.10.10.101 and 1 ICMP echo request from 100.100.100.250 -> 10.10.10.102 with traffic-selectors configured on SRX2. Traceoptions attached.

For the traffic from 100.100.100.250 -> 10.10.10.102:

Indeed it is egressing out of st0.2 and is accepted.

Dec 24 06:53:21 06:53:21.547165:CID-0:RT:flow_process_pkt_exception: setting rtt in lpak to 0x5d1c8530

Dec 24 06:53:21 06:53:21.547170:CID-0:RT:host inq check inq_type 0x6

Dec 24 06:53:21 06:53:21.547172:CID-0:RT:tifp st0.2

Dec 24 06:53:21 06:53:21.547175:CID-0:RT:pkt out of tunnel.Proceed normally

Dec 24 06:53:21 06:53:21.547176:CID-0:RT: st0.2:100.100.100.250->10.10.10.102, icmp, (8/0)

However, the issue is that the return traffic is trying to ingress via the st0.1 interface, for which the traffic selector indeed does not match. 

Dec 24 06:53:21 06:53:21.554742:CID-0:RT:flow_ipv4_rt_lkup success 100.100.100.250, iifl 0x0, oifl 0x45

Dec 24 06:53:21 06:53:21.554744:CID-0:RT: handle reroute for tunnel 0

Dec 24 06:53:21 06:53:21.554747:CID-0:RT: Doing IPSec traffic-selector match for 100.100.100.250 -> 10.10.10.102

Dec 24 06:53:21 06:53:21.554752:CID-0:RT: Error occured while finding nsp_tunnel for st0-ifp st0.1

Dec 24 06:53:21 06:53:21.554753:CID-0:RT: get_nsp_tunnel - Tunnel not found. if st0.1, nexthop ip 0xfa646464, policy id 0

Dec 24 06:53:21 06:53:21.554754:CID-0:RT:
dynamic route to tunnel if st0.1, but tunnel is not ready.

Dec 24 06:53:21 06:53:21.554757:CID-0:RT: packet dropped, pak dropped since re-route failed

Dec 24 06:53:21 06:53:21.554761:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

It's curious that Juniper documentation regarding is not mentioning this explicitly as this is a rather important caveat. I was under the impression that the traffic selector and proxy identity knobs serve the same purpose, the only difference being that they are configured on different stanza's and proxy identities have a limitation of being one per VPN. I was not aware of the source and destination address checks that were done for traffic selectors. 

Attachment(s)

10.10.10.102_Flow_Trace_Discard.txt   10 KB 1 version

10.10.10.101_Flow_Trace_Permit.txt   10 KB 1 version

After doing the simulations in the GNS3, I found a KB mentioning this explictly.
https://kb.juniper.net/InfoCenter/index?page=content&id=KB28787

CAUSE:

SOLUTION: