Hi Vijay,
Looking at your packet trace it looks to me you have bad key materials for
decrypt and integrity:
IP6_NONXT: 242.163.36.86 -> 70.168.225.19
version 1, header length 8
tos 0x34, ttl 245, length 22137, checksum 0x5156 (should be 0x972a) dscp
unknown ecn NON_ECN
fragment id 0x0000 offset 320
This looks like a decrypt failure.
How did you configure your SAs? Check the config with 'show ipsec all' etc.
Best
ben
> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of Vijay Kumar
> Sent: mardi 23 mars 2021 04:18
> To: Neale Ranns <[email protected]>
> Cc: vpp-dev <[email protected]>
> Subject: Re: [vpp-dev] GRE-over-IPSec fails
>
> Hi Neale,
>
> Could you let me know if you faced the mentioned problem anytime?
>
> For me only IPSec works fine, Only GRE also works fine. But when I
> configure GRE-over-IPSec, the traffic is dropped at esp4-decrypt-tun due
> to integrity check failure.
> As there are two logical interfaces created at VPP (ipip0 and gre0) for
> the peer, do I need to take care of something specially? As far as I know,
> I haven't missed any config.
>
>
> Regards,
> Vijay Kumar N
>
> On Mon, Mar 22, 2021 at 11:31 PM Vijay Kumar via lists.fd.io
> <http://lists.fd.io> <[email protected]
> <mailto:[email protected]> > wrote:
>
>
> Hi,
>
> I am trying a test case where-in I have an GRE P2MP (mGRE) tunnel on
> the VPP. The GRE peer is a strongswan VM that hosts both the GRE tunnel
> and IPSec SA. When I started ping traffic from SS, the traffic is dropped
> at esp4-decrypt-tun graph node due to integrity check failure.
>
> Has any one tested GRE-over-IPSec recently? If so can you pls share
> me a working config. If not please review the below config and let me know
> if I missed something
>
> NOTE: -
> If I have run only GRE test case, traffic is fine (no IPSec
> enabled). If I have only IPSec configured but no GRE then also traffic is
> fine.
>
> I am facing this issue only when both GRE and IPSec are enabled at
> the same time.
>
>
> Topology and config at SS and VPP
> ==============================
> Strongswan VM (20.20.99.215, gre peer 2.2.2.1, loopback 7.7.7.7)
> <=============> VPP cluster (20.20.99.99, gre peer 2.2.2.2, loopback
> 8.8.8.8)
> IPSec SA Traffic Selector (7.7.7.7/32 <http://7.7.7.7/32> to
> 8.8.8.8/32 <http://8.8.8.8/32> )
> ike=aes256-sha256-modp2048!
>
> esp=aes256-sha1-noesn!
>
>
>
> Below is the VPP trace
> ================
> 03:20:34:670201: dpdk-input
> VirtualFuncEthernet0/7/0 rx queue 0
> buffer 0x4c6b91: current data 0, length 170, buffer-pool 0, ref-
> count 1, totlen-nifb 0, trace handle 0x1000000
> 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 0xa3dae4c0
> 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 0x5b33 dscp CS0 ecn
> NON_ECN
> fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670208: 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
> 03:20:34:670214: ip4-input
> IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
> tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn
> NON_ECN
> fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670218: ip4-lookup
> fib 1 dpo-idx 21 flow hash: 0x00000000
> IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
> tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn
> NON_ECN
> fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670220: ip4-local
> IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
> tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn
> NON_ECN
> fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670222: ipsec4-tun-input
> IPSec: remote:20.20.99.215 spi:305419897 (0x12345679) seq 40 sa 1
> 03:20:34:670225: esp4-decrypt-tun
> esp: crypto aes-cbc-256 integrity sha1-96 pkt-seq 40 sa-seq 0 sa-
> seq-hi 0
> 03:20:34:670241: ip4-drop
> IP6_NONXT: 242.163.36.86 -> 70.168.225.19
> version 1, header length 8
> tos 0x34, ttl 245, length 22137, checksum 0x5156 (should be
> 0x972a) dscp unknown ecn NON_ECN
> fragment id 0x0000 offset 320
> 03:20:34:670243: error-drop
> rx:ipip0
> 03:20:34:670244: drop
> esp4-decrypt-tun: Integrity check failed
>
>
>
> vpp# show node counters
> Count Node Reason
> 25 esp4-encrypt-tun ESP pkts received
> 213 memif-input not ip packet
> 3 dpdk-input no error
> 136 arp-reply ARP replies sent
> 3 arp-reply IP4 source address
> not local to subnet
> 1 gre4-input no error
> 213 ip4-udp-lookup No error
> 42 esp4-decrypt-tun ESP pkts received
> 42 esp4-decrypt-tun Integrity check
> failed
> 25 esp4-encrypt-tun ESP pkts received
> 42 ipsec4-tun-input good packets
> received
> 11 ip4-local ip4 source lookup
> miss
> 3 ip4-local unknown ip
> protocol
> 3 ethernet-input unknown vlan
> vpp#
>
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18998): https://lists.fd.io/g/vpp-dev/message/18998
Mute This Topic: https://lists.fd.io/mt/81531694/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
