* Significant Dropped Packets on WG interface
@ 2020-05-14 7:05 Mike O'Connor
2020-05-14 9:15 ` Roman Mamedov
0 siblings, 1 reply; 5+ messages in thread
From: Mike O'Connor @ 2020-05-14 7:05 UTC (permalink / raw)
To: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Significant Dropped Packets on WG interface
2020-05-14 7:05 Significant Dropped Packets on WG interface Mike O'Connor
@ 2020-05-14 9:15 ` Roman Mamedov
2020-05-14 9:34 ` Mike O'Connor
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Roman Mamedov @ 2020-05-14 9:15 UTC (permalink / raw)
To: Mike O'Connor; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Significant Dropped Packets on WG interface
2020-05-14 9:15 ` Roman Mamedov
@ 2020-05-14 9:34 ` Mike O'Connor
2020-05-14 9:53 ` Mike O'Connor
2020-05-17 8:50 ` Mike O'Connor
2 siblings, 0 replies; 5+ messages in thread
From: Mike O'Connor @ 2020-05-14 9:34 UTC (permalink / raw)
To: Roman Mamedov; +Cc: WireGuard mailing list
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Significant Dropped Packets on WG interface
2020-05-14 9:15 ` Roman Mamedov
2020-05-14 9:34 ` Mike O'Connor
@ 2020-05-14 9:53 ` Mike O'Connor
2020-05-17 8:50 ` Mike O'Connor
2 siblings, 0 replies; 5+ messages in thread
From: Mike O'Connor @ 2020-05-14 9:53 UTC (permalink / raw)
To: Roman Mamedov; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Significant Dropped Packets on WG interface
2020-05-14 9:15 ` Roman Mamedov
2020-05-14 9:34 ` Mike O'Connor
2020-05-14 9:53 ` Mike O'Connor
@ 2020-05-17 8:50 ` Mike O'Connor
2 siblings, 0 replies; 5+ messages in thread
From: Mike O'Connor @ 2020-05-17 8:50 UTC (permalink / raw)
To: Roman Mamedov; +Cc: WireGuard mailing list
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.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-05-17 8:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-14 7:05 Significant Dropped Packets on WG interface Mike O'Connor
2020-05-14 9:15 ` Roman Mamedov
2020-05-14 9:34 ` Mike O'Connor
2020-05-14 9:53 ` Mike O'Connor
2020-05-17 8:50 ` Mike O'Connor
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.