Delegated prefix in firewall rules?

jhg

I know there have been several bugs and feature requests filed, most prominently Redmine #6626 and #12190.

There's a reference to a "shorthand" source/destination address using

{LAN-56}...

but I cannot find any references to this syntax in the documentation, and using that syntax (both {LAN-56} (and {LAN-64}, which is what I would need) result in error messages

#6626 was closed but it doesn't appear there was a resolution, and #12190 was rejected.

Is there a way to make firewall rules track the delegated prefix?

johnpoz

@jhg just use the lan net or opt net alias.. you can now view them in the tables..

Mine isn't delegated on my lan, but you can see it shows you the networks that in the alias.. This should include your delegated IPv6 prefix, and it should auto update if your delegation changes.

Bob.Dig

@johnpoz said in Delegated prefix in firewall rules?:

you can not

Yes, you can.

And for rules for some hosts you can use aliases by hostnames from DHCPv6.

johnpoz

@Bob-Dig hahaha - thanks.. Have corrected my typo.

jhg

@johnpoz said in Delegated prefix in firewall rules?:

@jhg just use the lan net or opt net alias.. you can now view them in the tables..

Mine isn't delegated on my lan, but you can see it shows you the networks that in the alias.. This should include your delegated IPv6 prefix, and it should auto update if your delegation changes.

If I understand correctly, the way to have delegated-prefix-relative rules is

Ensure the LAN host has an assigned address in DHCP, and is also in the DNS resolver
Create an alias that points to the host's FQDN
Specify that alias in the destination field in the rule definition

I tried this and it seems to work. We'll see what happens if/when my ISP (Comcast) changes my prefix.

Also, this procedure needs to be an explicit section in the manual. I had to do a lot of digging and experimentation to figure this out.

johnpoz

@jhg said in Delegated prefix in firewall rules?:

If I understand correctly,

I don't think you are. What I was saying is the prefix is available via an alias.. Not any specific address..

If you want to control what IPv6 address can talk to another IPv6 address on your different local networks. I would use ULA for this access, these will not change and you can set a specific device to always have the same ULA address, no matter what its GUA might change to or be..

Or just use IPv4 for your intervlan network access..

jhg

@johnpoz I think we're talking about two different things.

In IPv4 I allow external ssh access to an internal host with NAT/Port Forwarding. External ssh clients use the firewall's public IP (published with dynamic DNS), and the firewall routes the traffic to the internal host.

In IPv6 the ISP delegates an entire public /64 prefix and the firewall can assign fixed public IP addresses to internal hosts relative to the delegated prefix. All that is needed then is a firewall rule that allows incoming traffic to the internal host's public /128 IP. Neither NAT nor port forwarding are needed.

If the firewall rule's destination address is hardcoded with the current prefix, a problem occurs when the ISP arbitrarily changes the delegated prefix. A dynamic DNS client running on the target system will pick up the new prefix fairly quickly, but the firewall rule still has the old prefix and now blocks traffic to the internal host.

The procedure I outlined above seems to work, and has the following effect:

ISP initially assigns a delegated /64 prefix to pfSense
I create an alias X that points to FQDN host1.my.lan
In DHCP host1.my.lan is assigned an IP address relative to the delegated prefix, for example []:1.2.3.4 (where [] is the delegated /64 prefix), and is also configured to register the address in the local DNS resolver
The firewall rule specifies
- Source: Any
- Destination: X (alias)
- Port: 22

This allows traffic to be routed to the desired host.

What remains to be seen is whether, when the ISP changes the prefix, the pfSense DHCP service updates the internal host's IP to the new prefix (I believe this does occur) AND then changes the DNS entry so that the alias now points to the new IP.

I'll attempt to force a prefix reassignment and report what happens.

johnpoz

@jhg why do you need to allow IPv6 if you have IPv4 that you can allow in? Sounds like your creating your own grief?

Doctor, its hurts when I hit myself with this hammer..

jhg

@johnpoz Curiosity, and a strong desire to educate myself on the ins and outs of IPv6.

johnpoz

@jhg the ins and outs of IPv6 do not normally include a changing prefix ;) That is just going to cause you more grief trying to learn the other aspects of IPv6 when it comes to firewalling and networking.

