Hi Varun, Pls find my inputs inline.
Regards Ashish Mittal On Sat, 25 Feb, 2023, 11:23 pm Varun Tewari, <tewari.va...@gmail.com> wrote: > Hello Team, > > I am new to VPP and probing this technology to build an IPSec responder > for our use-cases. > Our initial tests do show the performance might of VPP. > However on probing this further in depth, I noticed a few limitations and > I am dropping this rider seeking clarification around these. > All my observations are for VPP 23.02 and am using VPP’s Ikev2 plugin.I am > using a linux with strongswan as the peer for my tests. > > My observations: > > 1. > VPP seems doesn’t support multiple child-sa (phase 2 sa, ipsec sa) within > the same tunnel. > Single IPsec SA works fine. An interface ipip0 gets created and SPD shows > the correct binding (show ipsec all). > However ,when I bring up the second child-sa for a different TS, I se the > SPD gets overwritten for the interface and the new child-sa gets installed > overwriting the previous one. > For sure this is leading to traffic drop for the traffic hitting the first > TS. > > Q: Is this by design or have I got my config wrong in some way. > > Here the quick output from the VPP and strongswan > sudo swanctl --list-sas > net-1: #11, ESTABLISHED, IKEv2, abb046c62a60c38a_i* dc95e079629854ca_r > local 'roadwarrior.vpn.example.com' @ 17.17.17.1[500] > remote 'vpp.home' @ 17.17.17.2[500] > AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 > established 848s ago, reauth in 84486s > net-1: #16, reqid 16, INSTALLED, TUNNEL, ESP:AES_CBC-192/HMAC_SHA1_96/ESN > installed 848s ago, rekeying in 84690s, expires in 85552s > in cec3d263, 24717 bytes, 107 packets, 687s ago > out a1816d8f, 179718 bytes, 778 packets, 0s ago > local 16.16.16.0/24 > remote 18.18.18.0/24 > net-2: #17, reqid 17, INSTALLED, TUNNEL, ESP:AES_CBC-192/HMAC_SHA1_96/ESN > installed 686s ago, rekeying in 84831s, expires in 85714s > in cd14add0, 122199 bytes, 529 packets, 2s ago > out de989d78, 122199 bytes, 529 packets, 2s ago > local 16.16.15.0/24 > remote 18.18.18.0/24 > > vpp# show ipsec all > [0] sa 2181038080 (0x82000000) spi 3468939875 (0xcec3d263) protocol:esp > flags:[esn anti-replay ] > [1] sa 3254779904 (0xc2000000) spi 2709613967 (0xa1816d8f) protocol:esp > flags:[esn anti-replay inbound ] > [2] sa 2181038081 (0x82000001) spi 3440684496 (0xcd14add0) protocol:esp > flags:[esn anti-replay ] > [3] sa 3254779905 (0xc2000001) spi 3734543736 (0xde989d78) protocol:esp > flags:[esn anti-replay inbound ] > SPD Bindings: > ipip0 flags:[none] > output-sa: > [2] sa 2181038081 (0x82000001) spi 3440684496 (0xcd14add0) protocol:esp > flags:[esn anti-replay ] > input-sa: > [3] sa 3254779905 (0xc2000001) spi 3734543736 (0xde989d78) protocol:esp > flags:[esn anti-replay inbound ] > IPSec async mode: off > vpp# > > All 4 SAs exist, however the SPD binding shows the latest 2, that > overwrote the SAs for the previous TS leading to traffic drop. > AM=> IKEv2 plugin is experimental state yet. This behaviour that you are observing, is unfortunately current implementation. Consider it either a bug or simplification done for experimental implementation. > > > 2. > Overlapping subnets between different Ipsec tunnel > > When Ikev2 completes, I see, it creates an pip interface and relevant > Child-SAs and ties them to the interface to protect traffic. > So far all is good. > Now, we add an route into VPP to route the traffic via this ipip interface > for each of the source subnet that are expected to be protected by the > tunnel. > This works fine as long as I keep the subnets distinct. > > Q: What’s the usual strategy when we have overlapping subnets in two > distinct tunnels ? > T1: SrcSubnet1 DestinationSubnet1 > T2: SrcSubnet1 DestinationSubnet2 > > When T1 is brought up, we add a FIB entry for SrcSubnet1 via ipipT1 and > things works fine. > When T2 comes up, ipipT2 is created and now I need to add FIB entry for > SrcSubnet1 via ipipT2 and as expected things break here. > AM=> I am not sure but it can be done via ABF instead of FIB entries. I > have never tried that but ABF is used for that. > > 3. > IpIp vs Ipsec interface > For Route based VPP IPsec, I see two options as per the documentation. > The doc says, Ikev2 will create an ipsec interface, however it creates an > ipip interface. Is this expected ? > The interface works okay for me, but wasn’t sure why the difference. > Further on probing the code, I do see Ikev2 plugin is creating an ipip > interface not ipsec interface as the doc says. > AM=> Latest implementation uses ipip tunnel instead of ipsec interface. > You are looking at older documentation so kindly check latest one. > > Thank you in advance for all your comments here. > > *शुभ कामनाएँ*, > Varun Tewari > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22637): https://lists.fd.io/g/vpp-dev/message/22637 Mute This Topic: https://lists.fd.io/mt/97230775/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
