I captured a trace of an incoming ping packet, and I have included it below.

This is a ping from 192.168.42.7 (remote wireguard peer, tunnel
address) to 192.168.42.6 ( local vpp host, tunnel address )

It appears everything is good all the way through the punt stage, but
for some reason the packet that's written to the tap7 interface ends
up being the encrypted wireguard packet, not the unencrypted ping
packet that had been previously processed that lead to the punt stage.

-Landy

00:11:16:258487: dpdk-input
  TenGigabitEthernet1/0/0 rx queue 0
  buffer 0x4b0273: current data 0, length 170, buffer-pool 0,
ref-count 1, trace handle 0x1000047
                   ext-hdr-valid
  PKT MBUF: port 0, nb_segs 1, pkt_len 170
    buf_len 2176, data_len 170, ol_flags 0x180, data_off 128,
phys_addr 0x3c09d40
    packet_type 0x211 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_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt.
      PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
      PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt.
    Packet Types
      RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
      RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
      RTE_PTYPE_L4_UDP (0x0200) UDP packet
  IP4: e0:0e:da:a9:01:0d -> 3c:ec:ef:28:9c:70
  UDP: 10.255.1.49 -> 207.188.7.26
    tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
    fragment id 0x29f4
  UDP: 51822 -> 51820
    length 136, checksum 0x7aa1
00:11:16:258487: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  IP4: e0:0e:da:a9:01:0d -> 3c:ec:ef:28:9c:70
00:11:16:258499: ip4-input-no-checksum
  UDP: 10.255.1.49 -> 207.188.7.26
    tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
    fragment id 0x29f4
  UDP: 51822 -> 51820
    length 136, checksum 0x7aa1
00:11:16:258510: ip4-lookup
  fib 0 dpo-idx 10 flow hash: 0x00000000
  UDP: 10.255.1.49 -> 207.188.7.26
    tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
    fragment id 0x29f4
  UDP: 51822 -> 51820
    length 136, checksum 0x7aa1
00:11:16:258524: ip4-receive
    UDP: 10.255.1.49 -> 207.188.7.26
      tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
      fragment id 0x29f4
    UDP: 51822 -> 51820
      length 136, checksum 0x7aa1
00:11:16:258539: ip4-udp-lookup
  UDP: src-port 51822 dst-port 51820
00:11:16:258555: wg4-input
  Wireguard input:
    Type: Data
    Peer: 0
    Length: 96
    Keepalive: false
00:11:16:258576: ip4-input-no-checksum
  ICMP: 192.168.42.7 -> 192.168.42.6
    tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
    fragment id 0x4f4c, flags DONT_FRAGMENT
  ICMP echo_request checksum 0x5c07 id 11
00:11:16:258593: ip4-lookup
  fib 0 dpo-idx 18 flow hash: 0x00000000
  ICMP: 192.168.42.7 -> 192.168.42.6
    tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
    fragment id 0x4f4c, flags DONT_FRAGMENT
  ICMP echo_request checksum 0x5c07 id 11
00:11:16:258612: ip4-receive
    ICMP: 192.168.42.7 -> 192.168.42.6
      tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
      fragment id 0x4f4c, flags DONT_FRAGMENT
    ICMP echo_request checksum 0x5c07 id 11
00:11:16:258632: ip4-icmp-input
  ICMP: 192.168.42.7 -> 192.168.42.6
    tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
    fragment id 0x4f4c, flags DONT_FRAGMENT
  ICMP echo_request checksum 0x5c07 id 11
00:11:16:258652: ip4-punt
    ICMP: 192.168.42.7 -> 192.168.42.6
      tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
      fragment id 0x4f4c, flags DONT_FRAGMENT
    ICMP echo_request checksum 0x5c07 id 11
00:11:16:258674: ip4-punt-redirect
  via redirect:6
00:11:16:258696: ip4-dvr-dpo
     sw_if_index:8
00:11:16:258719: ip4-dvr-reinject
     sw_if_index:8
00:11:16:258766: tap7-output
  tap7
  IP4: e0:0e:da:a9:01:0d -> 3c:ec:ef:28:9c:70
  UDP: 10.255.1.49 -> 207.188.7.26
    tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
    fragment id 0x29f4
  UDP: 51822 -> 51820
    length 136, checksum 0x7aa1

