Firewall rules for IPv6 when prefix is dynamic?
-
I'd like to pass a port to one of my internal host's IPv6 address, but it's not clear to me how to create rules that track the prefix I get from my ISP via DHCP PD but maintain the local part. I can make the local part predictable by means of stateless autoconfig or DHCPv6 or whatever but I don't control the prefix my ISP delegates and I don't want to have to update this manually.
Is there a way to create a firewall rule that will update the prefix for a static local part?
-
This is a very good question! When your network changes when the wind blows from your isp how do you write rules based upon IP?
I use a /48 from HE for my ipv6 needs - my ipv6 address do not change so I have no problems doing rules. But I am very interested to hear some responses to this as well.
-
Aliases
(assuming that you use DHCPv6, DHCPv6 tracks the WAN ipv6 prefix, and you have DHCPv6 enter the assigned addresses into DNS.)
-
And this comes right in line with your temp address space ? garyd9 ;) how do you block temp ipv6 that as well know are something random for privacy ;)
Unless you turn off ipv6 temp addresses in your network you want to control, while I might know that client abc gets specific IPv6 address from dhcp and can allow him access based upon that in the firewall rules. His client will more than likely use for outbound connections one of the random temp IPs it assigns itself based upon the prefix being handed out via RA, etc.
So how do you control access in your network with temp privacy ipv6 space? ;) And then the prefix changing at the whim of your isp also adds complexity.. This is all great discussion topics and falls inline with your other question about tracking these temp ipv6 addresses, etc.
Yes I agree while use of the fqdn the client will register in dns is a great way to allow inbound to your client, say for example its a http server.. Since yes as its IP changes it should register this IP, but problem is aliases only update every so often. So if this changes you could have an outage, etc. While if I have a prefix that doesn't change I make sure client always gets the same global IPv6 address and use this in my rules for inbound access from the public internet. If they are using temp ipv6 for their outbound I have problem controlling this via firewall rules and aliases.. Atleast ones that are not checked on every single time a new session is needed through the firewall.
The new privacy and temp addresses in ipv6 do change the game from ipv4 that is for sure.
-
We don't have a way to craft rules like that for specific hosts just yet. There is a feature request for it, though.
-
And this comes right in line with your temp address space ? garyd9 ;) how do you block temp ipv6 that as well know are something random for privacy ;)
For passing a port from "outside" to "inside", if there's a DHCPv6 assigned address, there's no need to deal with temp IPv6 addresses.
Of course, this doesn't deal with the question of how an "outside" machine would know the full ipv6 address of a machine "inside" your network. You'd have to have some kind of dynamic DNS service (dyndns, no-ip, etc) that allows registering IPv6 addresses and a client for that service running on the target machine inside the network. (Not very many dyndns services offer IPv6 registering. For example, google domains has a dyndns service for IPv4 only.)
That "other" discussion would only come into play for incoming connections if the IPv6 address wasn't in DNS. (For example, it was SLAAC assigned.) Even then, I'd avoid using a temp/privacy address for INCOMING connections.
Yes I agree while use of the fqdn the client will register in dns is a great way to allow inbound to your client, say for example its a http server.. Since yes as its IP changes it should register this IP, but problem is aliases only update every so often. So if this changes you could have an outage, etc.
I'm not completely sure how pfSense works, but I got the impression from somewhere that when the WAN prefix changes, it kicks off a script that updates DHCPv6 configurations. The BIG problem with that (assuming I understand this all correctly) is that if there's a host inside the LAN that has a DHCPv6 assigned address that it JUST got, with a lease time of, for example, 2 days, that the host is going to be happily using an essentially invalid IPv6 address for a day.
At this point, I have no idea what unbound (DNS) is going to show, but DNS has to be accurate before the alias would update (regardless of how often the alias might refresh – which is configurable in system->advanced->firewall and defaults to 5 minutes.)
On the other hand, I know that RADVD also updates when the prefix changes, and a new RA will be seen by the host within seconds. So, that host will self-assign a valid IPv6 in the prefix when it sees an updated RA, and actually ends up maintaining both a valid (from RA) and invalid (from DHCPv6) prefix. For that, I can't offer a good solution.
The honest truth is that our IPv6 toolset doesn't deal with changing prefixes very well. pfSense works better than most router/firewall packages in dealing with it, but it's not perfect (and I'm not sure it can be when "dynamic prefixes" aren't actually part of any ipv6 spec.)
The new privacy and temp addresses in ipv6 do change the game from ipv4 that is for sure.
Oh, yeah… massively. I think part of the problem is that we (generic "we") keep trying to think of IPv6 with concepts that we've learned from IPv4. (Well, that at least applies to me.) The more I fight with IPv6, the more I think that the best way might be to try and forget everything I know about IPv4 and start fresh.
-
We don't have a way to craft rules like that for specific hosts just yet. There is a feature request for it, though.
I think that if the DHCPv6 server configuration allowed creating reservations that tracked the prefix (does it do this now? I don't know), everything would work with aliases (assuming DHCPv6 registered reservations to DNS.) dhcpleases6 would update 'hosts' when the prefix changed. If it doesn't already happen, it should be trivial to force an update of the alias tables as part of that "prefix changed" sequence.– see next message for the results of actually getting off my lazy rear end and trying it.The only problem would be getting DHCPv6 clients to update when the prefix updates.
-
I think that if the DHCPv6 server configuration allowed creating reservations that tracked the prefix (does it do this now? I don't know), everything would work with aliases (assuming DHCPv6 registered reservations to DNS.) dhcpleases6 would update 'hosts' when the prefix changed.
.. this… well.. kind of works.
I selected a vm on my network, and copied it's DUID to pfsense to create a DHCPv6 reservation of "::20:1" in hopes that it would track the interface's prefix. I then did the song and dance needed to get DHCPv6 restarted on the LAN interface and forced the VM to renew on IPv6. The results are confusing:
Assuming that WAN is getting 1:2:3:4560/60, and that LAN tracks that with a prefix ID of "3", the "LAN" network should be 1:2:3:4563/64.
The VM was assigned an IPv6 of 1:2:3:4563::20:1. (That worked)
However, the entry added to hosts was "1:2:3:4560::20:1 virtual10.mydomain virtual10" (Wrong prefix)
The entries added to /var/unbound/host_entries.conf have the same wrong prefix.
That's really confusing when you consider that the "fixed-address6" entry in /var/dhcpd/etc/dhcpdv6.conf is 1:2:3:4563::20:1 (correct prefix)
So, there's a potential bug here.
@jimp, do you know which process is responsible for adding dhcpv6 reservations (not leases) to /etc/hosts? (I know dhcpleases6 does leases.. not sure if it does reservations. I'm also pretty sure that the last time I looked at the source for dhcpleases6, it didn't touch any unbound config files...)