Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Roman Mamedov <rm.wg@romanrm.net>
To: wireguard@lists.zx2c4.com
Subject: Mixed MTU hosts on a network
Date: Fri, 16 Mar 2018 14:25:47 +0500	[thread overview]
Message-ID: <20180316142547.2ecb70de@natsu> (raw)

Hello,

I have a host which is on PPPoE and has 1492 as underlying MTU.

When WireGuard starts by default, it sets MTU of its interface to 1420. All
TCP connections trying to send a stream of data over the WG interface to that
host, hang up (I test with iperf3).

My first idea was to override the MTU for this specific host via adding a
route:

# ip -6 route add fd39:30::250/128 dev wg0 mtu 1412 metric 1

# ip -6 route | grep ^fd39:30
fd39:30::250 dev wg0  metric 1  mtu 1412
fd39:30::/64 dev wg0  proto kernel  metric 256

# ip route get fd39:30::250
fd39:30::250 from :: dev wg0  src fd39:30::2  metric 1  mtu 1412

However, this does not help at all. Even adding the corresponding route on the
other side. Even using the "mtu lock" keyword instead of just "mtu". I am still
puzzled why. Any ideas?

=========================================
# iperf3 -c fd39:30::250
Connecting to host fd39:30::250, port 5201
[  4] local fd39:30::2 port 44902 connected to fd39:30::250 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   474 KBytes  3.88 Mbits/sec    1   1.31 KBytes       
[  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.31 KBytes       
[  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    1   1.31 KBytes       
[  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   1.31 KBytes       
[  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    1   1.31 KBytes       
[  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.31 KBytes       
[  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   1.31 KBytes       
[  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.31 KBytes       
[  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.31 KBytes       
[  4]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    1   1.31 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   474 KBytes   388 Kbits/sec    5             sender
[  4]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver

iperf Done.
=========================================

What helps, is only reducing MTU of the entire wg0 interface to 1412. Then
everything works fine. But it doesn't feel optimal to reduce MTU of the entire
network just because of 1 or 2 hosts. I would rather use a couple of those
mtu-override routes, if they worked.

-- 
With respect,
Roman

             reply	other threads:[~2018-03-16  9:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-16  9:25 Roman Mamedov [this message]
2018-03-16  9:35 ` Matthias Ordner
2018-03-16 10:53   ` Roman Mamedov
2018-03-16 16:20     ` Roman Mamedov
2018-03-16 10:01 ` Kalin KOZHUHAROV
2018-03-26 19:12 ` Luis Ressel
2018-04-14  1:38 ` Jason A. Donenfeld
2018-04-14  2:40   ` Jason A. Donenfeld
2018-04-14 13:16     ` Jason A. Donenfeld
2018-04-14 13:40       ` Roman Mamedov
2018-04-14 14:15         ` Jason A. Donenfeld
2018-04-14 14:38           ` Roman Mamedov
2018-04-14 14:45             ` Jason A. Donenfeld
2018-04-14 15:20               ` Roman Mamedov
2018-04-14 23:08                 ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180316142547.2ecb70de@natsu \
    --to=rm.wg@romanrm.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).