On Wed, Oct 19, 2022 at 11:26 PM Landy Bible via lists.fd.io
<landy=ljb2of3....@lists.fd.io> wrote:
>
> Hey All,
>
> I'm having some trouble passing a wireguard connection into the
> kernel. I'm new to VPP, but my goal is to set up a series of FRR / VPP
> routers running OSPF, BGP, and wireguard to connect several
> datacenters and do internet peering for any anycast project.
>
> I am using VPP 22.06 on Ubuntu 20.04, with Intel X550T NICs.
>
> I'm using Pim Van Pelt's lcpng_nl and lcpng_if plugins to connect the
> linux control plane, and that seems to be working fine for my physical
> interfaces. I tried the built-in linux_cp and linux_nl plugins, but
> the netlink plugin specifically seemed to get the startup process
> stuck in a loop of adding the interface pairs over and over again and
> I wasn't able to contact the host over the network.
>
> I've run into a problem when adding the wireguard interface though. It
> connects to the remote side just fine (an ubuntu 20.04 server, not
> running vpp). From the non-vpp server I can ping the vpp interface,
> and from within vpp I can ping the remote side. However, when adding
> the LCP pair I _cannot_ ping the remote side from linux. If I disable
> the VPP ping plugin then the remote side stops being able to ping the
> VPP server since VPP is no longer responding.
>
> VPP config:
>
> wireguard create listen-port 51820 private-key <private_key> src 
> <vpp-public-ip>
> lcp create wg0 host-if wg1-0-0
> set interface state wg0 up
> set interface mtu packet 1420 wg0
> # set interface ip address wg0 192.168.42.6/31
> wireguard peer add wg0 public-key <public_key> endpoint
> <remote-public-ip> allowed-ip 0.0.0.0/0 dst-port 51822
> persistent-keepalive 25
>
> I ran tcpdump on the VPP server side while pinging from the remote
> host and noticed something odd. Instead of receiving decapsulated
> packets on the kernel interface, I seem to be seeing the encrypted
> packets, and it's complaining about 16 bytes missing from the packet.
> I did notice that the source IP <remote-router-ip> is NOT the
> <remote-public-ip>, but instead a private IP that's used on that
> routers /31 link with the upstream router. I'm not sure if that makes
> a difference to the packet processing or not.
>
> root@vpp-host:~# tcpdump -i wg1-0-0 -v
> tcpdump: listening on wg1-0-0, link-type EN10MB (Ethernet), capture
> size 262144 bytes
> 03:50:30.355637 IP truncated-ip - 16 bytes missing! (tos 0x0, ttl 60,
> id 16433, offset 0, flags [none], proto UDP (17), length 156)
>    <remote-router-ip>.51822 > <vpp-public-ip>.51820: UDP, length 128
> 03:50:31.379675 IP truncated-ip - 16 bytes missing! (tos 0x0, ttl 60,
> id 16549, offset 0, flags [none], proto UDP (17), length 156)
>    <remote-router-ip>.51822 > <vpp-public-ip>.51820: UDP, length 128
> 03:50:32.403509 IP truncated-ip - 16 bytes missing! (tos 0x0, ttl 60,
> id 16776, offset 0, flags [none], proto UDP (17), length 156)
>    <remote-router-ip>.51822 > <vpp-public-ip>.51820: UDP, length 128
> 03:50:33.427508 IP truncated-ip - 16 bytes missing! (tos 0x0, ttl 60,
> id 17027, offset 0, flags [none], proto UDP (17), length 156)
>    <remote-router-ip>.51822 > <vpp-public-ip>.51820: UDP, length 128
> 03:50:34.451562 IP truncated-ip - 16 bytes missing! (tos 0x0, ttl 60,
> id 17165, offset 0, flags [none], proto UDP (17), length 156)
>    <remote-router-ip>.51822 > <vpp-public-ip>.51820: UDP, length 128
>
> Does anybody have any ideas? I can't imagine that I'm the first person
> to want to create an LCP interface for a wireguard tunnel.
>
> Thanks,
> Landy
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22058): https://lists.fd.io/g/vpp-dev/message/22058
Mute This Topic: https://lists.fd.io/mt/94447618/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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to