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. 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. 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.
