Delegated prefix in firewall rules?
-
@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
-
@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
-
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.
-
@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.
-
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 is2001:db8::then for all rules on this interface's tab- network
::/56gets expanded to2001:db8::/56 - address
::123gets expanded to2001: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). - network
-
@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.
-
@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.
-
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.
-
@Sevi said in Delegated prefix in firewall rules?:
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.
I don't know if you are aware and I know, it is not what was asked here about, but you can create aliases for dynamic IPv6 hosts with the help of the DHCPv6 Server and a hostname given by DHCPv6. You then can create an alias from that hostname the same way you can do that with IPv4 and it will change.
-
@Bob-Dig Good point! I believe that approach was mentioned in one of the posts above.
As far as I understood it, the limitation with aliases, is that they cannot be something that would expand to different things in different contexts, e.g. depending on which interface the alias is used on. But a FQDN that gets translated through DNS works of course (For my own network, I just didn't want the hassle of setting up DHCPv6 in parallel to my IPv4 DHCP at the moment
). -
@Sevi said in Delegated prefix in firewall rules?:
patch should also be included in upcoming releases
ref: https://docs.netgate.com/pfsense/en/latest/releases/24-03.html#aliases-tables
@Sevi said in Delegated prefix in firewall rules?:
address ::123
Hmm, thanks, will try that. Our IPv6 prefix at home changed recently and my main client (wife) was annoyed for a while without telling me.
@johnpoz said in Delegated prefix in firewall rules?:
free Hurricane Electric tunnel
We did that once because of a specific setup...it functions, but the throughput is throttled, about 35 Mbps as I recall. And there are sites that consider HE IPs like a VPN and block access, for instance sites that can only show video or sports content to certain regions due to licensing.