If you are just interested in playing and learning IPv6.. You could cut out the nonsense of a changing prefix by getting a free Hurricane Electric tunnel.. You get a /48, that never changes ;) and you can even setup PTR records, etc.

And they provide a test you can run through to test/exercise your understanding - and when you reach sage level, they will even send you a FREE t-shirt.. Its a win/win for sure.

I still wear mine now and then, and its like 12 years old ;)

IonutIT

@johnpoz said in Delegated prefix in firewall rules?:

@jhg just use the lan net or opt net alias.. you can now view them in the tables..

Mine isn't delegated on my lan, but you can see it shows you the networks that in the alias.. This should include your delegated IPv6 prefix, and it should auto update if your delegation changes.

Sorry to steal this thread but I for me those new tables do not work. Setting a rule and using lan__network as alias will not work, creating an alias with lan__network or opt1__network as contents shows blank when viewing that alias in the tables. Tried creating an alias with all my defined networks and added the lan and opt networks and that alias simply did not do anything. Mind you, there was no error or anything in defining aliases with lan__network or optX__network, just that it simply did not work, tables for those aliases were empty.

johnpoz

@IonutIT so your lan_network table is empty? You have something wrong then... It should for sure show your lan network network.. As is mine showing the 192.168.9.0/24 - what is your lan network? the default 192.168.1/24 ?

IonutIT

@johnpoz said in Delegated prefix in firewall rules?:

@IonutIT so your lan_network table is empty? You have something wrong then... It should for sure show your lan network network.. As is mine showing the 192.168.9.0/24 - what is your lan network? the default 192.168.1/24 ?

No, the individual tables themselves are correctly defined and populated, but using them in a firewall rule does nothing, and creating an alias from those tables results in the alias itself being empty

Screenshot 2024-01-28 at 16.46.06.png

Screenshot 2024-01-28 at 16.47.55.jpg

Screenshot 2024-01-28 at 16.48.39.jpg

johnpoz

@IonutIT There is a builtin alias for lan called lan subnets.. And your other networks

Your wanting to create some sort of nested alias? Using those tables? I don't believe that is a "thing"..

If you want a network alias, then create a "network" alias - and put in the cidr's

IonutIT

@johnpoz

Yeah, the idea was to have a nested alias with all my networks both for IPv4 and IPv6, all together nicely in a single alias.

Obviously this can be done for IPv4 by using CIDR notation, but for IPv6 I have dynamic prefix delegation from my ISP so all my VLAN prefixes change at every reconnect/reboot/reload/etc. that's why the idea of creating a nested alias from these new network tables was great.

As for firewall rules, defining individual networks in firewall rules was a thing for a long time, long before these lan__network or optX__network tables showed up in recent updates. The idea is having more than one for the same rule.

johnpoz

@IonutIT I would just use the builtin tables and create multiple rules vs trying to nest it all together.

The builtin say lan subnets will change if your IPv6 prefix changes.. Just can't nest that all together into 1 alias.

Sevi

Sorry to revive this semi-old topic once more, but I ran into similar issues recently (finding a way to make rules with a potentially changing IPv6 prefix) and wanted to share my findings here for posterity. Maybe it helps someone.

@jhg said in Delegated prefix in firewall rules?:

There's a reference to a "shorthand" source/destination address using

{LAN-56}...

