Hi Pim, IIRC you should specify the endpoint on vpp1. At least it was true about a year ago. I even prepared a patch to enable this dynamic endpoint updating, but I don't remember what went wrong (there should be a reason why I didn't send it upstream).
Could you give it a try by specifying the endpoint on vpp1 while I'm trying to find that patch? On Mon, 10 Jan 2022 at 13:01, Pim van Pelt <p...@ipng.nl> wrote: > Hoi folks, > > On a reasonably recent VPP, I'm trying to create a Wireguard tunnel, it's > not working for me and I have a few questions (and found a few small bugs > along the way) - I'm hoping you can help me further :) > This is on two instances of VPP running on a hypervisor (KVM so interfaces > are virtio) and the version is *vpp v22.02-rc0~347-gb28df767d built by > pim on hippo at 2021-11-30T15:22:48* > > After bringing up basic connectivity, machine vpp1 has a > loopback 192.168.10.0 and vpp2 has a loopback 192.168.10.3 -- they can > reach each other fine, and there is no additional configuration (like ACLs > and such) -- > > vpp1# ping 192.168.10.3 > > 116 bytes from 192.168.10.3: icmp_seq=1 ttl=62 time=5.7011 ms > > 116 bytes from 192.168.10.3: icmp_seq=2 ttl=62 time=4.4814 ms > > 116 bytes from 192.168.10.3: icmp_seq=3 ttl=62 time=4.4962 ms > > 116 bytes from 192.168.10.3: icmp_seq=4 ttl=62 time=23.2758 ms > > 116 bytes from 192.168.10.3: icmp_seq=5 ttl=62 time=5.6050 ms > > > Statistics: 5 sent, 5 received, 0% packet loss > > > vpp1# wireguard create listen-port 50869 src 192.168.10.0 generate-key > > vpp1# set int state wg0 up > > vpp1# set int mtu packet 1420 wg0 > > vpp1# set interface ip address wg0 10.0.123.1/24 > > vpp1# set interface ip address wg0 2001:db8::1/64 > > > vpp1# show wireguard interface > > [0] wg0 src:192.168.10.0 port:50869 > private-key:CJ5whwpgaWQRFGfU6PzJXYs06ix8IOfrE63iKDSl9lU= > 089e70870a606964111467d4e8fcc95d8b34ea2c7c20e7eb13ade22834a5f655 > public-key:x3ULwpplNvNRq5vl0ejj9ixlA5vEMLjip5M89Jvv3F0= > c7750bc29a6536f351ab9be5d1e8e3f62c65039bc430b8e2a7933cf49befdc5d mac-key: > ce323661f94c40e14e6efcfd5ca4827e5d4ea53cdc3cd4c3b0413462de99b539 > > > vpp1# wireguard peer add wg0 public-key > qZz6XPwtrrEJw2rnzFHXYCm5KGm7+Cc9clpoP+B6kQc= allowed-ip 10.0.123.2/32 > > vpp1# show wireguard peer > > [0] endpoint:[192.168.10.0:50869->202c:8103:ab7f:0:ff00:::0] wg0 > keep-alive:0 flags: 0, api-clients count: 0 > > adj: > > key:qZz6XPwtrrEJw2rnzFHXYCm5KGm7+Cc9clpoP+B6kQc= > a99cfa5cfc2daeb109c36ae7cc51d76029b92869bbf8273d725a683fe07a9107 > > allowed-ips: 10.0.123.2/32 > > I noticed right off the bat that the endpoint seems > weird: 192.168.10.0:50869->202c:8103:ab7f:0:ff00:::0 is off considering > nothing has been configured on machine vpp2 yet. That sounds like a > formatting bug to me, so I continued with the other machine: > > vpp2# wireguard create listen-port 50869 src 192.168.10.3 generate-key > > vpp2# set int state wg0 up > > vpp2# set int mtu packet 1420 wg0 > > vpp2# set interface ip address wg0 10.0.123.2/24 > > vpp2# set interface ip address wg0 2001:db8::2/64 > > > vpp2# wireguard peer add wg0 public-key > x3ULwpplNvNRq5vl0ejj9ixlA5vEMLjip5M89Jvv3F0= allowed-ip 10.0.123.0/24 > port 50869 endpoint 192.168.10.0 > > vpp2# show wireguard peer > > [0] endpoint:[192.168.10.3:50869->192.168.10.0:50869] wg0 keep-alive:0 > flags: 0, api-clients count: 0 > > adj: > > key:x3ULwpplNvNRq5vl0ejj9ixlA5vEMLjip5M89Jvv3F0= > c7750bc29a6536f351ab9be5d1e8e3f62c65039bc430b8e2a7933cf49befdc5d > > allowed-ips: 10.0.123.0/24 > > Observations: > * On vpp2, the relationship seems correct to me 192.168.10.3:50869-> > 192.168.10.0:50869 but on vpp1, the relationship is > still 192.168.10.0:50869->202c:8103:ab7f:0:ff00:::0 > * If I don't specify an "allowed-ip" argument, VPP crashes. It seems we > can catch that and return an error instead. > * The usage of 'wireguard peer add' claims the argument is 'dst-port', but > it's "port" instead. There's also a formatting error there (between > <pub_key_other> and endpoint, missing space: > > wireguard peer add <wg_int> public-key <pub_key_other>endpoint <ip4_dst> > allowed-ip <prefix>dst-port [port_dst] persistent-keepalive > [keepalive_interval] > > The tunnel is not functional, If I look at the connection between vpp1 and > vpp2, I do see that vpp2 is sending handshake packets: > > pim@hvn0:/srv/kvm$ sudo tcpdump -evni vpp1-vpp2 udp and port 50869 > > tcpdump: listening on vpp1-vpp2, link-type EN10MB (Ethernet), snapshot > length 262144 bytes > > 12:51:28.929809 52:54:00:02:10:01 > 52:54:00:01:10:02, ethertype IPv4 > (0x0800), length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > 12:51:33.945859 52:54:00:02:10:01 > 52:54:00:01:10:02, ethertype IPv4 > (0x0800), length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > 12:51:39.216163 52:54:00:02:10:01 > 52:54:00:01:10:02, ethertype IPv4 > (0x0800), length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > 12:51:44.357225 52:54:00:02:10:01 > 52:54:00:01:10:02, ethertype IPv4 > (0x0800), length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > But vpp1 is not receiving them. Show errors and show logging gives me no > reasonable leads. Can somebody help me figure this out ? > > groet, > Pim > -- > Pim van Pelt <p...@ipng.nl> > PBVP1-RIPE - http://www.ipng.nl/ > > > > -- Best regards Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20698): https://lists.fd.io/g/vpp-dev/message/20698 Mute This Topic: https://lists.fd.io/mt/88321357/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
