pfsense and IPv6 default behavior



  • It's not clear from the existing docs how pfSense handles the underlying housekeeping of IPv6 networks.

    So far I've had to manually add two rules to apparently compensate for default behavior but it's not clear if the rules are needed or best practice or not.

    e.g.
    I've had to add an IPv6(any) fe80::/10(from) any(to) to the LAN firewall rules to handle basic multicast traffic which is required for basic IPv6 operation. Also I've added an IPv6(ICMP[all]) any(from) LAN net(to) on the WAN side to allow basic ICMP to work.

    One of the big benefits of IPv6 is large multicast media streaming e.g. YouTube live events. It's not clear if the default config would allow for the multicast sessions to be handled correctly. With IPv4 it was a mess requiring kludges and IGMP snooping to work but with IPv6 it's all built in.

    The IPv6 section of the docs is very thin.


  • LAYER 8 Global Moderator

    @lohphat said in pfsense and IPv6 default behavior:

    I've had to add an IPv6(any) fe80::/10(from) any(to) to the LAN firewall rules to handle basic multicast traffic which is required for basic IPv6 operation

    Where did you get idea that you had to add that?

    And that is link-local space, multicast space would be ff00::/8



  • @johnpoz There are firewall blocked entries for link local to multicast showing in the logs.

    e.g.
    Sep 30 16:15 LAN [fe80::4b7:xxxx:yyyy:zzzz] [ff02::fb]:5353

    So I added the permit fe80::/10 to any rule to suppress those entries.


  • LAYER 8 Global Moderator

    that is the link-local address broadcasting for mdns.. That is not required for anything to work..



  • @johnpoz That's my point. Why is link local LAN traffic blocked at all? What if mDNS behavior is desired?


  • LAYER 8 Global Moderator

    Because link-local is not LAN NET would be why its blocked ;)

    Change your source on your IPv6 rule to any if you don't want to see the those blocks ;)

    And what exactly are you going to be running on pfsense for mdns to be resolve from it? There is not mdns package, etc.



  • @johnpoz Yes. I know that but for IPv6 to work it's not clear in the pfSense doc what is and is not appropriate link local traffic. Shouldn't it be presumed that link local to broadcast/multicast traffic on the LAN segment is permitted?


  • LAYER 8 Global Moderator

    Why would you assume that.. Its not a requirement for ipv6 to work...

    Not sure why the pfsense book or docs should be the IPv6 bible or anything... If you want to learn about IPv6 there are many a resource for that...

    Broadcast/multicast traffic isn't going anywhere - why should it be allowed.. What would be listening on pfsnese out of the box for such traffic?

    Rule is Lan Net, not whatever link-local address you might be using, etc. Which is not required for ipv6 to function and route through pfsense. Not aware of any service you would run on pfsense where those would be needed, etc.



  • @johnpoz Isn't avahi/zeroconf/bonjour a form of mDNS for auto-enumeration of local hostnames?

    Not wanting to get into the weeds, this is my point of my original issue: IPv6 default behavior is not well documented. multicast/broadcast needs to work for IPv6 and when you see blocked link local traffic to broadcast destinations raises questions. If it's blocking that, is it also interfering in other multicast group operations too?



  • @johnpoz Multicast group membership management is key for IPv6 functionality.

    https://en.wikipedia.org/wiki/IPv6_address#Multicast_addresses

    For these key IPv6 group addresses to work, multicast but be working. It is not optional.


  • LAYER 8 Global Moderator

    @lohphat said in pfsense and IPv6 default behavior:

    If it's blocking that, is it also interfering in other multicast group operations too?

    Again like what?? Not sure where you got the idea that link-local to broadcast is required for anything? Are you thinking of maybe icmpv6 that is required for say router solicitation, etc?

    edit:
    You might want do a bit more research ;)

    Pfsense is the gateway off that L3.. it has nothing to do with devices on that L2 talking whatever they want to talk to each other with... They can send traffic all day to [ff02::fb]:5353, pfsense is just not needed in that conversation and why should it allow the traffic to something its not listening on, etc.

    if you happen to add dhcpv6 enabled - just like when you enable dhcp - hidden rules are enabled that are not shown in the gui that allow the requirements... Look at the full ruleset if you want, etc.
    https://docs.netgate.com/pfsense/en/latest/firewall/viewing-the-full-pf-ruleset.html

    edit: also not sure what info you think you found about this

    One of the big benefits of IPv6 is large multicast media streaming e.g. YouTube live events

    Think you misread something somewhere ;)



  • @lohphat said in pfsense and IPv6 default behavior:

    @johnpoz That's my point. Why is link local LAN traffic blocked at all? What if mDNS behavior is desired?

    Given that link local addresses are not routeable, they will never pass through pfSense, so any rules for them will be useless. Link local addresses are useful only on the local network and may be used for things like router advertisements, etc.



  • @lohphat said in pfsense and IPv6 default behavior:

    @johnpoz Isn't avahi/zeroconf/bonjour a form of mDNS for auto-enumeration of local hostnames?

    Not wanting to get into the weeds, this is my point of my original issue: IPv6 default behavior is not well documented. multicast/broadcast needs to work for IPv6 and when you see blocked link local traffic to broadcast destinations raises questions. If it's blocking that, is it also interfering in other multicast group operations too?

    First off, there's no such thing as broadcasts in IPv6, only multicasts. The closest thing to broadcasts in IPv6 is all hosts multicast. Then, with multicasts, there's the issue of scope, that is how far the multicast is supposed to travel. That could be as limited as an interface, the local network is commonly used and somewhere beyond a router. I mentioned router advertisements (RAs) in another note. If you watch a network with Packet Capture, you will see RAs from the router, from the router link local address to the all hosts multicast address etc. So, you'll have to consider what the multicast will be used for, it's scope, routeable vs link local addresses, etc.



  • @johnpoz said in pfsense and IPv6 default behavior:

    If you want to learn about IPv6 there are many a resource for that...

    I recommend IPv6 Essentials.

    Broadcast/multicast traffic isn't going anywhere - why should it be allowed.

    No such thing as broadcast on IPv6. Multicast might be passed by a router, depending on scope.



  • @JKnott I understand that. My question is why are Layer 2 packets used for IPv6 housekeeping making it into the logs in the first place? Either they're all handed properly as part of the protocol spec or they're blocked and not processed. Thus the confusion caused by layer 2 housekeeping showing up. If it's not going to be processed by the definition of link local, then why log it?



  • @JKnott I apologize for using "broadcast" I was referring to the all hosts multicast address. Old habits die hard. ;-)



  • @lohphat said in pfsense and IPv6 default behavior:

    My question is why are Layer 2 packets used for IPv6 housekeeping making it into the logs in the first place?

    Layer 2 is Ethernet. I thought we were talking about IPv6, which is L3. Even link local addresses are L3. Perhaps this is where some of your confusion is coming from.



  • @JKnott Yes, probably. With IPv6 the reserved multicast address member management packets are link local too (IGMP, etc.) so why aren't those packets showing up in the firewall logs but the mDNS packets are?


  • LAYER 8 Global Moderator

    I knew you would call me out on the "broadcast" term ;) My bad yes - bad habit I do need to break, and yes you are correct the term is not correct in relation to ipv6.. But its the same sort of thing in use ;)



  • @lohphat

    pfsense by default blocks everything that isn't explicitly passed.

    The more correct way would be to have a rule that passes "any" to "multicast". I use ff00::/8 as multicast.

    The reason is that you will see multicast coming from your local ipv6 addresses and link local addresses both.

    You have to have a rule to pass multicast, if you are using Avahi for instance. The Avahi service inside pfsense will never see the mDNS traffic via ipv6 otherwise.



  • @johnpoz said in pfsense and IPv6 default behavior:

    @lohphat said in pfsense and IPv6 default behavior:

    I've had to add an IPv6(any) fe80::/10(from) any(to) to the LAN firewall rules to handle basic multicast traffic which is required for basic IPv6 operation

    Where did you get idea that you had to add that?

    And that is link-local space, multicast space would be ff00::/8

    If you don't have a rule to allow "any" to "multicast", then Avahi will not work on ipv6.

    You can verify it with wireshark. If you have no rule to pass the multicast, you will see devices asking for devices via mDNS, but no response from the router on ipv6 so it falls back to ipv4. If you pass the multicast then you will see the router respond via ipv6.

    With no ipv6 rule Avahi never receives the packet to process it. The reason Avahi seems to works is many people have a rule that passes "LAN net" to "any" which allows ipv4 multicast, but ipv6 link local is not part of "LAN net" so it gets blocked.


  • LAYER 8 Global Moderator

    @IsaacFL said in pfsense and IPv6 default behavior:

    if you are using Avahi for instance

    Which is not default setup.. So yes if you are adding new services that pfsense to do - then yes you might have to adjust the rules..



  • @IsaacFL This is my original point about pfSense's base config not supporting multicast by default. IPv6 relies on multicast for basic operations (e.g. enumerating the all hosts group) -- why should anyone need to manually enable rules for IPv6 multicast?


  • LAYER 8 Global Moderator

    because pfsense doesn't do anything with ipv6 multicast out of the box..


  • LAYER 8 Moderator

    And it doesn't have to - per default. We're running an IPv6 enabled dualstacked hosting setup for years now without needing that. Only time I had to actually pass in multicast traffic was for allowing downstream core switch to talk OSPF with the firewall via FRR, and that was necessary for IP4 & IP6. Besides that, nothing comes to mind, that absolutely needs multicast to pass a firewall with IPv6?



  • @JeGr One of the befits of IPv6 is that it finally fixes multicast to enable realtime media streaming from non-local sources to reduce bandwidth needs consumed by unicast.

    IPTV is one such solution where each channel is it's own multicast channel. http://www.klicktv.co.uk/iptv-multicasting



  • @JeGr said in pfsense and IPv6 default behavior:

    And it doesn't have to - per default. We're running an IPv6 enabled dualstacked hosting setup for years now without needing that. Only time I had to actually pass in multicast traffic was for allowing downstream core switch to talk OSPF with the firewall via FRR, and that was necessary for IP4 & IP6. Besides that, nothing comes to mind, that absolutely needs multicast to pass a firewall with IPv6?

    If you turn off ipv4 you will find that some some services may not function correctly without a rule passing multicast into the router. Your dual stack lets it fall back on ipv4.



  • @johnpoz said in pfsense and IPv6 default behavior:

    because pfsense doesn't do anything with ipv6 multicast out of the box..

    Not correct. The routing in ipv6 uses multicast and there are some built in rules to pass them in. There are also some that have been missed and are getting blocked that shouldn’t be

    I know of at least one bug that I submitted that is being fixed in 2.5

    If you add a pass rule to multicast it fixes it in meantime.



  • @IsaacFL This is my point, thanks. There are basic IPv6 functionality which is partially taken care of by default hidden rules and others which need manual intervention. This needs to be cleaned up and or clarified. WAN and LAN segments need to handle link local traffic properly (as an example) for both routing (OSPF broadcasts), ICMP, IGMP, etc. so that basic IPv6 functionality isn't broken due to incomplete/inconsistent/poorly documented defaults.

    In another pointless rant of mine =), all pfSense settings should have the default setting called out in the setting description. Currently it's very inconsistent.



  • @lohphat said in pfsense and IPv6 default behavior:

    @IsaacFL This is my point, thanks. There are basic IPv6 functionality which is partially taken care of by default hidden rules and others which need manual intervention. This needs to be cleaned up and or clarified. WAN and LAN segments need to handle link local traffic properly (as an example) for both routing (OSPF broadcasts), ICMP, IGMP, etc. so that basic IPv6 functionality isn't broken due to incomplete/inconsistent/poorly documented defaults.

    In another pointless rant of mine =), all pfSense settings should have the default setting called out in the setting description. Currently it's very inconsistent.

    I think the philosophy of pfSense is that by default everything is rejected. There are some exceptions for some of the internal functions, ie DHCP etc. but for the most part you are expected to explicitly pass via a firewall rule.

    That way the end user has complete control which means they can also shoot themselves in the foot.



  • @IsaacFL I understand that and agree however multicast is intrinsic to IPv6 not optional with IPv4. IPv6 internal consistency of multicast groups replacing broadcast and other functionality means that it should either be enabled fully or a clear, clean setting to enable multimedia multicast. The separation of some things into hidden (supporting host, routing, and service groups) vs. explicit rules (to support media streaming and mDNS) muddles the config process.



  • @lohphat said in pfsense and IPv6 default behavior:

    I understand that and agree however multicast is intrinsic to IPv6 not optional with IPv4. IPv6 internal consistency of multicast groups replacing broadcast and other functionality means that it should either be enabled fully or a clear, clean setting to enable multimedia multicast.

    For stuff directly on the LAN, multicast works fine and pfSense is not involved, except for it's own needs. It's only when you go beyond that you have to enable it. This is the same for every just about everything. By default, firewalls block everything coming in.


Log in to reply