Hi,
Strongswan <======================> [VPP IPSec] + [Azure IKE stack]
I have a use case like above. Strongswan is the peer while VPP is the
responder. On the right hand side, I am not showing VPP ikev2 plugin
because we have disabled the plugin but rather using the Microsoft Azure
ike stack. In our case the ike stack and vpp run on different pods. We have
written a new plugin for IKE pkt forwarding to the pod where IKE stack is
running. The new plugin registers for udp port 500 and 4500 and thus fwds
all the received IKE traffic to IKE stack (to be precise, the new VPP
plugin forwards IKE packets to the application process via memif. The
application process in turn uses REST API to forward the IKE pkts to the
pods that runs the IKE stack). Once SA is established, the IKE stack would
install the SA on to the VPP IPSec plugin using VPP APIs (we would use
the vl_api_rpc_call_main_thread function call to execute the REST API SA
information).
The *IPSec SA is established fine* as displayed below but ping to the host
on the strongswan side is failing as "*blackholed packets*"
CLIs logs
================
vpp# show ipsec sa
[0] sa 256349522 (0xf479552) spi 3475331116 (0xcf25582c) protocol:esp
flags:[anti-replay ]
[1] sa 256349523 (0xf479553) spi 305419899 (0x1234567b) protocol:esp
flags:[anti-replay inbound ]
vpp#
NOTE
=============
20.200.75.1 is the host on the strongswan side,
while VirtualFuncEthernet0/7/0.1556 is the interface that is connected to
the Strongswan (this interface is pingable with the SS interface)
vpp# show interface
Name Idx State MTU (L3/IP4/IP6/MPLS) Counter
Count
VirtualFuncEthernet0/7/0 3 up 1500/0/0/0 rx
packets 12
rx
bytes 2432
tx
packets 12
tx
bytes 2408
drops
8
VirtualFuncEthernet0/7/0.1556 14 up 1500/0/0/0 rx
packets 30
rx
bytes 647112
tx
packets 12
tx
bytes 2408
drops
8
ip4
8
VirtualFuncEthernet0/9/0 4 down 9000/0/0/0
ipip0 18 down 9000/0/0/0
local0 0 down 0/0/0/0
vpp# set interface ip address ipip0 20.200.76.2/32
vpp# set interface state ipip0 up
vpp# ip route add 20.200.75.1/32 via ipip0
vpp# set interface unnumbered ipip0 use VirtualFuncEthernet0/7/0.1556
vpp# show interface
Name Idx State MTU (L3/IP4/IP6/MPLS)
Counter Count
VirtualFuncEthernet0/7/0 3 up 1500/0/0/0 rx
packets 14
rx
bytes 2618
tx
packets 14
tx
bytes 2594
drops
9
VirtualFuncEthernet0/7/0.1556 14 up 1500/0/0/0 rx
packets 34
rx
bytes 711766
tx
packets 14
tx
bytes 2594
drops
9
ip4
9
VirtualFuncEthernet0/9/0 4 down 9000/0/0/0
ipip0 18 up 9000/0/0/0
local0 0 down 0/0/0/0
*ISSUE*
*=========*
All the ping traffic from SS are coming to VPP as ESP packets but the VPP
is dropping them as "*unknown ip protocol*". Also, for all the ping packets
triggered from VPP side are not being put onto the ipip0 IPSec tunnel but
they are dropped as "*blackholed packets*"
*NOTE: -*
*==============*
On the VPP, after adding a route to the destination 20.200.75.1, the show
ip FIB output shows dpo-drop rather than send via
"VirtualFuncEthernet0/7/0.1556" as shown below.
*vpp# show if fib*
*20.200.75.1/32 <http://20.200.75.1/32> unicast-ip4-chain [@0]:
dpo-load-balance: [proto:ip4 index:81 buckets:1 uRPF:109 to:[0:0]] [0]
[@6]: ipv4 via 0.0.0.0 ipip0: mtu:9000 next:16
450000000000000040048b9814146363141463d7 stacked-on entry:78:
[@1]: dpo-drop ip4*
vpp# show node counters
Count Node Reason
* 10 null-node blackholed packets*
81 memif-input not ip packet
2731 an_ppe_wfectrl wfectrl packets received
2731 an_ppe_wfectrl wfectrl replies sent
2181 an_ppe_wfectrl session stat request
received
1 an_ppe_wfectrl service construct config
request received
1 an_ppe_wfectrl service construct config
request success
1 an_ppe_wfectrl service config request
received
1 an_ppe_wfectrl service config request
success
453 an_ppe_wfectrl dpi stats request received
453 an_ppe_wfectrl dpi stats request success
19 an_ppe_wfectrl nat stats request received
19 an_ppe_wfectrl nat stats request success
58 arp-reply ARP replies sent
81 ip4-udp-lookup No error
* 14 ip4-local unknown ip protocol*
vpp#
vpp#
*NOTE*
*=============*
When I did a POC using VPP ikev2 plugin and VPP IPSec, I did not face this
issue. The ping traffic from SS would be successfully decrypted at VPP and
also the reply sent back to SS. In the POC, the route entry of the
destination was fine. It was not dpo-drop.
Please suggest if there is any way to debug the traffic drops as "Unknown
ip protocol" for incoming ESP traffic and traffic drops as "blackholed
packets" for outgoing traffic
Any help is highly appreciated.
Regards,
Vijay Kumar N
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18879): https://lists.fd.io/g/vpp-dev/message/18879
Mute This Topic: https://lists.fd.io/mt/81158278/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
