Hi Vijay, ‘unknown IP protocol’ means there is no registered handler for ESP. From the info you gave I am assuming you are using ip-ip tunnel protection with the SAs in transport mode. In that case the incoming packet should classify to the ip-ip tunnel. The fact that it doesn’t, and the fact that the per through the tunnel is unreachable, suggests that the src,dst addresses on this tunnel are incorrect. The VPP IKE plugin would have set these addresses correctly for you based on the IKE session end point.
/neale From: [email protected] <[email protected]> on behalf of Vijay Kumar via lists.fd.io <[email protected]> Date: Monday, 8 March 2021 at 08:44 To: vpp-dev <[email protected]> Subject: Re: [vpp-dev] Traffic is not put on IPSec tunnel intf ipip0 Hi, Below is the trace output for "unknown ip protocol" related drops for the ESP pkts coming from the strongswan to VPP. Let me know If I need to add some ip4-punt related config. show trace o/p =============== 00:08:29:451365: dpdk-input VirtualFuncEthernet0/7/0 rx queue 0 buffer 0x4c2d69: current data 0, length 170, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x1000001 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 0, nb_segs 1, pkt_len 170 buf_len 2176, data_len 170, ol_flags 0x180, data_off 128, phys_addr 0x4ecb5ac0 packet_type 0x691 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_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid Packet Types RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without extension headers RTE_PTYPE_L4_NONFRAG (0x0600) Non-fragmented IP packet IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556 IPSEC_ESP: 20.20.99.215 -> 20.20.99.99 tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN fragment id 0x8c7d, flags DONT_FRAGMENT 00:08:29:451372: ethernet-input frame: flags 0x3, hw-if-index 3, sw-if-index 3 IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556 00:08:29:451377: ip4-input IPSEC_ESP: 20.20.99.215 -> 20.20.99.99 tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN fragment id 0x8c7d, flags DONT_FRAGMENT 00:08:29:451380: ip4-lookup fib 1 dpo-idx 27 flow hash: 0x00000000 IPSEC_ESP: 20.20.99.215 -> 20.20.99.99 tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN fragment id 0x8c7d, flags DONT_FRAGMENT 00:08:29:451382: ip4-local IPSEC_ESP: 20.20.99.215 -> 20.20.99.99 tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN fragment id 0x8c7d, flags DONT_FRAGMENT 00:08:29:451383: ip4-punt IPSEC_ESP: 20.20.99.215 -> 20.20.99.99 tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN fragment id 0x8c7d, flags DONT_FRAGMENT 00:08:29:451384: error-punt rx:VirtualFuncEthernet0/7/0.1556 00:08:29:451386: punt ip4-local: unknown ip protocol On Mon, Mar 8, 2021 at 2:00 AM Vijay Kumar via lists.fd.io<http://lists.fd.io> <[email protected]<mailto:[email protected]>> wrote: 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<http://20.200.76.2/32> vpp# set interface state ipip0 up vpp# ip route add 20.200.75.1/32<http://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 (#18881): https://lists.fd.io/g/vpp-dev/message/18881 Mute This Topic: https://lists.fd.io/mt/81158278/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
