Hello, I have just added an use case over at https://wiki.fd.io/view/VPP/IPSec_and_IKEv2#IPSec_between_VPP_peers.2C_tunneling_IPv4_over_IPv6
It is pretty bare bones for now, but I hope to continue to improve it. Feel free to point out mistakes if there are any. I also will try to write a longer version explaining more things (more like capturing what neale explained to me) with traces in the VPP user docs. Thanks Neale, Filip and everyone. On Fri, May 15, 2020 at 3:11 PM Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > Hi Muthu, > > > > *From: *<vpp-dev@lists.fd.io> on behalf of Muthu Raj < > muthuraj.muth...@gmail.com> > *Date: *Friday 15 May 2020 at 09:20 > *To: *"Neale Ranns (nranns)" <nra...@cisco.com> > *Cc: *"Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco)" < > fteh...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > *Subject: *Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hi Neale, > > > > Sorry about the trace. > > > > Not your fault at all 😊 I was commenting that the trace VPP produced was > not clear in indicating the miss. > > > > The match in the SPD is against SA 20’s tunnel addresses not the policy’s > local/remote range. > > > > Thanks for clarifying this. I was confused here. > > > > I created the SA and policy with this in mind and got it to work > successfully. > > Thanks a lot for your help. > > > > Glad to hear it. > > > > I will spend some time this coming week and try to get a small write up > onto https://wiki.fd.io/ > > It may be of help to someone. > > > > I’m sure it will be. Thanks you! > > > > /neale > > > > Muthu > > > > On Thu, May 14, 2020 at 8:52 PM Neale Ranns (nranns) <nra...@cisco.com> > wrote: > > > > Hi Muthu, > > > > The tracing is not great, but what you see indicates a miss in the SPD. > > The match in the SPD is against SA 20’s tunnel addresses not the policy’s > local/remote range. > > > > /neale > > > > > > *From: *Muthu Raj <muthuraj.muth...@gmail.com> > *Date: *Thursday 14 May 2020 at 15:51 > *To: *"muthuraj.muth...@gmail.com" <muthuraj.muth...@gmail.com> > *Cc: *"Neale Ranns (nranns)" <nra...@cisco.com>, "Filip Tehlar -X > (ftehlar - PANTHEON TECH SRO at Cisco)" <fteh...@cisco.com>, " > vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > *Subject: *Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hi Neale, > > > > So I've since tried out setting SPD on the interface with the IPv6 > address, and even though I am not able to ping the interface, I see that it > does receive and process packets (which I had erroneously assumed it did > not when it became unpingable). > > > > > > I added a new SPD and added a policy like so > > ipsec policy add spd 1 priority 10 inbound action protect sa 20 > local-ip-range <local_IPv6> - <local_IPv6> remote-ip-range <remote_IPv6> - > <remote_IPv6> > > > > This is what the trace looks like: > > > > Packet 10 > > 01:02:05:902414: dpdk-input > lan0 rx queue 0 > buffer 0x13daa8: current data 0, length 96, buffer-pool 1, ref-count 1, > totlen-nifb 0, trace handle 0x9 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 0, nb_segs 1, pkt_len 96 > buf_len 2176, data_len 96, ol_flags 0x181, data_off 128, phys_addr > 0xe2f6aa80 > packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > 01:02:05:868297: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP6: 5c:5e:ab:d0:29:f0 -> b4:96:91:18:eb:be 802.1q vlan 67 > 01:02:05:868299: ip6-input > IPSEC_ESP: 2001::1 -> 2001::2 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 01:02:05:868299: ipsec6-input-feature > IPSEC_ESP: sa_id 0 spd 2 policy 0 spi 1000 (0x000003e8) seq 13693 > 01:02:05:868300: ip6-lookup > fib 0 dpo-idx 8 flow hash: 0x00000000 > IPSEC_ESP: 2001::1 -> 2001::2 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 01:02:05:868301: ip6-local > IPSEC_ESP: 2001::1 -> 2001::2 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 01:02:05:868301: ip6-punt > IPSEC_ESP: 2001::1 -> 2001::2 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 01:02:05:868302: error-punt > rx:wan0.67 > 01:02:05:868302: punt > ip6-input: valid ip6 packets > > > > > > IPSEC_ESP: sa_id 0 spd 2 policy 0 spi 1000 (0x000003e8) seq 13693 > > > > Here, the spd 2 actually does not have any policy in the 0 index. > > here is what show ipsec spd 2 looks like: > > > > ip6-inbound-protect: > [4] priority 100 action protect type ip6-inbound-protect protocol any > sa 20 > local addr range 2001::2 - 2001::2 port range 0 - 65535 > remote addr range 2001::1 - 2001::1 port range 0 - 65535 > packets 0 bytes 0 > > > > Is there a mistake in the way SPD has been added? > > Or is something else the issue? > > > > Here is trace as seen by the sender: > > > > Packet 1 > > > 20:48:33:279228: dpdk-input > eth0 rx queue 0 > buffer 0x8ee28: current data 0, length 98, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x0 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 98 > buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr > 0xb3fb8a80 > packet_type 0x10 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0xed0f5862 fdir.hi 0x0 fdir.lo 0xed0f5862 > Packet Types > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP4: 12:6a:27:79:97:3c -> 12:71:86:3a:04:7b > ICMP: 10.6.33.33 -> 172.30.0.2 > tos 0x00, ttl 64, length 84, checksum 0xf51f dscp CS0 ecn NON_ECN > fragment id 0x6e42, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15b1 > 20:48:33:279234: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP4: 12:6a:27:79:97:3c -> 12:71:86:3a:04:7b > 20:48:33:279239: ip4-input-no-checksum > ICMP: 10.6.33.33 -> 172.30.0.2 > tos 0x00, ttl 64, length 84, checksum 0xf51f dscp CS0 ecn NON_ECN > fragment id 0x6e42, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15b1 > 20:48:33:279240: ip4-lookup > fib 0 dpo-idx 6 flow hash: 0x00000000 > ICMP: 10.6.33.33 -> 172.30.0.2 > tos 0x00, ttl 64, length 84, checksum 0xf51f dscp CS0 ecn NON_ECN > fragment id 0x6e42, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15b1 > 20:48:33:279242: ip4-rewrite > tos 0x00, ttl 64, length 84, checksum 0xf51f dscp CS0 ecn NON_ECN > fragment id 0x6e42, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15b1 > 20:48:33:279242: ip4-rewrite > tx_sw_if_index 3 dpo-idx 6 : ipv4 via 11.11.11.10 loop0: mtu:9000 next:4 > 246e969ce5 > dfdead000000000800 flow hash: 0x00000000 > 00000000: > 246e969ce5dfdead000000000800450000546e4240003f01f61f0a062121ac1e > 00000020: 0002080015b178da00122221bd5e00000000c60f0500000000001011 > 20:48:33:279244: ipsec4-output-feature > spd 1 policy 2 > 20:48:33:279246: esp4-encrypt > esp: sa-index 0 spi 1000 (0x000003e8) seq 13028 sa-seq-hi 0 crypto > aes-cbc-128 inte > grity sha1-96 > 20:48:33:279240: ip4-lookup > fib 0 dpo-idx 6 flow hash: 0x00000000 > ICMP: 10.6.33.33 -> 172.30.0.2 > tos 0x00, ttl 64, length 84, checksum 0xf51f dscp CS0 ecn NON_ECN > fragment id 0x6e42, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15b1 > 20:48:33:279242: ip4-rewrite > tx_sw_if_index 3 dpo-idx 6 : ipv4 via 11.11.11.10 loop0: mtu:9000 next:4 > 246e969ce5 > 20:48:33:279240: ip4-lookup > fib 0 dpo-idx 6 flow hash: 0x00000000 > ICMP: 10.6.33.33 -> 172.30.0.2 > tos 0x00, ttl 64, length 84, checksum 0xf51f dscp CS0 ecn NON_ECN > fragment id 0x6e42, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15b1 > 20:48:33:279242: ip4-rewrite > tx_sw_if_index 3 dpo-idx 6 : ipv4 via 11.11.11.10 loop0: mtu:9000 next:4 > 246e969ce5 > dfdead000000000800 flow hash: 0x00000000 > 00000000: > 246e969ce5dfdead000000000800450000546e4240003f01f61f0a062121ac1e > 00000020: 0002080015b178da00122221bd5e00000000c60f0500000000001011 > 20:48:33:279244: ipsec4-output-feature > spd 1 policy 2 > 20:48:33:279246: esp4-encrypt > esp: sa-index 0 spi 1000 (0x000003e8) seq 13028 sa-seq-hi 0 crypto > aes-cbc-128 inte > grity sha1-96 > 20:48:33:279255: ip6-load-balance > fib 3 dpo-idx 3 flow hash: 0x00000000 > IPSEC_ESP: 2001::1 -> 2001::2 > tos 0x00, flow label 0x0, hop limit 254, payload length 132 > 20:48:33:279258: ip6-rewrite > tx_sw_if_index 1 adj-idx 3 : ipv6 via fe80::1043:12ff:fec4:2197 wan0: > mtu:9000 next > :3 124312c4219712273c81f8f386dd flow hash: 0x00000000 > 00000000: > 124312c4219712273c81f8f386dd60000000008432fd26001f18254c9301e507 > 00000020: > 7624cf3f7184260410c0000100000000000000000010000003e8000032e42112 > 00000040: > 6acf95626ff015f514ce23230e5cab93ba24df0ade533f87b96bc02856a7f0e7 > 00000060: df4922f832163a63346bb518f1308c757bbda288b750bd2cae26732a > 20:48:33:279258: wan0-output > wan0 > IP6: 12:27:3c:81:f8:f3 -> 12:43:12:c4:21:97 > IPSEC_ESP: 2001::1 -> 2001::2 > tos 0x00, flow label 0x0, hop limit 253, payload length 132 > 20:48:33:279260: wan0-tx > wan0 tx queue 0 > buffer 0x8ee28: current data -64, length 186, buffer-pool 0, ref-count > 1, trace han > dle 0x0 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 > l3-hdr-offset 14 > > PKT MBUF: port 1, nb_segs 1, pkt_len 186 > buf_len 2176, data_len 186, ol_flags 0x0, data_off 64, phys_addr > 0xb3fb8a80 > packet_type 0x10 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0xed0f5862 fdir.hi 0x0 fdir.lo 0xed0f5862 > Packet Types > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP6: 12:27:3c:81:f8:f3 -> 12:43:12:c4:21:97 > IPSEC_ESP: 2001::1 -> 2001::2 > tos 0x00, flow label 0x0, hop limit 253, payload length 132 > > > > Let me know if you need more info. > > Thanks, > > Muthu > > > > On Wed, May 13, 2020 at 9:15 PM Muthu Raj via lists.fd.io > <muthuraj.muthu15=gmail....@lists.fd.io> wrote: > > Hi Neale, > > > > Thanks a lot for looking into this and providing a fix, much appreciated. > > > > I have applied the fix, and that solved the issue on the sender side. > > The packet successfully reached the other side. However, the issue is on > the other side now. > > > > The packet trace looks like this: (I've put dummy local and remote IPv6 > IPs) > > > > Packet 12 > > 02:06:48:110231: dpdk-input > wan0 rx queue 0 > buffer 0x11e885: current data 0, length 74, buffer-pool 1, ref-count 1, > totlen-nifb 0, trace handle 0xb > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 74 > buf_len 2176, data_len 74, ol_flags 0x181, data_off 128, phys_addr > 0xe27a21c0 > packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 190 > buf_len 2176, data_len 190, ol_flags 0x181, data_off 128, phys_addr > 0xe279a300 > packet_type 0x41 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid 67 > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV6 (0x0040) IPv6 packet without extension headers > IP6: 5c:5e:ab:d0:29:f0 -> b4:96:91:18:eb:be 802.1q vlan 67 > IPSEC_ESP: 2001::2 -> 2001::1 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 02:06:48:074127: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP6: 5c:5e:ab:d0:29:f0 -> b4:96:91:18:eb:be 802.1q vlan 67 > 02:06:48:074128: ip6-input > IPSEC_ESP: 2001::2 -> 2001::1 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 02:06:48:074128: ip6-lookup > fib 0 dpo-idx 8 flow hash: 0x00000000 > IPSEC_ESP: 2001::2 -> 2001::1 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 02:06:48:074129: ip6-local > IPSEC_ESP: 2001::2 -> 2001::1 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 02:06:48:074130: ip6-punt > IPSEC_ESP: 2001::2 -> 2001::1 > tos 0x28, flow label 0x0, hop limit 238, payload length 132 > 02:06:48:074130: error-punt > rx:wan0.67 > 02:06:48:074131: punt > ip6-input: valid ip6 packets > > > > Now, in my understanding, this is because the SPD action for decryption is > not triggered - probably because I set the SPD on the lan0.218 interface > and nothing on the wan0.67 interface, which is the one that has the IPv6 IP. > > > > I looked at the script at > https://gerrit.fd.io/r/c/vpp/+/27019/4/src/scripts/vnet/ipsec_spd in your > patch. > > > > Things I noticed there, > > 1. SPD is set on the pipe interface with IPv6 which makes sense. > > 2. The inbound action actually just mentions IPv6 local and remote IP, > which I guess also makes sense since no other information is available > until decryption. > > > > The problem I am facing is, I am unable to set SPD on the wan0.67 > interface. As soon as I set an SPD, I lose the ability to communicate with > the interface. This actually happened with the lan interface as well, but I > side stepped by adding a loopback interface and setting SPD there. > > > > (I remember being able to ping the interface IP even after setting the SPD > on it in the past, but I am not completely sure) > > > > > > This is how it was done: > > > loopback create > set int state loop0 up > set int ip address loop0 11.11.11.11/31 > set ip neighbor loop0 11.11.11.10 24:6e:96:9c:e5:df > ipsec sa add 10 spi 1000 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <Key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > ipsec sa add 20 spi 1001 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <Key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > ipsec spd add 1 > set interface ipsec spd loop0 1 > ipsec policy add spd 1 priority 100 inbound action bypass protocol 50 > ipsec policy add spd 1 priority 100 outbound action bypass protocol 50 > ipsec policy add spd 1 priority 10 outbound action protect sa 10 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ipsec policy add spd 1 priority 10 inbound action protect sa 20 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ip route add 10.6.0.0/16 via 172.30.0.6 lan0.218 > > > > In the inbound action, I had directly translated what I had seen in > documentations for IPv4. > > > > I realise that this may not be the correct thing to do. > > > > So I guess my doubts are on 2 things, > > > > 1. What is the right way to set inbound action to correctly decrypt the > incoming ESP packets? Would something like this work? > > > > ipsec policy add spd 1 priority 10 inbound action protect sa 20 > local-ip-range <local_IPv6> - <local_IPv6> remote-ip-range <remote_IPv6> - > <remote_IPv6> > > > > 2. How would I overcome the fact that setting SPD means I am no longer > able to reach that interface? > > I am guessing another loopback interface, that gets all the packets > destined for wan0.67 (may be through an l2 bridge?) and SPD should be > there. Am I in the right path? > > If yes, could you direct me to documentation regarding oneway L2 bridging > to a virtual / loopback interface? > > > > > > Thanks so much for looking into this, once again. > > > > > > Thanks, > > Muthu > > > > On Wed, May 13, 2020 at 2:54 PM Neale Ranns (nranns) <nra...@cisco.com> > wrote: > > > > Hi Muthu, > > > > I tried your 4over6 config, it doesn’t work… here’s the fix: > > https://gerrit.fd.io/r/c/vpp/+/27019 > > > > /neale > > > > *From: *Muthu Raj <muthuraj.muth...@gmail.com> > *Date: *Monday 11 May 2020 at 21:36 > *To: *"Neale Ranns (nranns)" <nra...@cisco.com> > *Cc: *"Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco)" < > fteh...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > *Subject: *Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hi Neale, > > > > Thank you so much for patiently explaining. I initially added next-hop > like this - > > ip route add 10.6.0.0/16 via 172.30.0.6 lan0.218 > > > But it still got dropped with ip4-arp: ARP requests sent. > > > > Then I read your message again, and realised that the ARP response really > doesn't matter. So I set a static ARP entry like so - > > set ip neighbor lan0.218 172.30.0.6 c8:5b:76:d9:7f:9c > > > > That thankfully, changed the nodes visited. Unfortunately, it still fails > with an error like below - ipsec6-no-such-tunnel. > > I understand that it must be some mistake in setting up the tunnel, but > once again, I am not sure how to proceed. > > > > The packet trace is at the end. > > > > Here is the way I set-up the tunnel: > > > > ipsec sa add 10 spi 1000 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <Key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > ipsec sa add 20 spi 1001 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <Key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > ipsec spd add 1 > set interface ipsec spd lan0.218 1 > ipsec policy add spd 1 priority 100 inbound action bypass protocol 50 > ipsec policy add spd 1 priority 100 outbound action bypass protocol 50 > ipsec policy add spd 1 priority 10 outbound action protect sa 10 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ipsec policy add spd 1 priority 10 inbound action protect sa 20 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ip route add 10.6.0.0/16 via 172.30.0.6 lan0.218 > > set ip neighbor lan0.218 172.30.0.6 24:6e:96:9c:e5:df > > > > *Packet trace:* > > > 00:01:35:388393: dpdk-input > lan0 rx queue 0 > buffer 0x1389c3: current data 0, length 102, buffer-pool 1, ref-count 1, > totlen-nifb 0, trace handle 0x10 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 0, nb_segs 1, pkt_len 102 > buf_len 2176, data_len 102, ol_flags 0x181, data_off 128, phys_addr > 0xe2e27140 > packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid 218 > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP4: 00:1b:21:88:af:89 -> b4:96:91:18:eb:bc 802.1q vlan 218 > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xe791 dscp CS0 ecn NON_ECN > fragment id 0x91cf, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15bb > 00:01:35:388395: ethernet-input > frame: flags 0x3, hw-if-index 1, sw-if-index 1 > IP4: 00:1b:21:88:af:89 -> b4:96:91:18:eb:bc 802.1q vlan 218 > 00:01:35:388396: ip4-input > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xe791 dscp CS0 ecn NON_ECN > fragment id 0x91cf, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15bb > 00:01:35:388397: ip4-lookup > fib 0 dpo-idx 6 flow hash: 0x00000000 > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xe791 dscp CS0 ecn NON_ECN > fragment id 0x91cf, flags DONT_FRAGMENT > ICMP echo_request checksum 0x15bb > 00:01:35:388397: ip4-rewrite > tx_sw_if_index 4 dpo-idx 6 : ipv4 via 172.30.0.6 lan0.218: mtu:9000 > 246e969ce5dfb4969118ebbc810000da0800 flow ha > sh: 0x00000000 > 00000000: > 246e969ce5dfb4969118ebbc810000da08004500005491cf40003f01e891ac1e > 00000020: 00020a060b22080015bb4fa504f9a1a5b95e0000000067cf0c000000 > 00:01:35:388397: ipsec4-output-feature > spd 1 policy 2 > 00:01:35:388398: esp4-encrypt > esp: sa-index 0 spi 1000 (0x000003e8) seq 11 sa-seq-hi 0 crypto > aes-cbc-128 integrity sha1-96 > 00:01:35:388401: punt-dispatch > reason: [2] ipsec6-no-such-tunnel > 00:01:35:388403: drop > punt-dispatch: No registrations > > Thanks again, > > Muthu > > > > On Tue, May 12, 2020 at 12:24 AM Neale Ranns (nranns) <nra...@cisco.com> > wrote: > > > > Hi Muthu, > > > > Your lan0.218 has address in the 172.16.0.5/16, set the next hop to the > peer on that link in that subnet. If you don’t have one, in this case, you > can use any address… the problem is that IPSec SPD runs as an output > feature, but we don’t run features for packets that hit the glean (i.e. I > need to ARP) adjacency. So the route needs to resolve via a neighbour > adjacency. It doesn’t have to be a complete adj, hence you don’t need an > ARP response, so any address will do. > > > > /neale > > > > *From: *<vpp-dev@lists.fd.io> on behalf of Muthu Raj < > muthuraj.muth...@gmail.com> > *Date: *Monday 11 May 2020 at 19:22 > *To: *"Neale Ranns (nranns)" <nra...@cisco.com> > *Cc: *"Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco)" < > fteh...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > *Subject: *Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hi Neale, > > > > Thanks for responding so quickly. > > It might sound a little bit pedestrian, but what would be the next hop in > this case? Would it be the IPv6 IP (over which the tunnel is established) ? > > > > I have added it through the lan0.218 interface with the assumption that > the sa will kick in and send over the tunnel. > > > > > > On Mon, May 11, 2020, 10:26 PM Neale Ranns (nranns) <nra...@cisco.com> > wrote: > > > > > > *From: *Muthu Raj <muthuraj.muth...@gmail.com> > *Date: *Monday 11 May 2020 at 18:42 > *To: *"Neale Ranns (nranns)" <nra...@cisco.com> > *Cc: *"Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco)" < > fteh...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > *Subject: *Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hi Neale, > > > > The 10.6.0.0/16 is actually on the remote side, and should flow over the > IPv6 IPsec tunnel. > > I was hoping by adding route via the lan0.218 interface, the spd will kick > in and send over the tunnel. I guess I'm missing something very glaring, so > would appreciate pointers. > > > > You’re missing next-hop for the route. > > > > /neale > > > > The source of the traced packet is actually another node, that sends to > the lan0.218 IP for the remote subnet destination. > > > > > > Thanks, > > Muthu > > > > On Mon, May 11, 2020, 9:41 PM Neale Ranns (nranns) <nra...@cisco.com> > wrote: > > > > Hi Muthu, > > > > Your lan0 interface is not point-2-point, so your route needs a nexthop; > > ip route add 10.6.0.0/16 via 172.30.x.y lan0.218 > > > > x and y can be anything, apart from x=0 and y=5. > > > > /neale > > > > *From: *<vpp-dev@lists.fd.io> on behalf of Muthu Raj < > muthuraj.muth...@gmail.com> > *Date: *Monday 11 May 2020 at 17:39 > *To: *"Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco)" < > fteh...@cisco.com> > *Cc: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > *Subject: *Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hi Filip, > > > > I have traced the packet. > > > > Here is how I setup the tunnel > > > > <home subnet=172.30.0.0/16> || <SRC_IPv6> <=======> <DST_IPv6> || <Remote > Subnet=10.6.0.0/16> > > > > ipsec sa add 10 spi 1000 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <Key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > ipsec sa add 20 spi 1001 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <Key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > ipsec spd add 1 > set interface ipsec spd lan0.218 1 > ipsec policy add spd 1 priority 100 inbound action bypass protocol 50 > ipsec policy add spd 1 priority 100 outbound action bypass protocol 50 > ipsec policy add spd 1 priority 10 outbound action protect sa 10 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ipsec policy add spd 1 priority 10 inbound action protect sa 20 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > > ip route add 10.6.0.0/16 via lan0.218 > > > > vpp# show int address > lan0 (up): > lan0.218 (up): > L3 172.30.0.5/16 > local0 (up): > wan0 (up): > wan0.67 (up): > L3 <SRC_IPv6> > > > > Corresponding config on remote side. > > Trace: > > > > 00:32:40:825694: dpdk-input > lan0 rx queue 0 > buffer 0x13e1d1: current data 0, length 74, buffer-pool 1, ref-count 1, > totlen-nifb 0, trace handle 0x11 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 0, nb_segs 1, pkt_len 74 > buf_len 2176, data_len 74, ol_flags 0x181, data_off 128, phys_addr > 0xe05874c0 > packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid 218 > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP4: 00:1b:21:88:af:89 -> b4:96:91:18:eb:bc 802.1q vlan 218 > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xb4be dscp CS0 ecn NON_ECN > fragment id 0xc4a2, flags DONT_FRAGMENT > ICMP echo_request checksum 0x7ddd > 00:32:40:712830: ethernet-input > frame: flags 0x3, hw-if-index 1, sw-if-index 1 > IP4: 00:1b:21:88:af:89 -> b4:96:91:18:eb:bc 802.1q vlan 218 > 00:32:40:712831: ip4-input > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xb4be dscp CS0 ecn NON_ECN > fragment id 0xc4a2, flags DONT_FRAGMENT > ICMP echo_request checksum 0x7ddd > 00:32:40:712831: ip4-lookup > fib 0 dpo-idx 3 flow hash: 0x00000000 > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xb4be dscp CS0 ecn NON_ECN > fragment id 0xc4a2, flags DONT_FRAGMENT > ICMP echo_request checksum 0x7ddd > 00:32:40:712832: ip4-glean > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xb4be dscp CS0 ecn NON_ECN > fragment id 0xc4a2, flags DONT_FRAGMENT > ICMP echo_request checksum 0x7ddd > 00:32:40:712833: ip4-drop > ICMP: 172.30.0.2 -> 10.6.11.34 > tos 0x00, ttl 64, length 84, checksum 0xb4be dscp CS0 ecn NON_ECN > fragment id 0xc4a2, flags DONT_FRAGMENT > ICMP echo_request checksum 0x7ddd > 00:32:40:712833: error-drop > rx:lan0.218 > 00:32:40:712834: drop > ip4-glean: ARP requests sent > > > > I believe for some reason the policy match is not happening. And I am not > able to find examples of IPv4 over IPv6 tunnel, so I might be making a > mistake in setting up the tunnel itself. > > Let me know if you need more info, and thank you so much for looking into > this. Much appreciated. > > > > Thanks, > > Muthu > > > > > > > > On Mon, May 11, 2020 at 3:41 PM Filip Tehlar -X (ftehlar - PANTHEON TECH > SRO at Cisco) <fteh...@cisco.com> wrote: > > Hi Muthu, > > > > you can enable packet tracing [1] and see what nodes are visited. > > > > Filip > > > > [1] > https://wiki.fd.io/view/VPP/How_To_Use_The_Packet_Generator_and_Packet_Tracer#Step_3._Examine_the_setup_script > > VPP/How To Use The Packet Generator and Packet Tracer - fd.io > <https://wiki.fd.io/view/VPP/How_To_Use_The_Packet_Generator_and_Packet_Tracer#Step_3._Examine_the_setup_script> > > Introduction. The VPP platform includes packet generation and packet > tracing facilities. The following example shows steps that you might > typically use to run a debug version of the vpp executable file, generate > packets, and to analyze results. > > wiki.fd.io > > > ------------------------------ > > *From:* Muthu Raj <muthuraj.muth...@gmail.com> > *Sent:* Thursday, May 7, 2020 7:04 PM > *To:* Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco) < > fteh...@cisco.com> > *Cc:* vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> > *Subject:* Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hello Filip, > > > > I just tried adding a loopback interface and setting the SPD on that > interface. > > Here is how I tried it: > > > > create loopback interface > set int state loop0 up > set interface ip table loop0 0 > set int ip address loop0 11.11.11.11/32 > ipsec sa add 10 spi 1000 esp crypto-key <KEY> crypto-alg aes-cbc-128 > integ-key <KEY> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > ipsec sa add 20 spi 1001 esp crypto-key <KEY> crypto-alg aes-cbc-128 > integ-key <KEY> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DST_IPv6> > > ipsec spd add 1 > set interface ipsec spd loop0 1 > ipsec policy add spd 1 priority 100 inbound action bypass protocol 50 > ipsec policy add spd 1 priority 100 outbound action bypass protocol 50 > > ipsec policy add spd 1 priority 10 outbound action protect sa 10 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ipsec policy add spd 1 priority 10 inbound action protect sa 20 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ip route table 0 10.6.0.0/16 via loop0 > > > > Corresponding configuration on the other side. > > Ping 10.6.0.1 results in these counters in show errors: > > > > 5 arp-input IP4 destination address > is unset > 5 ip4-glean ARP requests sent > > If there is any documentation that would help me gain clarity on what is > going wrong, that would be really appreciated. > > > > Thanks again, > > Muthu > > > > > > On Thu, May 7, 2020 at 8:50 PM Muthu Raj <muthuraj.muth...@gmail.com> > wrote: > > Thanks for replying Filip. > I have indeed tried to set it up this way, and I think setting the spd on > lan0.218 messes something up. > > I lose the ability to ping even other IPs on the same subnet as the > address of the lan0.218 interface. > eg., I can't ping 172.30.0.1 when lan0.218 is 172.30.0.2 > > I see the ipsec4-output-feature IPSec policy (no match) counter > going up by the exact number of ping packets, which means even local > destinations are getting caught in this. > I am not sure how to fix this. > > This is what show ipsec spd looks like: > spd 1 > ip4-outbound: > [0] priority 100 action bypass type ip4-outbound protocol IPSEC_ESP > local addr range 0.0.0.0 - 0.0.0.0 port range 0 - 65535 > remote addr range 0.0.0.0 - 0.0.0.0 port range 0 - 65535 > packets 0 bytes 0 > [2] priority 10 action protect type ip4-outbound protocol any sa 10 > local addr range 10.6.0.0 - 10.6.255.255 port range 0 - 65535 > remote addr range 172.30.0.0 - 172.30.255.255 port range 0 - 65535 > packets 0 bytes 0 > ip6-outbound: > ip4-inbound-protect: > [3] priority 10 action protect type ip4-inbound-protect protocol any sa > 20 > local addr range 10.6.0.0 - 10.6.255.255 port range 0 - 65535 > remote addr range 172.30.0.0 - 172.30.255.255 port range 0 - 65535 > packets 0 bytes 0 > ip6-inbound-protect: > ip4-inbound-bypass: > [1] priority 100 action bypass type ip4-inbound-bypass protocol > IPSEC_ESP > local addr range 0.0.0.0 - 0.0.0.0 port range 0 - 65535 > remote addr range 0.0.0.0 - 0.0.0.0 port range 0 - 65535 > packets 0 bytes 0 > ip6-inbound-bypass: > > > > Can you guide me on how to set the SPD the right way and if I should setup > a separate loopback interface with a dummy IP from a different subnet > (different from local-subnet) and send IPsec remote destinations there and > set SPD on that dummy interface? > > > > Your help is much appreciated. > > Thanks, > > Muthu > > > > On Thu, May 7, 2020 at 7:11 PM Filip Tehlar -X (ftehlar - PANTHEON TECH > SRO at Cisco) <fteh...@cisco.com> wrote: > > Hi Muthu, > > > > I don't see any reason why your approach shouldn't work. > > > > Do you have any specific problem with it? > > > > Filip > ------------------------------ > > *From:* Muthu Raj <muthuraj.muth...@gmail.com> > *Sent:* Thursday, May 7, 2020 9:08 AM > *To:* Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco) < > fteh...@cisco.com> > *Cc:* vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> > *Subject:* Re: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer > behind NAT (AWS instance) > > > > Hello Filip, > > I was wondering if IPv6 IPsec can help us here while NAT traversal is > being developed. > Can we route IPv4 traffic over ipv6 ipsec tunnel? > If we had two interfaces, one with the IPv4 IP which is part of local > subnet and one with IPv6 subnet IP which will be used for transporting > the ESP packets. > The configuration I have in mind is like this: > vpp# show int address > lan0 (up): > lan0.218 (up): > L3 172.30.0.5/16 > local0 (dn): > wan0 (up): > wan0.67 (up): > L3 <IPv6_HOME> > > > On home side(172.30.0.0/16): > > ipsec sa add 10 spi 1000 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DEST_IPv6> > ipsec sa add 20 spi 1001 esp crypto-key <key> crypto-alg aes-cbc-128 > integ-key <key> integ-alg sha1-96 tunnel-src <SRC_IPv6> tunnel-dst > <DEST_IPv6> > ipsec spd add 1 > set interface ipsec spd lan0.218 1 > ipsec policy add spd 1 priority 100 inbound action bypass protocol 50 > ipsec policy add spd 1 priority 100 outbound action bypass protocol 50 > ipsec policy add spd 1 priority 10 inbound action protect sa 20 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ipsec policy add spd 1 priority 20 outbound action protect sa 20 > local-ip-range 172.30.0.0 - 172.30.255.255 remote-ip-range 10.6.0.0 - > 10.6.255.255 > ip route add 10.6.0.0/16 via lan0.218 > > And similar configuration on the remote side. > > Let me know if I am going obviously wrong. > This is what I could get from the docs available and there doesn't see > to be examples for IPv6. > > I would like traffic flow from outside VPP source, like 172.30.0.2 on > home side to flow to 172.30.0.5 (VPP) and flow over the tunnel for > 10.6.0.0/16 destination. > Thanks, > Muthu > > On Tue, May 5, 2020 at 1:58 PM Filip Tehlar -X (ftehlar - PANTHEON > TECH SRO at Cisco) <fteh...@cisco.com> wrote: > > > > Hi, > > > > NAT traversal in IKE isn't supported yet, but there is an ongoing work > to add one: > > https://gerrit.fd.io/r/c/vpp/+/26726 > > > > Filip > > ________________________________ > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of > muthurajmuth...@gmail.com <muthurajmuth...@gmail.com> > > Sent: Tuesday, May 5, 2020 8:49 AM > > To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> > > Subject: [SUSPECTED SPAM] [vpp-dev] Troubleshooting IPsec peer behind > NAT (AWS instance) > > > > Hello, > > > > I am trying out IPSec on VPP, and used the wiki[1] to create an IPSec > > tunnel between an AWS instance(remote) and my home. The tunnel was > > established successfully, and when pinging an IP on the remote side, > > the icmp req flows over the tunnel, is seen by the remote box, and > > responded back as well. I also see that the packets indeed end up > > reaching my home VPP instance - however, they do not reach the last > > hop. When I run show int, the ipip0 interface does not show the rx > > counter at all, and when running `show errors` I do not see the > > counter for the `ipsec4-tun-input` node either. Neither do I see the > > `esp4-encrypt-tun' counter. > > > > My preliminary guess is that it has something to do with the fact that > > on AWS we cannot see the public IP inside the instance and so that > > cannot be assigned to the interface itself, so probably the ESP > > packets are generated with source as the private IP address > > corresponding to the public IP. With strongswan, we specify an > > explicit sourceip parameter, like in the snippet below > > > > left=1.2.3.4 > > leftid=1.2.3.4 > > leftsubnet=172.16.0.0/16 > > right=4.5.6.7 #AWS public IP > > rightsourceip=10.6.82.34 #AWS private IP for that public IP, seen > > inside the instance. > > rightsubnet=10.6.0.0/16 > > > > So it is essentially like being NATed from the private IP to the public > IP. > > > > I am attaching the ikev2 sa as seen from both sides. > > How would I fix this issue? > > Any help is appreciated very much. > > > > Thanks in advance. > > > > > > This is from the home side. I've changed the IPs on home and remote > > side. The private IP addresses have been left as it is. > > > > vpp# show ikev2 sa > > iip 1.2.3.4 ispi d8607eea97ac12a9 rip 4.5.6.7 rspi d6726c2768b2420 > > encr:aes-cbc-256 prf:hmac-sha2-256 integ:sha1-96 dh-group:modp-2048 > > nonce > i:eb01e6ef107ba7018679bd239e25d4557f2465323caf0d3213b453ca59af3deb > > > r:1d9cb8f11cd69d4b2f73b182028d8aa8854a49bb3c99797f3994575c2994154c > > SK_d > 1eee29fff1ff234f1452006a79a7e27787e83331b29954300a70a9d6061f2fde > > SK_a i:7f86a547c2d9cb2a4035e4926ca6e23c745c6c8c > > r:04a71f139f2076058ceafb9be73eb359e43bc308 > > SK_e > i:281c47cd100f69a3425031667150d3054124ff887d77a4a1f43fd7dece7486fc > > > r:3f72f8e973ee62962dc9dffd64d80af9e83993acbcd3690adf85044a23310409 > > SK_p > i:79c096024c45499bd43b5d716c56e5152252c433b112195201dd5c4c23a1f1c7 > > > r:fb7e3b35d57b2987bf61f04858a4afaeee10045c6001594f9f2e505b94d950d8 > > identifier (i) fqdn vpp.aws > > identifier (r) fqdn vpp.home > > child sa 0: > > encr:aes-cbc-256 integ:sha1-96 esn:yes > > spi(i) 147e7a05 spi(r) de36dcbc > > SK_e > i:31e22be618e3fe60faf935759e75fdc699f743486dd18f07de8b78747d10d229 > > > r:30b10195fdb1cd5b7384a2db92d5a51fd9fab7f6fc7db775957e3dc862d72532 > > SK_a i:f98f3539966a66afec330c7cdf85fbe2794e01d3 > > r:9504182eb614d90aa8fe742122ec9d98c1b6e224 > > traffic selectors (i): > > 0 type 7 protocol_id 0 addr 172.30.0.0 - 172.30.255.255 port 0 - > 65535 > > traffic selectors (r): > > 0 type 7 protocol_id 0 addr 10.6.0.0 - 10.6.255.255 port 0 - 65535 > > iip 1.2.3.4 ispi d8607eea97ac12a9 rip 4.5.6.7 rspi d6726c2768b2420 > > > > -------------------------------------------------------------------- > > Here is the AWS side > > > > vpp# show ikev2 sa > > iip 1.2.3.4 ispi a72ae3cef809725c rip <aws private IP corresponding > > to public IP> rspi b8b7b8ef09266a6d > > encr:aes-cbc-256 prf:hmac-sha2-256 integ:sha1-96 dh-group:modp-2048 > > nonce > i:d3e4299761fd93edd3df16456cb0ca9f717f67e57155fa7cb4cd0b9a1d371019 > > > r:e9a33a33b901366438e262d225a418e9489839415562d3e3673107e0d81d830f > > SK_d > 7e4f795db87a02c5b4d5ea738945521473f5e449b783f3ac4b954be7716b7909 > > SK_a i:13639a11b6e96e65dd38d095a87fc1b5ceefdc6b > > r:97c96809563dfe39c3d2762c1ff1bf0a8fbc3576 > > SK_e > i:114661a058686bd4362d8515ce83a7d7de098af11b08084c407ad51843316135 > > > r:d812542cfa988e6c302fc52d848fb2d7b7321d6c3e77ee04134338a21c0ccba8 > > SK_p > i:a65ea61c70b3cb749dedc205b7715b4c278a4bc630c6508d89a55a00cd00a2cd > > > r:9e23352bac4d21f6f0d2ec8de82e556db3ddaba0ade0c4d664a020da3986d17b > > identifier (i) fqdn vpp.home > > identifier (r) fqdn vpp.aws > > child sa 0: > > encr:aes-cbc-256 integ:sha1-96 esn:yes > > spi(i) 31c649f8 spi(r) 967b11c4 > > SK_e > i:6a1b5898746bc922af1beba021768cd6417a0e8a4c555e5544781fee302cf633 > > > r:2035a8be8fae47c284cef445381cef487bcd670bddc31558109c0303bc0f5399 > > SK_a i:da119e539529803a3d2a883c01a825211c782bd2 > > r:2330bc2dd9eb3741e3df649bcc3f7e5320fba512 > > traffic selectors (i): > > 0 type 7 protocol_id 0 addr 172.30.0.0 - 172.30.255.255 port 0 - > 65535 > > traffic selectors (r): > > 0 type 7 protocol_id 0 addr 10.6.0.0 - 10.6.255.255 port 0 - 65535 > > iip 1.2.3.4 ispi a72ae3cef809725c rip <aws private IP corresponding > > to public IP> rspi b8b7b8ef09266a6d > > iip 1.2.3.4 ispi d8607eea97ac12a9 rip <aws private IP corresponding > > to public IP> rspi d6726c2768b2420 > > encr:aes-cbc-256 prf:hmac-sha2-256 integ:sha1-96 dh-group:modp-2048 > > nonce > i:eb01e6ef107ba7018679bd239e25d4557f2465323caf0d3213b453ca59af3deb > > > r:1d9cb8f11cd69d4b2f73b182028d8aa8854a49bb3c99797f3994575c2994154c > > SK_d > 1eee29fff1ff234f1452006a79a7e27787e83331b29954300a70a9d6061f2fde > > SK_a i:7f86a547c2d9cb2a4035e4926ca6e23c745c6c8c > > r:04a71f139f2076058ceafb9be73eb359e43bc308 > > SK_e > i:281c47cd100f69a3425031667150d3054124ff887d77a4a1f43fd7dece7486fc > > > r:3f72f8e973ee62962dc9dffd64d80af9e83993acbcd3690adf85044a23310409 > > SK_p > i:79c096024c45499bd43b5d716c56e5152252c433b112195201dd5c4c23a1f1c7 > > > r:fb7e3b35d57b2987bf61f04858a4afaeee10045c6001594f9f2e505b94d950d8 > > identifier (i) fqdn vpp.home > > identifier (r) fqdn vpp.aws > > child sa 0: > > encr:aes-cbc-256 integ:sha1-96 esn:yes > > spi(i) 147e7a05 spi(r) de36dcbc > > SK_e > i:31e22be618e3fe60faf935759e75fdc699f743486dd18f07de8b78747d10d229 > > > r:30b10195fdb1cd5b7384a2db92d5a51fd9fab7f6fc7db775957e3dc862d72532 > > SK_a i:f98f3539966a66afec330c7cdf85fbe2794e01d3 > > r:9504182eb614d90aa8fe742122ec9d98c1b6e224 > > traffic selectors (i): > > 0 type 7 protocol_id 0 addr 172.30.0.0 - 172.30.255.255 port 0 - > 65535 > > traffic selectors (r): > > 0 type 7 protocol_id 0 addr 10.6.0.0 - 10.6.255.255 port 0 - 65535 > > > > [1] > > > https://wiki.fd.io/view/VPP/IPSec_and_IKEv2#IKEv2_negotiation_between_a_VPP_responder_and_a_VPP_initiator.2C_using_RSA_signature_authentication_method > > > > *I've used PSK in place of RSA signature. > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16554): https://lists.fd.io/g/vpp-dev/message/16554 Mute This Topic: https://lists.fd.io/mt/74050344/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
