Hi, On Sun, Jul 30, 2023 at 07:55:56PM +0200, Niccolò Belli wrote: > That's NOT what's happening! Somehow I can ping the server private IP with a > payload size of 1472 despite fragment not being set (tun-mtu and mssfix have > not been set either).
Outside fragmentation. There's a number of MTUs involved, which makes this all painful - OpenVPN interface MTU (what "ifconfig" shows) - this is the maximum size packet which can be stuffed *into* the VPN - and then you add overhead to it - "outside MTU", which is the maximum size a packet leaving your machine can be - "path MTU", which is the maximum size that will arrive, unfragmented So, for an OpenVPN connection with inside MTU 1500, when I do my all-time favourite "ping -s 3000" test, what happens is - the ping gets *inside* fragmented into 2x 1500 + some remainder, creating 3 OpenVPN (UDP) packets - the 2 big UDP packets get fragmented on the *outside*, so for 1 ping, *5* packets arrive at the VPN server (in theory, the outside packets could get fragmented again by a router on the path, but this depends on framgent size on the sending host) Now, OpenVPN --fragment will add *another* layer, taking a full-sized 1500 byte into the OpenVPN tun, and fragmenting on OpenVPN protocol layer to produce smaller UDP packets that do not need to be "outside fragmented". This is useful if you have non-TCP-traffic - for TCP, --mssfix is less over head and gets the job done nicely. > How do you explain that? It looks like it's automatically fragmenting > packets despite fragment has not been set. tcpdump/wireshark will be able to answer this - "tcpdump -n -i tun0" (inside) or "tcpdump -n -i eth0" (outside). Beware of the length values tcpdump prints, that's just payload. Wireshark is more precise there. > > Considering your command of English, this is documented: > > https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html > > I've read that, but it's not fully clear. > > About "--fragment max mtu" I can read the following: > "Enable internal datagram fragmentation so that no UDP datagrams are sent > which are larger than max bytes. > If the mtu parameter is present the max parameter is interpreted to include > IP and UDP encapsulation overhead. > If the mtu parameter is absent, the max parameter is interpreted in the same > way as the --link-mtu parameter, i.e. the UDP packet size after > encapsulation overhead has been added in, but not including the UDP header > itself. > --fragment adds 4 bytes of overhead per datagram." This should do what is documented (the calculation was fully reworked for 2.6.0). So, "--fragment 1492 mtu" should ensure that no UDP packet larger than 1492 is ever created by OpenVPN. [..] > "--tun-mtu tun-mtu" seems easy to understand: > "Take the TUN device MTU to be tun-mtu and derive the link MTU from it. > The MTU (Maximum Transmission Units) is the maximum datagram size in bytes > that can be sent unfragmented over a particular network path." This will "ifconfig" the inside interface to the smaller MTU, so the client OS will never send larger packets to OpenVPN. > According to the docs and my experimental data the Tiscali-Server tun-mtu > parameter should be set to 1460. I think that this is supposed to set the > mtu on the tap interface to such value, but it doesn't because I create the > tap device with NetworkManager. What I do is manually setting the tap mtu to > 1460. I also set the bridge where the tap has been added to to 1460, as well > as the ethernet interface attached to the bridge. This way all the packets > originated from the Tiscali client or the server shouldn't exceed 1460, but > being a layer 2 vpn that does nothing for all the other devices in the > network that want to talk to the other side of the tunnel. ... there's the catch: if you bridge to a LAN on the other side, setting MTU on the tap interface is very likely not going to work - those machines on the other end have 1500, and you can't (inside) fragment on bridging. > One question remains open: how do I verify which link-mtu gets computed from > the tun-mtu? According to what I've understood from the documentation it > should be at least 1460 - 20 (IPv4 header) - 66 (encapsulation overhead) - 8 > (UDP header) = 1366. Unfortunately there is no way to verify what actually > gets computed from the link-mtu. It should be logged (--verb 4), but generally, link-mtu is "tun-mtu plus overhead for OpenVPN protocol plus crypt plus auth", and that varies depending on cipher etc. [..] > Setting "tun-mtu 1460, fragment 1300 mtu, mssfix 1300 mtu" should give > plenty of headroom to stay on the safe side, yet the Tiscali connection > behaves weirdly: for example clients most of the times don't receive the > gateway from the dhcp (certain clients like the Amazon Fire Stick never do, > yet they work fine with static IP). This doesn't happen with the Iliad > connection! tcpdump on both OpenVPN tap interfaces will tell what sort of packets are lost, and hopefully why. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
