Development discussion of WireGuard
 help / color / mirror / Atom feed
From: zrm <zrm@trustiosity.com>
To: wireguard@lists.zx2c4.com
Subject: Re: WG can now be fragmented -- great!
Date: Fri, 24 May 2019 11:17:53 -0400	[thread overview]
Message-ID: <9f1123cc-8796-3b76-f452-09f080a296ce@trustiosity.com> (raw)
In-Reply-To: <20190524134817.2c0e73d2@natsu>

On 5/24/19 04:48, Roman Mamedov wrote:
> Hello,
> 
> Just wanted to share my excitement about
> https://git.zx2c4.com/WireGuard/diff/?id=57a8ca7f49b5e70aae18b8b5a70cde8f9e4a9346&id2=7cf2dae97635c8c20a8943522bab2b56c6885c8d
> 
> This means WG packets can now be fragmented, and as such we can use arbitrary
> large MTU inside WG. This in turn means we can now use WG to transport full
> 9000 MTU VXLAN frames over the Internet:
> 
> # ifconfig wg10
> wg10      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>            inet6 addr: fd39:aa:6089:5d42:7900:fcd:12a3:6181/64 Scope:Global
>            UP POINTOPOINT RUNNING NOARP  MTU:9070  Metric:1
>            RX packets:12405 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:11130 errors:17 dropped:2 overruns:0 carrier:8
>            collisions:0 txqueuelen:1000
>            RX bytes:81966214 (78.1 MiB)  TX bytes:45563644 (43.4 MiB)
> 
> # ifconfig xwg10
> xwg10     Link encap:Ethernet  HWaddr 02:79:00:0f:cd:12
>            inet addr:10.123.0.250  Bcast:10.123.0.255  Mask:255.255.255.0
>            inet6 addr: fe80::79:ff:fe0f:cd12/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
>            RX packets:12369 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:9577 errors:9 dropped:0 overruns:0 carrier:9
>            collisions:0 txqueuelen:1000
>            RX bytes:80678848 (76.9 MiB)  TX bytes:44408417 (42.3 MiB)
> 
> # ping 10.123.0.1 -s 8972 -M do
> PING 10.123.0.1 (10.123.0.1) 8972(9000) bytes of data.
> 8980 bytes from 10.123.0.1: icmp_seq=1 ttl=64 time=78.7 ms
> 8980 bytes from 10.123.0.1: icmp_seq=2 ttl=64 time=77.2 ms
> 8980 bytes from 10.123.0.1: icmp_seq=3 ttl=64 time=82.0 ms
> 8980 bytes from 10.123.0.1: icmp_seq=4 ttl=64 time=77.5 ms
> ^C
> --- 10.123.0.1 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3003ms
> rtt min/avg/max/mdev = 77.214/78.881/82.054/1.940 ms
> 
> 08:39:47.573368 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (0|1440) 710 > 710: UDP, bad length 9102 > 1432
> 08:39:47.573371 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (1440|1440)
> 08:39:47.573374 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (2880|1440)
> 08:39:47.573376 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (4320|1440)
> 08:39:47.573378 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (5760|1440)
> 08:39:47.573380 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (7200|1440)
> 08:39:47.573383 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (8640|470)
> 08:39:48.575079 IP6 dynamic-2a02-2698-8024-0.tmn.ertelecom.ru > rin.romanrm.net: frag (0|1440) 710 > 710: UDP, bad length 9102 > 1432
> 08:39:48.575189 IP6 dynamic-2a02-2698-8024-0.tmn.ertelecom.ru > rin.romanrm.net: frag (1440|1440)
> 08:39:48.575339 IP6 dynamic-2a02-2698-8024-0.tmn.ertelecom.ru > rin.romanrm.net: frag (2880|1440)
> 08:39:48.575448 IP6 dynamic-2a02-2698-8024-0.tmn.ertelecom.ru > rin.romanrm.net: frag (4320|1440)
> 08:39:48.575565 IP6 dynamic-2a02-2698-8024-0.tmn.ertelecom.ru > rin.romanrm.net: frag (5760|1440)
> 08:39:48.575691 IP6 dynamic-2a02-2698-8024-0.tmn.ertelecom.ru > rin.romanrm.net: frag (7200|1440)
> 08:39:48.575693 IP6 dynamic-2a02-2698-8024-0.tmn.ertelecom.ru > rin.romanrm.net: frag (8640|470)
> 08:39:48.575828 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (0|1440) 710 > 710: UDP, bad length 9102 > 1432
> 08:39:48.575831 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (1440|1440)
> 08:39:48.575833 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (2880|1440)
> 08:39:48.575834 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (4320|1440)
> 08:39:48.575837 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (5760|1440)
> 08:39:48.575838 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (7200|1440)
> 08:39:48.575840 IP6 rin.romanrm.net > dynamic-2a02-2698-8024-0.tmn.ertelecom.ru: frag (8640|470)
> 
> I also briefly tested performance and despite fragmentation having a bad
> reputation for some, I don't see much difference in iperf speeds to
> the same host vs going directly.
> 
> This is now usable to join multiple locations via VXLAN interfaces as members
> of L2 bridges to physical 1G/10G networks without hobbling MTU of the latter.
> 
> Thanks!
> 

I'm not saying this is a bad idea to support, but it may be good to 
document a couple of things about this.

The first is that this makes it apparent to an observer what the MTU on 
your other interfaces are, and which interface a connection routes 
through if they're different. This is only a small information leak, but 
it is one.

I would also suggest that if you're going to do this with the underlying 
transport, check the DF bit on the inner packet and send the ICMP[v6] 
too big message back to the sender as appropriate. Then you can set a 
high MTU on the wg interface but things that support PMTU discovery can 
still use it.

Moreover, you may want to performance test the common degenerate case of 
setting the MTU on the wg interface to not account for transport 
overhead which then fragments every packet into one full packet and one 
tiny packet. That is likely to be somewhat worse, and would occur in any 
case that the MTU on the originating and wg underlying transport 
interfaces are equal and the MTU on the wg interface is set to that or 
higher.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

      reply	other threads:[~2019-05-24 15:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24  8:48 Roman Mamedov
2019-05-24 15:17 ` zrm [this message]

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=9f1123cc-8796-3b76-f452-09f080a296ce@trustiosity.com \
    --to=zrm@trustiosity.com \
    --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).