Feature #6626
closed![Author: Anonymous](/images/anonymous.png?1678052115)
Support for IPv6 firewall entries with dynamic delegated prefix and static host address
Added by Anonymous about 8 years ago. Updated 3 months ago.
0%
Description
When using an ISP with dynamic prefix delegation, the prefix may change at any time, resulting in a change of the IP address of a host. A mechanism needs to be added to the firewall rule setup that allows the prefix of an interface to be dynamically updated should it change on the interface, while still allowing the host portion of the address to be static. This way firewall rules for a host can be updated automatically, allowing it to retain access in the event of a prefix change.
One possible way to do this would be to add an item to the Destination drop-down (i.e. LAN Prefix) and allow the host portion of the address to be entered into the text box.
Another possible way would be to have a token that could be entered into the Address box, that is replaced with the prefix during rule generation.
However this is implemented, validation should reject the rule with an error if the protocol is IPv4 or IPv4+IPv6.
My personal preference would be the drop-down box, but I leave this decision to whoever is implementing this feature.
Updated by Corey Boyle almost 8 years ago
Another place this would be handy is when configuring server options in DCHPv6 and RAs.
Updated by Frederick Staats over 7 years ago
I would also like to see such a feature. My work around currently is to manually create an aliases that contains the full prefix network delegation and use that in our rules. This allows me to set a simple rulesets between my ipv4/ipv6 VLAN. Note: with aliases you can mix ipv4/ipv6 addresses and any prefix notation should still allow that. I think the implementation could be as simple as a text macro substitution in the aliases definitions and an automatic trigger to reparse and save automatically save updated aliases when the prefix delegation changes.
Typically I whitelist allow rules at the network level (VPN_A net can talk to VPN_B net, VPN_A net can talk to WAN net, etc.) and then set a few deny rules (All nets nets can not talk to Internal nets [my delegation prefix alias containing all configured ipv4/ipv6 networks], all nets can not talk to private addresses [another alias], all nets can not talk to firewall [a built in alias]), and then set a blanket permission rule to talk to the internet (VPN_A net can talk to all nets.)
My problem is that anytime the prefix delegation gets reset (an extended power failure, I reconfigure the WAN) I'm left with a hole in my firewall rules between delegated IPv6 networks until I remember to fix the alias. With dynamic DNS I can set a script to detect the issue, but I would still rather make rules that can observe the prefix delegation dynamically.
Updated by Frederick Staats over 7 years ago
Note I also have the issue with configuring DHCPv6 and RAs and in configuring somme OpenVPN configurations that are internal address aware.
Updated by Graham Gudgin almost 7 years ago
I would like to see support for this added as I have switched my home router to use pfSense and run into the same issue. On my previous consumer router I was able to add a netmask to my IPv6 rule that ignored the prefix portion and only matched on the host portion. Not an exact match, but hey, more than close enough.
i.e. 2601:1234:1234:1234:abcd:abcd:abcd/::ffff:ffff:ffff:ffff or the lower 64 bits
Currently updating the alias for server's IPv6 address should my prefix change that is assigned.
Ideally agree with being able to add a host with a <LAN Prefix> variable that tracks the LAN network prefix the is delegated and I can add the static host portion.
Updated by Lukas Kuzmiak almost 6 years ago
Same issue as Frederick described - I can't seem to be able to effectively block inter-vlan traffic for IPv6 as the addresses change (dynamic PD prefix).
Updated by Elv Quant over 5 years ago
On generating the interface identifier using EUI-64 (based on MAC address), the interface identifier are independed by the prefix. So it is able to use only the interface identifier for the firewall rule and internaly add the prefix, even it changed for the delegated network.
BUT
Newer versions of operation systems implements RFC-7217 (Semantically Opaque Interface Identifiers) and/or RFC-3972 (Cryptographic Generated Address). In this case the interface identifiers contains hash-values which are depend by the prefix. So the interface identifier changing the prefix changed.
SOII and CGA can by disabled on debian 16.04ff and macOS 10.12ff by changing sysctl-parameters and on rasbian jessie ff changing slaac from private to hwaddr. But should we restrict new security features to get back the EUI-64 interface identifier?
EDIT:
My idea are to define a rule based on an "alias" and make it possible the client in the delegated net can update the alias with it's new IPv6 (secured by token)
Updated by Pim Pish about 5 years ago
I think this issue really needs to be adressed ASAP. If I understand this correctly it means that today the best workaround is to disable IPv6 completely because you effectively cannot deny traffic in between local nets. Disabling IPv6 on the other hand doesn't seem to be a reasonable option in nowadays networking landscape since IPv6 becomes more and more important.
I think we would need a variable that always keeps the current delegated prefix ID so that we can define rules based upon this.
With such a variable we could define rules that affect jut the prefix ID + network portion or we could even define rules like:
allow SSH for *prefixID*-*mynetwork portion*-*interface ID*
Updated by Nathan Stansell about 5 years ago
Same issue here. I need the ability to filter/firewall some hosts IPV6 traffic just the same as IPV4 traffic. Right now its either all or none for IPV6 when it comes to firewall rules. Im not sure how this has not been resolved yet? Not complaining as much as im just not sure how this isnt a bigger deal. Seems pretty basic to me, the need to have firewall rules work on single hosts or alias's.
Ideally, the ability to specify a single IPV6 address as an alias would be best. I can assign ::1001 to a machine, why cant i filter based on the same ::1001 instead of requiring the entire V6 address? It seems this should work as i can input ::1001 in an alias, it just does not function despite not throwing an error when saving.
Updated by Michael Smith about 5 years ago
A global variable with the current delegated IPv6 prefix in CIDR form, which could be used in firewall aliases would be a nice start :-)
Updated by B P over 4 years ago
The global prefix variable should be available to the Dynamic DNS tool as well. Currently the Dynamic DNS tool has an `%IP%` variable that can be used to fill in the WAN's IPv4 or IPv6 address, but it would be nice to also have IPv6Prefix here to allow pfSense to update DNS entries for servers on pfSense's LAN.
What would be required internally to create this? Would the existing Alias code be sufficient for this with some modification? Or does this require the creation of a new Prefix type?
Without looking at the code, I feel like a new Prefix type would be best. Then rather than touching every location in the UI (and code) that consumes aliases, we could allow Prefixes to be used in Aliases (and nowhere else) and then a user could create a new Prefix, make an alias that uses that prefix, and then use the alias just as they do normally.
Or maybe a new customizable prefix type isn't required and we just allow the use of something like WANPrefix inside an alias definition.
Updated by A J over 4 years ago
This issue should be adressed in the near future, as it may prevent the use of IPv6 in some instances, where filtering and blocking is needed.
Updated by mpfusion _ about 4 years ago
This issue should get a higher priority IMO. It renders IPv6 pretty much inoperable on (domestic) connections with changing prefix as there's no practical way to create firewall rules.
Updated by Netnewb net about 4 years ago
Some form of management for dynamic PD for IPv6 would be nice. It seems there are several, maybe many, ISPs that are running out of IPv4 but won’t implement static IPv6.
Management is cumbersome but still doable. I’m using static DHCPv6 assignments which get registered in DNS. Then I’m creating Aliases for those DNS entries and finally, firewall rules with Aliases. I’m managing only several hosts this way though.
Updated by Mike Murdoch about 4 years ago
Hello,
we are also in dire need of this feature. Lack of support for dynamic prefixes makes IPv6 pretty much unusable in our scenario.
Thanks!
Updated by A J over 3 years ago
This request is now 4,5 years old and has not seen any relevant activity.
As ISPs in Europe still provide users with only temporary IPv6 prefixes and most likely continue to do this in the future, I will probably switch to Mikrotik, as their RouterOS doesn't support this natively, but there seems to be an pretty easy workaround: https://forum.mikrotik.com/viewtopic.php?t=168470 / https://web.archive.org/web/20201231173931/https://forum.mikrotik.com/viewtopic.php?t=168470
Updated by Viktor Gurov over 3 years ago
Allow to use host portion of IPv6 in firewall rules:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/134
Updated by Jim Pingle over 3 years ago
- Status changed from New to Pull Request Review
- Target version set to CE-Next
Updated by Renato Botelho over 3 years ago
- Status changed from Pull Request Review to Feedback
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
Updated by Jim Pingle over 3 years ago
- Target version changed from CE-Next to 2.6.0
Updated by Jim Pingle over 3 years ago
- Subject changed from Allow IPv6 firewall entries with dynamic PD prefix + static host address to Support for IPv6 firewall entries with dynamic delegated prefix + static host address
Updating subject for release notes.
Updated by Jim Pingle over 3 years ago
- Subject changed from Support for IPv6 firewall entries with dynamic delegated prefix + static host address to Support for IPv6 firewall entries with dynamic delegated prefix and static host address
Updating subject for release notes.
Updated by Jim Pingle about 3 years ago
- Target version changed from 2.6.0 to 2.5.2
Updated by Greg Wallace about 3 years ago
This appears to only be partially resolved. While using ::0/56 as a 'destination' on a Rule works, using the same ::0/56 on an Alias and then setting the Rule 'destination' to that Alias fails.
Updated by Nathan Stansell about 3 years ago
Did you get this figured out by chance? I was going to spend some time this weekend setting up IPV6 but if its still not working yet, there is no need as I use alias's also.
Updated by Jim Pingle about 3 years ago
It works as intended for entries on rules.
It cannot work on aliases because aliases are not associated with an interface, and delegated prefixes are specifically associated with an interface.
The underlying software does not give pfSense knowledge of the entire prefix, or a list, so it only has the specific prefixes assigned to interfaces with which it can work.
Updated by Nathan Stansell about 3 years ago
So another feature request is needed for the ability to use IPV6 with rules that use alias's?
Updated by Jim Pingle about 3 years ago
That would be a separate request, yes, but as I mentioned it's not currently possible to implement. There isn't any way for an alias to know how to resolve that prefix since there is no association with an interface, and even if it did have a list of prefixes available, there isn't a way for an alias to know which one to pick since it's a completely ambiguous situation.
Aliases are global objects, a single copy used potentially by multiple rules on multiple interfaces. Telling it you want ::blah/prefix would not be viable since it has no way to know what to fill in there when the ruleset it generated. Even with a prefix list available there isn't a viable way to figure out the intent without doing things like making multiple copies of the alias (one for each interface) which doesn't scale well and has its own share of problems.
So while you can make a new feature request, I wouldn't get your hopes up about a viable implementation appearing.
Updated by Nathan Stansell about 3 years ago
Ok, thanks for the response.
How does someone use IPV6 with dynamic assignments, and firewall rules?
I am a home user of PFSense so i not an expert.
I feel like i must be missing something as not being able to use IPV6 with firewall rules seems fairly restrictive.
Am i being a newb and am unaware of how to use dynamic IPV6 addresses with a firewall correctly?
Thanks for your time in responding. Ive been waiting years for this issue to be resolved, thinking it would address this issue.
This is the single reason i do not use IPV6.
I have kids and want the internet to turn off at night.
My ISP determines how address's are assigned so i have no choice but to use dynamic address's.
What's a person to do?
Is there another firewall option with a solution to this that someone can point me to?
Or a site/page that will help me figure out how to use this properly if its my hangup on how im trying to use it.
Updated by Jim Pingle about 3 years ago
Most of those are items for discussion on the forum, not a bug report.
You can use these shorthand notations in firewall rule source and destination fields directly, just not in aliases.
Updated by Nathan Stansell about 3 years ago
Well, i know IPv6 firewall entries with dynamic delegated prefix and static host address's are not supported when using alias's.
With alias's being such an integral part of rules, and rules being such an integral part of a firewall, im not sure how this counts as resolved.
Hence posting on here in case other people are confused as i am.
Updated by Jim Pingle about 3 years ago
It's resolved because they work on rules directly, which as I explained in my comments above is the only solution currently possible. Also, aliases are not mentioned in the original request. Aliases are fundamentally different than rules, despite their usual association.
Rather than leave this open and expand the scope to include aliases and keep kicking it down the road indefinitely, we consider this to be as complete as it can be given the fundamental incompatibility with aliases I described above.
Making it work with aliases would be a separate request. See my other comments for details.
Updated by Nathan Stansell about 3 years ago
Regardless, this is not the place so i created a forum post.
If you might be so kind as to offer some advice there, it would be appreciated.
https://forum.netgate.com/topic/164971/ipv6-and-firewall-rules-my-newb-is-showing
Updated by Greg Wallace about 3 years ago
I opened Feature #12190 to address the remaining issues/considerations.
https://redmine.pfsense.org/issues/12190
Updated by Thilo Gass over 2 years ago
May someone provide me a link to documentation of this long awaited feature…
I‘ve searched the hole day how to setup the fw rule…. ;-O
Updated by Nathan Stansell over 2 years ago
Thilo Gass wrote in #note-37:
May someone provide me a link to documentation of this long awaited feature…
I‘ve searched the hole day how to setup the fw rule…. ;-O
Good luck if you are working with alias's.
I've been told it works, but it doesn't work with alias's so its 100% useless for me.
I was told (in a nutshell) that making it work with aliases is too much coding work for too little return.
Updated by Thilo Gass over 2 years ago
My workaround with alias is to setup an alias with a fqdn and let the server update this fqdn with his new ipv6 Adresse on prefix change… :-)
In https://redmine.pfsense.org/issues/12190 you find the information:
Format for source or destination address is {LAN-56}2601:db8::dead:beef
but I’m not able to generate a valid dest entry
Today I tested OPNsense in a VM: there you can use an alias.
Updated by xpxp2002 xpxp2002 over 2 years ago
Thilo Gass wrote in #note-39:
My workaround with alias is to setup an alias with a fqdn and let the server update this fqdn with his new ipv6 Adresse on prefix change… :-)
In https://redmine.pfsense.org/issues/12190 you find the information:
Format for source or destination address is {LAN-56}2601:db8::dead:beef
but I’m not able to generate a valid dest entry
Today I tested OPNsense in a VM: there you can use an alias.
I just gave in and configured NPt for each of my subnets.
I don’t like it in principle, but everything internal uses private address space and whenever my delegated prefix changes I only have to update the NPt mapping.
Updated by Thilo Gass over 2 years ago
Thilo Gass wrote in #note-39:
In https://redmine.pfsense.org/issues/12190 you find the information:
Format for source or destination address is {LAN-56}2601:db8::dead:beef
In 2.6.0 there is still:
The following input errors were detected: {LAN-56}2601:db8::dead:beef is not a valid destination IP address or alias.
Any hints…?
Updated by Thilo Gass over 1 year ago
Thilo Gass wrote in #note-39:
Format for source or destination address is {LAN-56}2601:db8::dead:beef
but I’m not able to generate a valid dest entry
Anyone successfull on that?
Updated by Robin Kluth 4 months ago
Anyone who searches the mentioned PR above: https://github.com/pfsense/pfsense/commit/7c4b3d3c8d2d15b1e59d1d262cc295a848434355
Updated by Jan-Jonas Sämann 3 months ago
In addition to the previous commit, which introduced the basic ability to auto build rules on-top of dynamic prefixes, I have developed a proof of concept to support a granular selection which delegated prefix should actually be used based on the (tracked) interface. This way we are now able to directly address a single host instead of a wildcard over the entire delegation.
So a use-case would be to create a rule in WAN with pass destination address ::80%vtnet1 port 443/tcp to expose port 443 on a webserver living in the LAN network (configured via slaac with ip token set ::80)
My version now supports addresses in form of ::dead:beef%vtnet1 where the interface name is then used instead of the rules parent interface to lookup the target prefix. The %iface notation was already implemented and primarily used for link-local addresses.
Commit can be found here: https://github.com/Sprinterfreak/pfsense/tree/ipv6-pd-rules
A PR will follow after a brief discussion, review and testing.
This also provides a solution to requests of for instance Thilo Gass.