On 2019/06/07 23:42, Heinrich Rebehn wrote: > > > > On 7. Jun 2019, at 22:38, Stuart Henderson <[email protected]> wrote: > > > > On 2019-06-07, Heinrich Rebehn <[email protected]> wrote: > >> Hi list, > >> > >> Doing tcpdump(8) on a wireguard tunnel yields: > >> > >> -------------------------------------------------------------------------------- > >> # tcpdump -n -i tun0 icmp6 > >> tcpdump: listening on tun0, link-type LOOP > >> 18:44:34.742106 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > >> request [flowlabel 0xb6f77] > >> 18:44:34.754246 bad-ip-version 6 > >> 18:44:35.802498 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > >> request [flowlabel 0xb6f77] > >> 18:44:35.814841 bad-ip-version 6 > >> 18:44:36.860380 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > >> request [flowlabel 0xb6f77] > >> 18:44:36.872536 bad-ip-version 6 > >> 18:44:37.917605 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > >> request [flowlabel 0xb6f77] > >> 18:44:37.929694 bad-ip-version 6 > >> > >> Huh? I thought that 6 is the current version? ;-) > > > > But v4+NAT/CGNAT is the will of the people! > > > >> Also, the echo replies are not shown, although I know they exist. Is there > >> a known problem with tcpdump(8) on wireguard tunnels? > > > > The replies are clearly the packets ~120ms after the echo requests > > that are shown as 'bad-ip-version-6'. > > > > It might be something wrong with the parser in tcpdump, or it might be > > something wrong with wg. Can you put a pcap online somewhere? > > (tcpdump -itun0 -s2000 -w /tmp/wg.pcap) > > > > > > Since the file is only 632 bytes big, I chose to simply uuencode and paste > into this mail: > > begin-base64 644 wg.pcap > 1MOyoQIABAAAAAAAAAAAANAHAAAMAAAALNf6XKA6CQA8AAAAPAAAAAAAABhgDGlGABA6QCABBHB2 > UwAFAAAAAAAAABEgAQY4Bg8BEAAAAAAAAQACgAALEz0lAABc+td6AAk6ySzX+lwLagkAPAAAADwA > AAAAAAACYAU4vAAQOjggAQY4Bg8BEAAAAAAAAQACIAEEcHZTAAUAAAAAAAAAEYEAChM9JQAAXPrX > egAJOskt1/pcFU8KADwAAAA8AAAAAAAAGGAMaUYAEDpAIAEEcHZTAAUAAAAAAAAAESABBjgGDwEQ > AAAAAAABAAKAAAhmPSUAAVz613sACj1zLdf6XAB+CgA8AAAAPAAAAAAAAAJgBTi8ABA6OCABBjgG > DwEQAAAAAAABAAIgAQRwdlMABQAAAAAAAAARgQAHZj0lAAFc+td7AAo9cy7X+lzMYAsAPAAAADwA > AAAAAAAYYAxpRgAQOkAgAQRwdlMABQAAAAAAAAARIAEGOAYPARAAAAAAAAEAAoAABoM9JQACXPrX > fAALP1Mu1/pczpALADwAAAA8AAAAAAAAAmAFOLwAEDo4IAEGOAYPARAAAAAAAAEAAiABBHB2UwAF > AAAAAAAAABGBAAWDPSUAAlz613wACz9TL9f6XGRXDAA8AAAAPAAAAAAAABhgDGlGABA6QCABBHB2 > UwAFAAAAAAAAABEgAQY4Bg8BEAAAAAAAAQACgAAW6T0lAANc+td9AAwu6i/X+lzuhwwAPAAAADwA > AAAAAAACYAU4vAAQOjggAQY4Bg8BEAAAAAAAAQACIAEEcHZTAAUAAAAAAAAAEYEAFek9JQADXPrX > fQAMLuo= > ==== > > MD5 (wg.pcap) = df36e7fa6e7a7d80e9185e96aae51fed > > Hope this is ok. Thanks for help! > > BTW, the replies are happily accepted by the ping program running on my > iPhone (HE.NET Network Tools 1.6.5.337) > > -Heinrich >
Packets captured on "tun" interfaces have an extra header which includes the address family. In the echo request packets from your capture this is correctly set to IPv6 which matches the inner IP packet so that's ok. In the replies (i.e. incoming packets) this is set to IPv4; so in tcpdump the inner packet is passed to an IPv4 decode routine, the address family on this inner packet doesn't match, so the bad-ip-version-6 message is printed. I think this version number is something that wireguard is setting. Are you using wireguard-go or some other implementation? Looking at the code wireguard-go does look like it's trying to set this correctly but I'm unsure whether it actually works (and the scaffolding for building go things in ports is a bit of a mess and doesn't work with the standard methods to rebuild with patches so it's not quick and easy to test things out..)
