-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
firewall: Allow dynamic IPv6 prefixes in rules #3247
Comments
|
I don't think pf has an option like this, at least not as far as I could find. It might be good to know how other vendors solve this, adding keywords like |
|
Dynamic ipv6 prefixes in the firewall is not the solution unfortunately. Almost everyone implement RFC7217 today (aka "stable privacy"), which mean the last 64 bits of the ipv6 address change when the host receives a new prefix. There is no pretty solution for this problem. There is a feature request to allow NPT rules to be dynamically updated when the upstream prefix changes With this feature, you could use ULA in the LAN. It also solves the multihoming problem |
If you mean the clumsy The best thing would still be to simply match the last n bits of an IPv6 address. After thinking about this you could even include the static subnet id in the rule to make it a perfect match. The iptables equivalent (for subnet id @AdSchellevis Are you sure
RFC 7217 is about opaque interface identifiers, which do not make sense for servers. For servers you want stable interface identifiers. And for stable identifiers there are two easy (and more or less pretty) solutions (sorry for being off-topic here, but it might explain why we need dynamic prefixes in firewall rules):
I agree that NPTv6 (which ATM is still a draft only) can kind of work around the current firewall limitation, but it's still much more elegant (and desirable) to assign public IPv6 addresses to your servers. Especially since we live in times where many people are getting /56 prefixes from their ISPs. |
|
@klada you can easily check on the machine what pf supports and what it doesn't |
|
Klada, I know what static reservation and ipv6 token are but I don't understand why you are focusing on servers and ignoring all the other kind of hosts... For exemple, Android doesn't support (yet) DHCPv6 or the ipv6 token, the same for a lot of IoT crap. Aside from bgp/ipv6 PI, NPT is the only solution who can provide easy multihoming and prefix independence no matter the kinf of hosts you have on your network. It's doesn't matter if it's only a draft, it's supported by Cisco, Juniper, Palo Alto, Linux and FreeBSD. It's only my opinion but I think NPT will be massively used by the people who can't afford a BGP peering with their provider. |
|
Same as #2544 if we widen the scope. Please direct discussion there. |
Is your feature request related to a problem? Please describe.
Unfortunately many ISPs only hand out dynamic IPv6 prefixes. IPv6-enabled hosts/servers behind the firewall might have a static IPv6 interface address with a dynamic prefix part (e.g. assigned through
ip tokensin Linux).Right now it is impossible to add IPv6 firewall rules for individual hosts with dynamic prefixes.
Describe the solution you'd like
A trivial approach would be to match only the last 64 bits of an IPv6 address, thus ignoring the entire prefix. In Linux (with ip6tables) you can invert the network mask, so you ignore the prefix and only match the host part. This can be done like this:
I think this is a very convenient approach which resolves most issues with changing prefixes in IPv6 firewall rules. I don't know if
pfactually supports inverting the network mask, but if it does this would probably be the easiest way of supporting dynamic prefixes.If the outbound interface could also be specified we wouldn't have to worry about address collision in situations where the host part is not unique across IPv6 subnets.
Describe alternatives you've considered
If matching the last 64 bits is not possible, a syntax like
${PREFIX_LAN}:192:168:20:1for host aliases would probably also get the job done. The disadvantage would probably be that the aliases would need to be reloaded each time the tracked IPv6 address changes on the relevant interface.The text was updated successfully, but these errors were encountered: