Interface groups and IPv6 GUA subnets
-
Hi! I've tried to find an answer to this specific question online and I think I know now how it works, but would like to ask here for some clarification. I am running pfSense plus 23.09 but also get the same behavior on 23.09.1 on a different machine.
My goal is to add IPv6 support to my setup with a single WAN connection (dual stack, /56 prefix on IPv6) and multiple VLANs. To segregate the VLANs with IPv4 I am using a rule that allows everything except private IPv4 address ranges as destination, as described in this post (the whole situation is pretty similar actually).
For IPv6, my understanding is (and testing showed) that I can do one of these to effectively block traffic between different VLANs while allowing internet access.
On the VLAN interface to be isolated:
- use a default "allow all" rule at the bottom and add an explicit block rule above for each other interface with the automatically generated "VLAN XYZ subnets" alias (this works in my tests, but is a bit too laborious for 4+ VLANs with expected changes down the road)
- use a single allow rule with destination "anything except ::0/56" (if I got it right, the ::0/56 networks expands to "all addresses that have the same (current) /56 prefix that the ISP delegated to me, i.e. it includes all delegated prefixes of my VLANs - this seems to do exactly what I want and I can still manually add allow rules for specific VLANs with the automatic interface aliases if I want more fine-grained control)
Now the surprising thing for me was that this didn't work
- create an interface group containing all the VLANs that should not be accessible and add an allow rule with destination "anything except this interface group". In this case the traffic is not blocked / the rule is ignored.
With the new Diagnostics > Tables it seems also clear to me why the interface group option didn't work: The IPv6 addresses don't show up in the interface group table, they only contain IPv4 addresses.
So my actual questions are:
- Is this known/intended behavior that the interface groups don't contain the corresponding IPv6 addresses?
- I've read that the automatic inference of the IPv6 prefix doesn't work with aliases, so do interface groups work with aliases internally?
Interface groups with IPv6 support would be nice to have and enable more flexibility, but as said, the "workaround" with ::0/56 works for my purposes - I would just like to make sure I understand why it works and why the alternative doesn't. Any hints are greatly appreciated and apologies if I missed the answer somewhere else
-
@Sevi said in Interface groups and IPv6 GUA subnets:
- Is this known/intended behavior that the interface groups don't contain the corresponding IPv6 addresses?
In my test with only two interfaces they are included. I use static IPv6 addresses though.
And there is another problem with your approach I think. How will you allow those subnets to still connect to their pfSense interface for DNS etc.?
-
That's interesting, thanks for the quick reply!
@Bob-Dig said in Interface groups and IPv6 GUA subnets:
In my test with only two interfaces they are included. I use static IPv6 addresses though.
Do you mean statically assigned GUAs or ULAs?
I am not using static addresses nor ULAs, only "Track Interface" on all the VLAN interfaces, tracking the WAN interface which gets the prefix through DHCP6 from the ISP.
To test the interface groups, I also made one containing only a single VLAN, but the corresponding table also doesn't contain the delegated-prefix subnet (but the actual interface table does).
Just to be sure I didn't miss anything, this is what I just did on the a Netgate 1100 running 23.09.1:
- create a new VLAN 123
- assign a corresponding interface with static IPv4 and Track Interface of the WAN with an available prefix ID
- enable, save and apply the interface
- (save and apply the WAN interface settings, so the new interface gets its IPv6 prefix)
- create a new interface group containing only the new VLAN 123 interface
- on the new test interface, create these dummy firewall rules
- IPv6, allow, any protocol, source "Test interface subnets", destination "Test interface subnets"
- IPv6, allow, any protocol, source "Test interface subnets", destination "Test interface group networks"
- Check the tables under "Diagnostics > Tables"
- The table corresponding to the interface contains the right IPv4 subnet and the delegated IPv6 subnet
- The table of the interface group contains only the IPv4 subnet
Side note: I also disabled the test interface's IPv4 and the table of the interface itself gets updated (contains only the IPv6 GUA network now), but the interface group table still contains the obsolete IPv4 network.
@Bob-Dig said in Interface groups and IPv6 GUA subnets:
And there is another problem with your approach I think. How will you allow those subnets to still connect to their pfSense interface for DNS etc.?
The isolated VLANs don't really need access to the pfSense interface, they only need routing to the internet. On the IPv4 side, I distribute a DNS server like 1.1.1.1 with DHCP. My first intuition would be to do something similar with IPv6?
I'm still relatively new to IPv6 and I'm not sure how DNS is handled with SLAAC / "Track Interface" or if other ports are required for the network to function properly on IPv6. At least so far it seems to be working fine in a test setup (although that might be because IPv4 is set up as well).
Even if the above (distributing some public IPv6 DNS server in the local network) doesn't work as I imagine it, I would just add explicit rules above the "isolation rule" to allow traffic to the "VLAN interface address" on the respective ports, e.g. DNS, etc. ?
-
@Sevi said in Interface groups and IPv6 GUA subnets:
Even if the above (distributing some public IPv6 DNS server in the local network) doesn't work as I imagine it, I would just add explicit rules above the "isolation rule" to allow traffic to the "VLAN interface address" on the respective ports, e.g. DNS, etc. ?
The public ones would work.
But you can not place an allow rule above your block rule for individual pfSense interfaces in that groups tab.Regarding your interface groups don't contain the corresponding IPv6 addresses, have you tried the patch? It has side-effects though, so I am not using it.
-
@Bob-Dig said in Interface groups and IPv6 GUA subnets:
But you can not place an allow rule above your block rule for individual pfSense interfaces in that groups tab.
Ah, there might have been a misunderstanding. I'm creating the rules on each individual interface, not the group tab. Of course, creating it in the group tab would be even more convenient (don't have to copy the rules to every new interface), but it's not really what I want, precisely for the reasons you mentioned.
I just don't know what exactly the "alias" "Interface group networks" is supposed to contain if it is used as a source/destination in a firewall rule.
I'm already happy if I don't have to update all existing VLAN rule tabs when I add a new interface - I don't mind copying the rules to each new interface when I create one
@Bob-Dig said in Interface groups and IPv6 GUA subnets:
Regarding your interface groups don't contain the corresponding IPv6 addresses, have you tried the patch? It has side-effects though, so I am not using it.
You mean the patch mentioned here, right? I haven't tried it yet, but I'll do that later and report back whether it changes something.
Thanks again for your input!
-
@Sevi said in Interface groups and IPv6 GUA subnets:
Ah, there might have been a misunderstanding. I'm creating the rules on each individual interface, not the group tab.
Smart move. Hadn't thought about that one.
-
Wow, the patch (
1c4ca20d3d5910f126f11221f23e1fa21197f225) is indeed working. After applying and reloading the filters, the interface group tables now contain the same (IPv4 + IPv6) subnets as the individual interfaces. Haven't got a chance to test the firewall rules in practice yet, but I'm confident they will work.My non-expert conclusion would be that the GUA subnets from "Track Interface" are are "real" IP addresses on the interface network alias, but they are considered "Virtual IPs" on an interface group? That would at least explain why the missing GUAs show up on the interface group after applying the patch
@Bob-Dig said in Interface groups and IPv6 GUA subnets:
It has side-effects though, so I am not using it.
So far I had no issues with adding new interfaces and getting assigned a GUA via Track Interface after the patch was applied (I didn't use "auto apply" though). Are there any other side effects you know of?
-
@Sevi said in Interface groups and IPv6 GUA subnets:
Are there any other side effects you know of?
No. Interesting that it does work for you without problems.
-
@Bob-Dig said in Interface groups and IPv6 GUA subnets:
Interesting that it does work for you without problems.
A difference might be that I'm only testing VLANs right now, no physical interfaces? I can try it later on the 4100, but for now I was testing on an 1100 with the switched ports.
(I did have to use the ol' Save&Apply on the WAN interface to trigger the prefix delegation for any new interface though... but I also had to do that before the patch.)
-
S Sevi referenced this topic on
