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 (0x8200) spi 3468939875 (0xcec3d263) protocol:esp
flags:[esn anti-replay ]
[1] sa 3254779904 (0xc200) spi 2709613967 (0xa1816d8f) protocol:esp
flags:[esn anti-replay inbound ]
[2] sa 2181038081 (0x8201) spi 3440684496 (0xcd14add0) protocol:esp
flags:[esn anti-replay ]
[3] sa 3254779905 (0xc201) spi 3734543736 (0xde989d78) protocol:esp
flags:[esn anti-replay inbound ]
SPD Bindings:
ipip0 flags:[none]
output-sa:
[2] sa 2181038081 (0x8201) spi 3440684496 (0xcd14add0) protocol:esp
flags:[esn anti-replay ]
input-sa:
[3] sa 3254779905 (0xc201) 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.
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.
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.
Thank you in advance for all your comments here.
शुभ कामनाएँ,
Varun Tewari
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22626): https://lists.fd.io/g/vpp-dev/message/22626
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]
-=-=-=-=-=-=-=-=-=-=-=-
