IPv6 PPPoE MSS incorrect

msmith100

@bm118 Looking through the raw rules in pfsense, I see this:

pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state

These are not anything I created, and I believe part of the default pfsense rules. If I understand them correctly, they mean that by default pfsense will pass along "packet too big" messages without issue. I also allow pings with one of my own rules, and I pass the IPv6-test.com tests no problem. Doesn't help me on other sites though, as I think some sites like yahoo.com don't do PMTUD properly. Even for sites that do, the delay while it figures out the proper size is very noticeable and undesirable.

viktor_g

@bm118

Could you test this patch: 135.diff

You need to install System Patches pkg:
https://docs.netgate.com/pfsense/en/latest/development/system-patches.html

msmith100

@viktor_g Applied on 2.4.5 without issue and confirmed working on all my problem websites with 1492 entered as MSS into WAN configuration page.

[2.4.5-RELEASE][root@pfSense]/root: pfctl -sr | grep mss
scrub on pppoe0 inet all max-mss 1452 fragment reassemble
scrub on pppoe0 inet6 all max-mss 1432 fragment reassemble

Thank you very much!

EDIT: May also want to update the description on the interfaces page:
If a value is entered in this field, then MSS clamping for TCP connections to the value entered above minus 40 (TCP/IP header size) will be in effect.

dem

Perhaps slightly off topic, but my IPv6 is via 6rd over PPPoE and when I was having PMTUD issues what I did was patch the radvd config to advertise a lower MTU.

viktor_g

@dem please try the updated patch with 6rd/6to4 support: 135 (1).diff

dem

@viktor_g Thanks, but I'm unable test with my production system right now.

BM118

@msmith100 said in IPv6 PPPoE MSS incorrect:

@bm118 Looking through the raw rules in pfsense, I see this:
pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state
These are not anything I created, and I believe part of the default pfsense rules. If I understand them correctly, they mean that by default pfsense will pass along "packet too big" messages without issue. I also allow pings with one of my own rules, and I pass the IPv6-test.com tests no problem. Doesn't help me on other sites though, as I think some sites like yahoo.com don't do PMTUD properly. Even for sites that do, the delay while it figures out the proper size is very noticeable and undesirable.

Thanks for this, I actually wasn’t aware that PFSense had any rules for ICMPv6 built-in. I wouldn’t expect to see NeighbourSolicit and NeighbourAdvertise through a WAN interface though, however to the interface may be another thing. I believe there are some types missing from that list that are commonly accepted to be essential.

I would recommend having a look through this article if you are so inclined as it details a bit about the types of messages that must be allowed, generally should be allowed and ones that don’t matter.

https://tools.ietf.org/html/rfc4890#page-14

JKnott

@bm118 said in IPv6 PPPoE MSS incorrect:

I wouldn’t expect to see NeighbourSolicit and NeighbourAdvertise through a WAN interface though

I certainly see them here. IPv6 can't work without them.

viktor_g

@bm118 see https://redmine.pfsense.org/issues/9167

BM118

@jknott said in IPv6 PPPoE MSS incorrect:

@bm118 said in IPv6 PPPoE MSS incorrect:

I wouldn’t expect to see NeighbourSolicit and NeighbourAdvertise through a WAN interface though

I certainly see them here. IPv6 can't work without them.

I might be going on a tangent here, and while I 100% agree you need NS and NA for IPv6 to work, I still don't believe that the packets need to be allowed to transit through the WAN interface or any L3 interface for that matter. Should the packets be allowed to the interface of the Firewall, and to the Multicast address block, sure, but I don't see why they need to be allowed through them.

In the grand scheme of things, a routed NS/NA will likely be dropped anyway.

NS and NA messages are purely for local link management, and as such if you have an L2/Bridge setup then it makes sense to allow them through the interface.

BM118

@viktor_g said in IPv6 PPPoE MSS incorrect:

@bm118

Could you test this patch: 135.diff

You need to install System Patches pkg:
https://docs.netgate.com/pfsense/en/latest/development/system-patches.html

Works a treat, thank you very much!