Re: Significant Dropped Packets on WG interface

2020-05-14 Thread 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

2020-05-14 Thread 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

2020-05-14 Thread Roman Mamedov
On Thu, 14 May 2020 16:35:30 +0930
Mike O'Connor  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


Significant Dropped Packets on WG interface

2020-05-14 Thread 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