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? 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. 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. Cheers, Simon. On Mon, 10 Feb 2020 at 13:50, Janne Johansson <[email protected]> wrote: > Den mån 10 feb. 2020 kl 12:15 skrev Simen Stavdal <[email protected]>: > >> True, but issue was related to downloading over http, which is over tcp. >> So, if http is your only concern I would go for this option. >> > > To me, it sounds just a bit like "let this person notice the other errors > later". > > >> Most clients are configured with an MTU of their physical NIC >> capabilities, and sometimes even with jumbo support. >> MTU is a property of the OS in both ends, while MSS is a property of the >> packets that can be adjusted in-flight. >> >> > MTU is strictly a property of each and every interface in all the hops > between you and your endpoint and equally strictly is mss a property of > _tcp_ packets that can be adjusted. If you run another ipsec inside this > first ipsec tunnel-with-mss-fixed that second one would break, since ESP/AH > is not tcp and will not do the 3way handshake where PF can fix mss for it. > Or mosh, wireguard, or http/3 since they run over UDP. > > Not trying to nitpick everything, but internet wasn't built on 1500 MTU > ethernet everywhere, in the old bad days you might go over PPP (576) or > SLIP (296) links at times and it still worked, so if your setups today > break if someone in your path limits you to 1476 or so, then we have > regressed quite a bit since the crap internet days. > > >> So, if you want to fix the MTU, you will have to configure that on the >> conversation parters and not in pf. >> So, while we agree on the principals, how do you suggest MTU is changed? >> > > PMTU discovery would be one method, yes. Middle boxes that will not drop > icmp is part if this of course. > > >> Statically configured on each host? DHCP option? >> > > This depends a bit on where you place your ipsec gw of course, but if you > can't set it on the tunnel (since ipsec on obsd isn't like openvpn or > gif/gre) you might need to set it on the interface where you take in the > traffic, if you can't set it on all clients going via the gw, which is a > believable scenario. > > >> This might fix the http/ssh issues one might see, because both of those >>> run over TCP, but MSS fixups will not correct large UDP or icmp packets, or >>> any other non-TCP protocol one might run over that ipsec, so making sure >>> the traffic is below the MTU should be the end goal, not fixing 90% with >>> pf. >>> >> > > -- > May the most significant bit of your life be positive. >
