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 (#16268): https://lists.fd.io/g/vpp-dev/message/16268 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] -=-=-=-=-=-=-=-=-=-=-=-
