Significant Dropped Packets on WG interface

Significant Dropped Packets on WG interface

[Mike O'Connor]

Hi All

For the last few weeks my Wireguard link which I use to as my default
gateway has been having issues with TCP connections stalling.

I've been trying to work out what is wrong. I just noticed that the
Wireguard link has dropped packets at both ends.

wg-p2p    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:104.127.123.10  P-t-P:103.127.123.10 
Mask:255.255.255.248
          inet6 addr: 2506:c500:ff4:1::ab/64 Scope:Global
          inet6 addr: fe80::e6/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:141849 errors:0 dropped:5915 overruns:0 frame:0
          TX packets:141626 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:33771496 (33.7 MB)  TX bytes:14348632 (14.3 MB)

wg-p2p    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:104.127.123.9  P-t-P:103.127.123.9  Mask:255.255.255.248
          inet6 addr: 2506:c500:ff4:1::aa/64 Scope:Global
          inet6 addr: fe80::dc/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:663287 errors:1 dropped:1433 overruns:0 frame:1
          TX packets:1023948 errors:594 dropped:13 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:110192140 (110.1 MB)  TX bytes:872273836 (872.2 MB)

Note the above is after a reboot of both end points (about 4 mins)

One end is running a 4.4.0 kernel

ii  wireguard                            
1.0.20200510-1~16.04                            all          fast,
modern, secure kernel VPN tunnel (metapackage)
ii  wireguard-dkms                       
1.0.20200429-2~16.04                            all          fast,
modern, secure kernel VPN tunnel (DKMS version)
ii  wireguard-tools                      
1.0.20200510-1~16.04                            i386         fast,
modern, secure kernel VPN tunnel (userland utilities)

The other is

ii  wireguard                                
1.0.20200319-1ubuntu1~14.04                          all          fast,
modern, secure kernel VPN tunnel (metapackage)
ii  wireguard-dkms                           
1.0.20200429-1~14.04                                 all          fast,
modern, secure kernel VPN tunnel (DKMS version)
ii  wireguard-tools                          
1.0.20200319-1ubuntu1~14.04                          amd64        fast,
modern, secure kernel VPN tunnel (userland utilities)

I was thinking of rebuilding the ubuntu 14.04 to a 16.04 (18.04 uses
netplan and can be a real pain to setup)


I've done my best to check the underlying Internet and I do not think
packets are be dropped in general or between the two end points.

How do I tell why the packets have been dropped ?

What do I need to look at to try to fix this ?


Thanks

Mike

Re: Significant Dropped Packets on WG interface

[Roman Mamedov]

On Thu, 14 May 2020 16:35:30 +0930
Mike O'Connor <mike@pineview.net> wrote:

> Hi All
> 
> For the last few weeks my Wireguard link which I use to as my default
> gateway has been having issues with TCP connections stalling.
> 
> I've been trying to work out what is wrong. I just noticed that the
> Wireguard link has dropped packets at both ends.
> 
> wg-p2p    Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>           inet addr:104.127.123.10  P-t-P:103.127.123.10 
> Mask:255.255.255.248
>           inet6 addr: 2506:c500:ff4:1::ab/64 Scope:Global
>           inet6 addr: fe80::e6/64 Scope:Link
>           UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

Reduce MTU of the WG interfaces to accomodate for overhead. See 
https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg01856.html for
calculations of by how much.

>           inet6 addr: 2506:c500:ff4:1::aa/64 Scope:Global

I wonder what's this IP range, is this some VPN service? Squatting on
unassigned IPs within 2000::/3 seems like a very bad practice. If they wanted
an imaginary GUA for their NAT66, I'd suggest something like 66::/16 instead.

-- 
With respect,
Roman

Re: Significant Dropped Packets on WG interface

[Mike O'Connor]

> Reduce MTU of the WG interfaces to accomodate for overhead. See 
> https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg01856.html for
> calculations of by how much.
Ok but why all of a sudden, I'll go thought the process again and see.
>>           inet6 addr: 2506:c500:ff4:1::aa/64 Scope:Global
> I wonder what's this IP range, is this some VPN service? Squatting on
> unassigned IPs within 2000::/3 seems like a very bad practice. If they wanted
> an imaginary GUA for their NAT66, I'd suggest something like 66::/16 instead.
>
I have a ipv6 range allocated, I changed the ip before posting.

I'm routing my part of my class C and a small part of my ipv6 range from
my DC to my home.

Mike

Re: Significant Dropped Packets on WG interface

[Mike O'Connor]

Hi

> Reduce MTU of the WG interfaces to accomodate for overhead. See 
> https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg01856.html for
> calculations of by how much.

So yes it was, but I can not understand why. I worked out the MTU be
pinging back from the VPN server to the clients external ip address.

Its way less than it should be at 1472, I think my ISP has made a change
which broke things.

I did do some MTU testing emailing before but I think I messed it up.


Thanks

Mike

Re: Significant Dropped Packets on WG interface

[Mike O'Connor]

Hi All

So after dropping all the way down to 1364 I'm still getting a lot of
dropped packets, only at one end.

A ping test using 'ping -M do -s 1472 IP' works from both directions but
1473 does not.

I really think there is something else wrong, but I had no idea what.

Mike

On 14/5/20 6:45 pm, Roman Mamedov wrote:
> On Thu, 14 May 2020 16:35:30 +0930
> Mike O'Connor <mike@pineview.net> wrote:
>
>> Hi All
>>
>> For the last few weeks my Wireguard link which I use to as my default
>> gateway has been having issues with TCP connections stalling.
>>
>> I've been trying to work out what is wrong. I just noticed that the
>> Wireguard link has dropped packets at both ends.
>>
>> wg-p2p    Link encap:UNSPEC  HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>>           inet addr:104.127.123.10  P-t-P:103.127.123.10 
>> Mask:255.255.255.248
>>           inet6 addr: 2506:c500:ff4:1::ab/64 Scope:Global
>>           inet6 addr: fe80::e6/64 Scope:Link
>>           UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
> Reduce MTU of the WG interfaces to accomodate for overhead. See 
> https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg01856.html for
> calculations of by how much.
>
>>           inet6 addr: 2506:c500:ff4:1::aa/64 Scope:Global
> I wonder what's this IP range, is this some VPN service? Squatting on
> unassigned IPs within 2000::/3 seems like a very bad practice. If they wanted
> an imaginary GUA for their NAT66, I'd suggest something like 66::/16 instead.
>