Hi Landy, The packet you're receiving is probably not encrypted. You can see that it was successfully decrypted after wg4-input because the trace shows the inside addresses (192.168.42.7 -> 192.168.42.6). None of the nodes after that point would have encrypted it again. The likely explanation is that the buffer that the packet was written to still contains the outside ethernet and IP headers, the inside packet was decrypted in place and a current_data field was set with the offset of that packet. Since the packet gets handed off to an L2 tap interface, the tap output node finds and uses the original L2 headers. The decrypted packet is likely still sitting in the payload.
When you create the linux-cp pair for an L3 tunnel interface, you need to add the keyword 'tun' to the command. By default a tap (L2) interface is created. Adding 'tun' to the command will create a tun (L3) interface. If you do this, everything is likely to work as expected. -Matt On Thu, Oct 20, 2022 at 2:15 PM Landy Bible <la...@ljb2of3.net> wrote: > 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 (#22059): https://lists.fd.io/g/vpp-dev/message/22059 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] -=-=-=-=-=-=-=-=-=-=-=-
