pfsense and IPv6 default behavior

IsaacFL

@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.

johnpoz

@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..

lohphat

@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?

johnpoz

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

JeGr

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?

lohphat

@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

IsaacFL

@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.

IsaacFL

@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.

lohphat

@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.

IsaacFL

@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.

lohphat

@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.

JKnott

@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.