-----BEGIN PGP SIGNED MESSAGE-----
On 09/16/16 14:08, Stuart Henderson wrote:
> On 2016-09-14, Harald Dunkel <ha...@afaics.de> wrote:
>> AFAIU setting the max-mss affects TCP traffic only (e.g. HTTPS). It defines
>> the maximum payload block size on sending and receiving(!) data via TCP. UDP
>> and other protocols are not affected. Very important to know if you run
>> IPsec or openvpn or other non-TCP protocols over the PPPoE tunnel.
>> The mtu works on ethernet level, giving the maximum packet size to send(!)
>> to the next hop without fragmentation, regardless if the higher level
>> protocol is TCP, UDP, ESP or whatever.
> You are supposed to be able to get large packets through; routers are meant
> to either fragment or send ICMP "frag-needed" messages to allow the end host
> to do it. But some idiots misconfigure their firewalls to drop the necessary
> ICMP messages causing breakage to some sites.
Would you say that setting "scrub (no-df random-id)" is best practice
for IPv4 traffic forwarded into the internet?
> The MSS in the TCP handshake is based on the MTU on the outgoing route from
> the end host. So if you have
> router - pppoe0 - 1492 router - internal - 1500 host - internal - 1500
> the host will base its calculation on 1500 not 1492.
> "scrub (max-mss ..)" will cap this in the TCP handshake (and adjust checksums
> to match).
I figured this out, but maybe pf.conf(5) could be more explicit on
this detail, too?
> However: if you have working 1500 MTU pppoe via baby jumbos on the ethernet
> interface, "scrub (max-mss..)" shouldn't fix anything. The restricted MTU is
> usually towards the "client" side of things rather than towards the server,
> plus if it's towards the server then many people will be affected
> so it's easier for the server admin to spot problems.
>> My current configuration uses both baby jumbo frames (mtu = 1508 on re0 and
>> mtu = 1500 on pppoe0) and "scrub (max-mss 1452)" for TCP traffic on pppoe0
>> (1500 bytes - 40 bytes TCP/IP header - 8 bytes PPPoE frame).
> You should not need both. If baby jumbos are working correctly (you can "ping
> -D -s 1472 $some_internet_host" from an end host) then you should be able to
> get rid of the scrub. If they are not working correctly, you should get rid
> of the baby jumbo config and just use 1492, this will at least
> fix things for larger packets in the normal case where there is no bad
> firewall config in the way.
Deutsche Telekom seems to support baby jumbo frames ("Dumbos"? :-) )
on my side, but they told me that they don't actively support per-
customer MTUs on their BNGs.
Thanx for your detailed response. That was really helpful.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----