but I cannot find any references to this syntax in the documentation, and using that syntax (both {LAN-56} (and {LAN-64}, which is what I would need) result in error messages

This is from the closed feature request #12190 and as far as I can tell, never made it into actual pfSense. The implementation mentioned there is in a fork on Github, but I can't access the referenced repo unfortunately.

The feature from the original issue #6626 (i.e. specifing a "shorthand" in the rules directly, not in an alias) is already implemented, however. Just the syntax is different:

By specifying a firewall rule with an address or network starting with two colons :: it gets expanded to the same address/network with the interface's IPv6 prefix (at least I just checked that on an interface with "Track Interface" in pfSense+ 23.09.1 by inspecting the rules in /tmp/rules.debug).
E.g. if the delegated prefix of the interface is 2001:db8:: then for all rules on this interface's tab

network ::/56 gets expanded to 2001:db8::/56
address ::123 gets expanded to 2001:db8::123

The relevant code can be found here (original diff) or here (current version of pfSense codebase) if anyone is interested.

@IonutIT said in Delegated prefix in firewall rules?:

Yeah, the idea was to have a nested alias with all my networks both for IPv4 and IPv6, all together nicely in a single alias.

@johnpoz said in Delegated prefix in firewall rules?:

The builtin say lan subnets will change if your IPv6 prefix changes.. Just can't nest that all together into 1 alias.

While you cannot do it with aliases from "Firewall > Aliases", you can indeed achieve the same by using interface groups and their corresponding built-in "group network" alias (appears in the dropdown, same as the individual "inferface subnets" alias). You can make a group containing the interfaces you want to bundle together and check under "Diagnostics > Tables" that the corresponding group table contains all the individual networks.

However, there is a bug in the recent version of pfSense+ (23.09) and the corresponding pfSense, which I've discussed in this thread (also this is the original thread about the bug and the bug issue was #15096). Essentially, the group tables would only contain the IPv4 subnets and not the IPv6 ones. But applying the patch mentioned in the thread (commit 1c4ca20d3d5910f126f11221f23e1fa21197f225 ) fixes the bug. The patch should also be included in upcoming releases. Some people have reported issues with the patch, but I've been using it without problems so far (and I don't really see how the code changes (diff / github) should affect anything besides the filter tables).

IonutIT

@Sevi said in Delegated prefix in firewall rules?:

You can make a group containing the interfaces you want to bundle together and check under "Diagnostics > Tables" that the corresponding group table contains all the individual networks.

I've tried to do this, unfortunately creating an alias with those interface groups (defined as LAN__NETWORK, OPT__NETWORK, etc.) results in a blank alias with no members (not even IPv4) and the table rebuild log shows something on the lines of "cannot find hostname lan__network", indicating that it thinks it's a hostname and wants to resolve it. Maybe this is also a bug of 23.09 and we must wait for the next release.

Sevi

@IonutIT said in Delegated prefix in firewall rules?:

I've tried to do this, unfortunately creating an alias with those interface groups (defined as LAN__NETWORK, OPT__NETWORK, etc.) results in a blank alias

We might be talking about different things. If you create an alias under "Firewall > Aliases", this is not what I meant. Apparently dynamic prefixes with this kind of alias will never be possible in pfSense for technical reasons - at least that's what I gathered from the posts cited above. These sort of aliases have to be "constants" in a certain sense.

What I meant is when you go to "Interfaces > Assignments", then at the top, select the tab "Interface Groups" and create a new interface group. You can add the interfaces you want from the list there (multiple selection with Ctrl+Mouse click).

The resulting interface group can be used as a source or destination in firewall rules, in the very same way as the interface itself, it will show up as something like "<Group Name> network" in the dropdown analogous to "<Interface Name> subnets". Since this is also somewhat of an "alias", the terminology might be confusing (it definitely was for me trying to figure this out), but people tend to call these "built-in alias" or something similar, to distinguish them from the user-defined aliases from "Firewall > Aliases".

Note:

As of pfSense+ 23.09.1 the interface groups will only properly work with IPv4 addresses, unless you use the patch above.
There will also be a new tab in the "Firewall > Rules" section for the interface group. You can also use it for rules that should apply to all interfaces, but it may or may not be what you want, check the documentation for that.

IonutIT

@Sevi

Ah ok, I think I got it now, yes. That's a neat little workaround, and it does work. Only (minor) issue is having that Interface Group in the Firewall Rules as a tab, that will get pretty crowded if you want to make lots of these groups.