> On 9. Jun 2019, at 19:41, Stuart Henderson <[email protected]> wrote:
>
> 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 buildings
> 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..)
>
Yes, I am using wireguard-go, I was not aware of other implementations.
wireguard-go-0.0.20190517 implementation of WireGuard in Go
wireguard-tools-0.0.20190406p1 fast and secure VPN
If we are unsure wether the error is caused by wireguard, i could do a ktrace
to see what it is sending to tun0, but i am neither too familiar with ktrace
nor with the packet format. What should I be looking for? send(2)?
-Heinrich
PS. Might this be what we are looking for? 46.142.231.196:53138 is the iPhone.
71735 wireguard-go STRU struct sockaddr { AF_INET, 46.142.231.196:53138 }
71735 wireguard-go GIO fd 8 wrote 96 bytes
"\^D\0\0\0)~>Pd\0\0\0\0\0\0\0\M-9\M^U\M-ljl\M^S4\M^S\M-}\M-N\v\M-I\M^S\M^H\\\M^X\M-{\M-uw\M^X(\
\M-2U\M^Z\M^RK\M-y\M^Y*u\M-:Uw\M-{'\^BH\M-E\M-w)\M-7\M-8\M-,W\M-3\M^W\M-?\M^R}\M-m\M-L\M-r0\^Q\
\M-Z\M-E\^C\M-Bb\M-^m\^[\M-x\M-H\M-'\M^_"\M^O\M-AK\M-HeWg7\M^A\M-;p?\M^T"
7
