On Mon, 10 Feb 2020 at 17:00, Janne Johansson <icepic...@gmail.com> wrote:
> Den mån 10 feb. 2020 kl 16:27 skrev Simen Stavdal <sstav...@gmail.com>: > >> This is more a discussion about scalability and practical implementation. >> We both know that PMTU will work partly at best, your entire path back >> must support this, and also, the "offending" client must allow inbound >> control messages on their host firewall for this to work. >> And even if the packets are received by the client, will it support and >> adjust MSS? I have seen a lot of clients not adhering to standards. >> >> Modifying thousands of clients (via dhcp options for instance) to use a >> fixed MTU will affect other applications too (if you choose to go that >> route), not just the ones that need to traverse a tight ipsec tunnel. >> Would you adjust all your clients just because you had a single path >> using SLIP in your network? >> > > I would want for noone to ever have to know the complete path, slip or no > slip. > > >> Point is, there is no perfect solution to this issue, there are just >> different ways of solving bits and bobs on the way. >> Adjust mss will work just fine for all tcp protocols, and no, not for UDP >> because it does not use a three way handshake (no MSS to adjust). >> In my opinion, max-mss works very well in most cases, especially when you >> have full control of the tunnel you are using (as is the case of Lucas' >> original question). >> We use it extensively in many of our applications in my workplace, and as >> of yet has not represented any big issues, so it is a practically good way >> to solve this issue. >> > > I think the more complete solution is to run some gif/gre inside ipsec and > set low-enough MTU on that one, so it can correctly fragment incoming > packets, and optionally rebuild the packets at the remote end, while also > giving you an idea of "state" on the link so you optionally can run things > like routing daemons or something that cares about and acts on tunnel > state. This would cause even lower MTU, but still allow all kinds of > traffic and not just the "popular" one. > So, how will your client/server know about this lower mtu? And df bit is set more often than not, so fragmentation is now allowed in a lot of cases. This is exactly the problem that started this thread... > > I am somewhat trying to care for the ones that make a site-2-site ipsec > which may work for the initial setup, and later find out that more than one > non-tcp kind of traffic doesn't work without understanding why ssh,http > works but not list-of-things-like > mosh,wireguard,quic,yet-another-layer-of-ipsec,hosting-udp-game doesn't. > so, I agree that it would be nice that all protocols would work, but ultimately the client/server refusing to use fragmentation is really the problem, when MTU is too small, and clients insist on big packets. > > As for UDP, there are options here too in pf.conf (like no-df), but >> personally I have not tested this, but it would be fun to try. It says it >> supports IPv4 (which would include TCP, UDP and ICMP). >> Would be interesting to find if UDP enforces DF in most cases. >> > > no-df in PF more or less controls if it will silently drop fragments that > arrive which has DF set. Linux used/uses to send such udp, for much > enjoyment. "noone else should fragment, but I just did and you as the > packet checker can't know who did" > > -- > May the most significant bit of your life be positive. >
