On Mon, Feb 10, 2020 at 12:15:37PM +0100, Simen Stavdal wrote: | 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. | | 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. | | 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?
One interesting option that I recently discovered thanks to florian@ is the 'mtu'[1] setting in /etc/rad.conf on your IPv6 router. By lowering the MTU, packets had a smaller MSS, which aligned with the MTU of the IPv6 tunnel I was using in that situation. This, in turn, allowed me to use software my bank has provided for my mobile device over IPv6 without a problem. Admittedly, after learning that this worked, I switched back to scrubbing the MSS in pf.conf for this particular bank, and I've told them to either stop filering ICMPv6 Packet Too Large errors or restrict the MSS to a lower value on their end (as they said they were doing) to fix this for all their users. The effect of using 'mtu' in rad(8) is a lower configured MTU on your SLAAC enabled clients, affecting also IPv4 (and local IPv6) traffic. Cheers, Paul 'WEiRD' de Weerd [1]: http://man.openbsd.org/rad.conf#mtu | Statically configured on each host? DHCP option? | | Cheers, | Simon. | | On Mon, 10 Feb 2020 at 12:06, Janne Johansson <icepic...@gmail.com> wrote: | | > Den mån 10 feb. 2020 kl 11:58 skrev Simen Stavdal <sstav...@gmail.com>: | > | >> Hi Lucas, | >> Have you tried to manipulate the mss during conversation setup? | >> This is done with the max-mss directive in pf.conf. | >> Basically, it takes the three way handshake, and overrides the MSS value | >> in | >> the handshake to something lower than the default. | >> | > | > 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. | > -- >++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+ +++++++++++>-]<.>++[<------------>-]<+.--------------.[-] http://www.weirdnet.nl/
