Is a dynamic alias or variable for IPv6 Prefix scheduled?
-
IPv6 will be more and more important and therefore I have to change my infrastructure also. IPv6 is working on Pfsense but I found one use which isn't really solved. It has to do with alias and firewall rules. FW fule is the most important feature of Pfsense.
With IPv4 and NAT the internal devices have static internal addresses. So aliases and fw rules are statically even if the external WAN address will change. Example of a rule: source:any destination 192.168.x.x port:yy
With IPv6 devices have external routable addresses. These are concatenated with prefix id of subnet + device address. Therefore a fw rule must be defined with external addresses, eg. source=any destination=2001b:c:1:2:3:4 port=yy
What happens if the subnet prefix given by the provider changes (like 202ab:c)? All rules are have to be changed manually. Often ISPs provide for private persons dynamic ip addreses only. This means after reboot of the modem the prefix will change always. In this case IPv6 without NAT with Pfsense isn't usable.
My proposal is to implement a prefix variable for each interface which can be used in aliases or fw rules. The names could be "prefix_wan", "prefix_lan", "prefix_opt1" until "prefix_optn". The usage could be like:
aliases: server_alias = "{prefix_lan}1:2:3:4"
fw rule: source=any dest="{prefix_opt2}ac:d" port=80The variable must be filled with current subnet prefix always. If ISP's subnet change all aliases and rules are adapted automtically.
What do other users or developers of Pfsense think about such a feature?
Regards,
Enrica -
As a residential user I really hope something like this gets implemented.
-
Something like this would be an amazing addition to pfSense.
-
I think a better way to do this rather than have a "token" you have to put in the Address box would be to add an entry in the drop-down that specifies things like "This firewall", "LAN network", etc. Have an entry for track-interface networks like… "LAN Prefix" and then allow entering the host portion of the address in the text box.
I suppose a workaround would be to put in a static DHCPv6 entry for the host, with a hostname, then create an alias for the hostname. Since DHCPv6 server is now configurable for Track Interface networks in 2.3, it should update the static DHCP entry if the prefix changes. Of course, that assumes you use DHCPv6...
-
@virgiliomi:
I think a better way to do this rather than have a "token" you have to put in the Address box would be to add an entry in the drop-down that specifies things like "This firewall", "LAN network", etc. Have an entry for track-interface networks like… "LAN Prefix" and then allow entering the host portion of the address in the text box.
Yeah that's how I'd like to see it implemented.
No specific plans to implement this at this time, but it is something I want to see in the future.
-
The way I have gotten around this in the past, is using 1:1 nat ranges;
So using unique local address range on the LAN and 1:1 NAT those with the external global prefix.
I KNOW that the whole point of IPv6 is that you can throw NAT in the bin, but there are reasons why you might consider this as an option.1:1 NAT is a world better than NAT Overload etc.
-
@Virgiliomi, cmb
Thank you for your proposals. I wanted kick-off a discussion about this problem that IPv6 pf rules should work without having NAT to a "static" internal address. I think the problem is recognized.A solution can be implemented in different ways. Important is a split between subnet prefix and local host address part. At the end the final IP address is concatenated. A potential solution could be combined with Multi-WAN (eg. same Host/Server could get two external known IPs where the host part could be the same.
-
@cmb:
@virgiliomi:
I think a better way to do this rather than have a "token" you have to put in the Address box would be to add an entry in the drop-down that specifies things like "This firewall", "LAN network", etc. Have an entry for track-interface networks like… "LAN Prefix" and then allow entering the host portion of the address in the text box.
Yeah that's how I'd like to see it implemented.
No specific plans to implement this at this time, but it is something I want to see in the future.
Hm, how about privacy extensions (default in Windows, OS X, iOS, some Linuxes)? Hosts do not assign themselves the same host identifiers every time. So it seems impossible to enter "the host portion of the address" as part of a firewall rule.
That's a bit lengthy now and I don't know whether this kind of basic thought belongs here. But after understanding the shortcomings of the current implementation of the firewall for IPv6 I believe this will become very relevant soon. I don't know whether I can speed up the process by providing my thoughts on this. But well, here it goes:
In the firewall rules I typically want to refer to a host or group of hosts, not an address per se. With aliases this is already possible. It's just that there is no way I can define an alias for a host based on its IPv6 address. (From my point of view in the GUI it would suffice to be able to enter aliases in firewall rules anyway. Addresses will become very inconvenient with IPv6.)The central idea is the following: In IPv4 via DHCP the router can assign IP addresses and thus has a mapping from host (by MAC address) to IPv4 address. With self assigned addresses in IPv6 there is no such thing anymore automatically. So what's needed is simply a mapping of hosts to IPv6 addresses. Because the router does not hand out such addresses anymore he must be enabled to learn the mapping dynamically from the incoming traffic. Just like in IPv4 this should be based on the MAC addresses. I would call an entry in the mapping an "IPv6 address alias".
This is what's required for this solution to work:
-
In the GUI I want to be able to define a mapping of MAC addresses to Aliases. (This could as well be used for IPv4 but is required only for creation of IPv6 address aliases.) This could look similar to the current DHCP leases page which also shows host names and MAC addresses learned from the traffic. From this page it should be possible to create static mappings to aliases.
-
pfSense should learn IPv6 addresses from LAN traffic and create the IPv6 address aliases based on the MAC address.
-
Firewall should lookup IP addresses for aliases from the dynamic IPv6 address mapping in addition to the statically mapped aliases. (Should not be too much of a problem to build, aliases can be dynamically adapted already today when using FQDNs in aliases.)
-
pfSense should allow to use IPv6 address aliases in host aliases (just like it allows IPv4 addresses). I want to be able to define a single host alias based on its IPv4 address as well as its IPv6 address alias.
-
The IPv6 address aliases should be used to resolve IPv6 addresses of local hosts in the LAN just like DHCP assigned IPv4 addresses right now.
The drawback from security point of view: MAC addresses can be spoofed. This is no bigger problem than with IPv4 currently as long as there is only one routable IPv6 address mapped to an alias. This should probably be sufficient as long as there is only one WAN connection. The security is probably good enough for most home uses.
As an added security feature between the prefix from the ISP (for example /56) and the host identifier there is another part of the prefix which is advertised by the router to make the delegated prefix a /64. If it is possible to refer to this part of the prefix in firewall rules then this can be used for added security (zones) which cannot be circumvented by MAC spoofing. If implemented like in pfSense currently this part of the prefix is bound to an interface. It would be convenient to add some new kind of alias for this prefix to refer to in the firewall rules. This kind of security if probably relevant for commercial and / or large networks.
-
-
To bring this one back up, I created a feature request for the ability to have a firewall rule with a dynamic prefix + static host address.
https://redmine.pfsense.org/issues/6626
-flo-, on your comment about privacy extensions… You'd need to either use the EUI-64 SLAAC address (by disabling privacy extensions) or use a static DHCPv6 entry for this to work in the implementations proposed here.
I think what you're asking for would be great in the grand scheme of things... but I expect that the amount of work to get to that point would be significant (I'm not a developer, but bringing together that amount of stuff sounds like it wouldn't be a simple undertaking). I think it would be a lot easier, at least in the short term, to add an option to specify a dynamic prefix and allow a static host portion to accomplish this.
-
@virgiliomi:
-flo-, on your comment about privacy extensions… You'd need to either use the EUI-64 SLAAC address (by disabling privacy extensions) or use a static DHCPv6 entry for this to work in the implementations proposed here.
I think this is perfectly fine. And you don't need to disable privacy extensions to use the SLAAC address, since v6 interfaces with them turned on will have both addresses. This is the way it's intended to be in v6 (i.e. use the temp privacy address for outgoing connections, and the static SLAAC address for incoming).
-
@virgiliomi:
To bring this one back up, I created a feature request for the ability to have a firewall rule with a dynamic prefix + static host address.
https://redmine.pfsense.org/issues/6626
-flo-, on your comment about privacy extensions… You'd need to either use the EUI-64 SLAAC address (by disabling privacy extensions) or use a static DHCPv6 entry for this to work in the implementations proposed here.
I think what you're asking for would be great in the grand scheme of things... but I expect that the amount of work to get to that point would be significant (I'm not a developer, but bringing together that amount of stuff sounds like it wouldn't be a simple undertaking). I think it would be a lot easier, at least in the short term, to add an option to specify a dynamic prefix and allow a static host portion to accomplish this.
I think it's a great idea for prefix to be a variable in the firewall rule, since it is dynamic at the discretion of the ISP. ipv6 unfortunately still isn't pervasive enough that you can depend in it being available everywhere, but I hope it's not long from now that we will be able to rely upon a global address (with DDNS) for a machine (e.g., for remote desktop or VNC), rather than messing with ipv4 / NAT and port forwarding.
-
The names could be "prefix_wan", "prefix_lan", "prefix_opt1" until "prefix_optn".
Doesn't pfSense already support "LAN net" and "LAN address"? Do those track local address prefix? Also, as I mentioned in another thread, perhaps filtering on MAC address, as some other firewalls do, would be useful.
-
@virgiliomi:
-flo-, on your comment about privacy extensions… You'd need to either use the EUI-64 SLAAC address (by disabling privacy extensions) or use a static DHCPv6 entry for this to work in the implementations proposed here.
I think this is perfectly fine. And you don't need to disable privacy extensions to use the SLAAC address, since v6 interfaces with them turned on will have both addresses. This is the way it's intended to be in v6 (i.e. use the temp privacy address for outgoing connections, and the static SLAAC address for incoming).
Yes, but: Blocking outgoing trraffic would just not work this way because the firewall does not know the temporary addresses. Actually if the firewall is not enabled to know the self assigned IPv6 addresses of hosts then the privacy extensions will not work (or there will be no safe way of blocking outgoing traffic).
Using a DHCPv6 would work of course but that would be a pity.
-
What about a little checkbox on each static DHCP server entry and the range field titled 'RSL Privacy' – Randomize Short Lease? The manual entry would read: "If RSL" is checked, the address given will be assigned randomly within the pool, and it will be re-assigned every eight hours or when there are no active states in the table, whichever comes second"
-
Yes, but: Blocking outgoing trraffic would just not work this way because the firewall does not know the temporary addresses. Actually if the firewall is not enabled to know the self assigned IPv6 addresses of hosts then the privacy extensions will not work (or there will be no safe way of blocking outgoing traffic).
Using a DHCPv6 would work of course but that would be a pity.
Well, if you need to control outgoing traffic for individual hosts, I think DHCP-assigned addresses are the best solution. With SLAAC, you don't really know how the host constructs the host ID. E.g. Windows doesn't use the MAC address, but a random ID, which can change if the host is re-installed.
-
think DHCP-assigned addresses are the best solution.
Further up the thread, I mentioned filtering on MAC addresses. That can be done on Linux, with IPTables and with at least some Cisco gear. This could easily solve the problem, as then you wouldn't have to worry about what local IP address was. According to what I found with a Google search, pfSense is supposed to be able to filter on MAC, but I don't see any way when setting up a rule.
-
Further up the thread, I mentioned filtering on MAC addresses. That can be done on Linux, with IPTables and with at least some Cisco gear. This could easily solve the problem, as then you wouldn't have to worry about what local IP address was. According to what I found with a Google search, pfSense is supposed to be able to filter on MAC, but I don't see any way when setting up a rule.
Filtering on L2 is not straightforward with ipfw/pf in FreeBSD (AFAIK the only way to do it is to tag the packet on the interface and then filter based on the tag). Also, it doesn't help when filtering ingress traffic for a host on the WAN interface, or when the packet is coming from another internal subnet.
But what is the problem with using DHCP? You can also run in "assisted" mode to run hosts using SLAAC and DHCP in the same subnet.
Another good solution would be SLAAC with RFC 7217 identifiers, but it's unfortunately not widely supported yet.
-
With SLAAC, you don't really know how the host constructs the host ID. E.g. Windows doesn't use the MAC address, but a random ID, which can change if the host is re-installed.
I envisioned a self learning feature in the firewall for this reason based on the MAC address.
Does Windows really not use the MAC address in Ethernet frames?? I wasn't aware of this. Does Microsoft give any reason for this behavior? How should network infrastructure be able to identify a host then? This seems very strange to me, but hey, I'm not a network engineer. :-)
-
Does Windows really not use the MAC address in Ethernet frames??
You can't have Ethernet without MAC addresses. It's how a NIC decides whether a frame is addressed to it. On the other hand, SLAAC IPv6 addresses can be based on the MAC or a random number. Either or both can be used, depending on configuration. I prefer to use both, so that outgoing connections have a random address, but the DNS points to the MAC based addresses, for incoming connections.
-
Does Windows really not use the MAC address in Ethernet frames?? I wasn't aware of this. Does Microsoft give any reason for this behavior?
By default Windows builds SLAAC addresses using random interface IDs for privacy and security reasons (so the device's MAC addresses don't leak out to the Internet). These IDs remain static for the lifetime of the OS installation (they are stored in the Windows registry). You can disable this though, in which case it uses the EUI-64 like most other operating systems.
Note that Windows can create temporary privacy addresses in addition to that.
How should network infrastructure be able to identify a host then?
You can in principle use the SLAAC addresses produced by Windows just like those produced with EUI-64, since they remain static as long as the OS isn't re-installed.
Generally, you can never rely on any v6 device using EUI-64 to build the SLAAC addresses, since the RFCs allow other types of ID as well.
Another issue are the temporary privacy addresses that most OSs generate. Very difficult to manage for things like logging, audit, filtering etc.. That is one reason why admins often prefer to assign addresses via DHCP, because it effectively disables the use of privacy addresses.