How to create IPv6 firewall rules?
-
We got into this discussion because @zjgn said:
"Thanks for your input. Those bug reports confirm that IPv6 in pfSense isn't really usable as of now (at least on domestic connections), which is a great shame.To which I replied:
If the ISP is not respecting the Do not allow PD/Address release setting, how is that pfSense's fault?If that setting works with some ISPs, but not others, is the problem with pfSense, as @zjgn implies? Or the ISP, as I suggest? It seems to me this wouldn't affect only pfSense, but any firewall/router that uses DHCPv6-PD, so @zjgn shouldn't be blaming pfSense for something beyond it's control.
-
@JKnott The "Do not allow PD/Address" is not even relevant in this descussion. When you are getting your IP prefix via DHCP, that means you get it dynamically. If you copy this dynamic prefix into a static configuration, you are doing it wrong. Period. If you have a dynamic prefix, all settings you want to use have to support that. If you have a static prefix, configure it statically and do not get it via DHCP!
Settings in pfSense that do not support dynamic prefixes (some even do already, like e.g. the IP configurations for LANs that have the "track interface" option) are just not usable in this scenario. You may call it a bug or you might call it just missing features, but it's pfSense's task to support dynamic prefixes ideally for all settings. It can be done and as it was mentioned before, they are working on it, it's just work that has to be done, and as pfSense has many features compared to other routers (e.g. not many routers support Multi-WAN at all), it's much work. Therefore I cannot follow your conclusion "It seems to me this wouldn't affect only pfSense, but any firewall/router that uses DHCPv6-PD, so @zjgn shouldn't be blaming pfSense for something beyond it's control.".
"Do not allow PD/Address" is just a workround that works in some situations, but it is not a static prefix/address. Period.
-
@HG said in How to create IPv6 firewall rules?:
The "Do not allow PD/Address" is not even relevant in this descussion. When you are getting your IP prefix via DHCP, that means you get it dynamically. If you copy this dynamic prefix into a static configuration, you are doing it wrong. Period. If you have a dynamic prefix, all settings you want to use have to support that. If you have a static prefix, configure it statically and do not get it via DHCP!
Who's copying an address into a static config? I am using DHCPv6-PD. Always have. When I use that setting, my prefix does not change. Is that not the purpose of it? According to my understanding, if that setting is not enabled, pfSense will tell my ISP to release my prefix and that's exactly what was happening before it was available. A loose comparison would be DHCPv4 static mappings. DHCP is still being used, but the address doesn't change. Even without that, DHCP addresses don't normally change, unless the lease has expired and the address is no longer available. With my ISP, my IPv4 address is virtually static. It only changes when I change hardware. Other than that, there was one occasion several years ago, when they renumbered the network, which forced an address change on everyone. By comparison, without that setting, my prefix would change if I did nothing more than disconnect/reconnect the WAN cable, which made it even worse than plain DHCP on IPv4.
-
You both have valid reasons.
I for myself think that the first thing that should be made possible in pfSense is the integration of NPt for dynamic prefixes, should be rather easy to implement by now.What I can't tell is, if it would solve all the problems with the lack of fine control over IPv6 we now have over IPv4...
Privacy extensions maybe could be implemented at the router level and not the host level? That potentially would help for example.
Or better, the firewall just knows all the hosts with all their addresses, however this is possible.
This fine control is probably the reason why we are using (and loving) pfSense in the first place. -
@Bob-Dig said in How to create IPv6 firewall rules?:
Privacy extensions maybe could be implemented at the router level and not the host level?
????
Privacy extensions are host addresses. They have to be on the host.
-
@JKnott said in How to create IPv6 firewall rules?:
@Bob-Dig said in How to create IPv6 firewall rules?:
Privacy extensions maybe could be implemented at the router level and not the host level?
????
Privacy extensions are host addresses. They have to be on the host.
See it in the context of the problems we got now in pfSense. But first you have to see the problems.
-
I believe the relevant part of the original question is:
"How to create firewall rules if I don't know the address of the hosts?"
@zjgn was trying to solve a problem that doesn't exist, due to his unfamiliarity with IPv6 and privacy addresses. I pointed out that he only had to worry about the consistent address, which is often based on the MAC address, but could also be a random number. This is the address that's used for incoming connections and for which the rules have to be written. The privacy addresses are normally used for outgoing connections, which are blocked for incoming connections by default. As mentioned, if privacy addresses are a problem, they can be disabled. Then you mentioned using NPt, for some reason, and the discussion moved into how that didn't work because the prefix was changing, etc.. Does that sum it up? The next question is why the prefix is changing. I maintain it shouldn't, when Do not allow PD/Address release is set, though I know some ISPs will change the prefix anyway. This reminds me of when some ISPs would frequently change the IPv4 address, when there was no need to. In short, they were just being nasty.
-
@JKnott said in How to create IPv6 firewall rules?:
@Bob-Dig
"How to create firewall rules if I don't know the address of the hosts?"No, the problem we are facing is that pfSense doesn't know all the addresses of a host and therefore we can't create granular firewall rules, especially for outgoing connections, like we could for IPv4.
-
@Bob-Dig said in How to create IPv6 firewall rules?:
No, the problem we are facing is that pfSense doesn't know all the addresses of a host and therefore we can't create granular firewall rules, especially for outgoing connections, like we could for IPv4.
Well, given that privacy addresses come and go by design, there's no way around that, short of filtering on the MAC address, which pfSense doesn't do.
-
@JKnott said in How to create IPv6 firewall rules?:
Well, given that privacy addresses come and go by design, there's no way around that, short of filtering on the MAC address, which pfSense doesn't do.
Then I hope pfSense will get there.
-
Perhaps DDNS and use that hostname in rules? https://duckduckgo.com/?t=ffab&q=ddns+for+ipv6&ia=web
-
@teamits said in How to create IPv6 firewall rules?:
Perhaps DDNS and use that hostname in rules? https://duckduckgo.com/?t=ffab&q=ddns+for+ipv6&ia=web
Perhaps read the thread before posting crap.
-
Well the initial and one of the important questions in this thread was to create something like this, so e.g. an alias for all internal addresses.
@zjgn said in How to create IPv6 firewall rules?:
internal_nets = 10.0.0.0/8, 192.168.0.0/16To solve this specific problem, you do not need to know all the addresses or whatever. You only need the possibility to use the dynamic prefix in firewall aliases, e.g. if you have a /56 prefix:
internal_nets = $WAN_IPV6_PREFIX/56or even
internal_nets = $WAN_IPV6_PREFIX/$WAN_IPV6_PREFIX_SIZEwhere pfSense automatically substitutes $WAN_IPV6_PREFIX with the prefix it got via DHCP on that interface. Unfortunately not possible right now, but this could be a option from UI perspective how firewall aliases could be extended to work with dynamic prefixes. Could also be a drop-down in the web interface or whatever.
Another solution, if https://redmine.pfsense.org/issues/4881 is implemented, you can configure static ULAs for the internal communication and easily use these addresses in firewall rules because they are really really static, not somewhat sometimes temporary pseudo-static as with "Do not allow PD/Address release".
This only thing that's really hard from conceptual perspective (on IP level), but that has nothing to do with DHCP at all and is also not solved by "Do not allow PD/Address release", is if you want to block individual temporary privacy IPv6 addresses. But everything that is because of the prefix changing could be solved by something like a $WAN_IPV6_PREFIX placeholder (or drop-downs in the UI or whatever). Don't get me wrong, I know that it's not easy to integrate it everywhere and I understand that it takes time, but it's the clean solution that's needed to be able to use the full functionality of pfSense with delegated prefixes via DHCPv6.
-
@HG said in How to create IPv6 firewall rules?:
not to use IPv6 for internal communication for now (only for Internet communication
These days, a bunch of Microsoft (Apple also) devices will use IPv6 for the local network 'Neighbourhood', using auto assigned address. pfSense couldn't even stop them doing so.
So "you" are using it.
Exception : you step down form the default network settings : de activate IPv6 on every LAN type device.
But why would you ? -
@Gertjan said in How to create IPv6 firewall rules?:
pfSense couldn't even stop them doing so.
Not sure how you figure that, via their cell connection.. Yeah your right they are most likely using IPv6..
If they want to use IPv6 for local communication between each other, sure again you have no control over what devices do on the L2 network amongst themselves.
But between vlans, or to the internet via pfsense - nope not using IPv6 unless you allow it.
But if your using a switch with the right feature set, sure you can block IPv6 between L2 devices.
What is the ultimate goal here - block unwanted ipv6.. That is very simple to do, just do not allow it between vlans all together. What is more difficult is blocking or allowing the source IP of the traffic to dest.. Since sure the client could use a temp address as its source. That would have to be disabled on the client.
This is why it has always been practice to block/allow via prefix be your ipv6 prefix or your ipv4 network..
The prefix used on any specific network on pfsense even via tracking and delegation that changes will still be known as the Vlan net, you can use that in your rules.. So even if the prefix changes on the interface, the "net" alias will be the assigned prefix to that interface. So if I want to block ipv6 traffic between lan and vlan, can just use those as the source and dest IPs
Here's the thing, if you are not at a place where you feel you can control IPv6 traffic how you desire, then turn it OFF.. There is zero requirement for IPv6 be it locally or globally. At that time.. If you can not control it like you want, then sure just turn it off. Your still going to be able to get to any website/service you desire.. Name one actual mainstream service that is not still reachable via IPv4.. When you can not get to facebook or google via IPv4 - then sure IPv6 will be required - but until you can name a specific service that requires you to have IPv6, if you can not control it how you want - then just turn it off.
There are millions of users, if not billions that do not even have IPv6 today.. So clearly its not a "requirement" that you have it.. Or use it - unless you want to.
-
Yes, sorry, I was not very precise regarding the "not to use IPv6 for internal communication for now". I meant more I'm not using it explicitly like e.g. having DNS entries for my local servers (NAS etc.), having firewall rules that allow specific IPv6 traffic (e.g. from or to specific hosts between VLANs) etc..
Generally, I want to push IPv6 as far as possible, but without any compromise or "ugly" setups. IPv6 addresses are running out and in my opinion everyone should do their part moving to IPv6 (and I'm also very interested in it ;) ). And IPv6 definitely has its advantages, e.g. like getting rid of NAT. (Using NPt is fine from my perspective, because it's 1:1 without any state, and it's very helpful e.g. for Multi-WAN setups.)
My setup looks like this:
- I have two ISPs that support full DualStack with dynamic /56 prefixes via DHCPv6. But because of https://redmine.pfsense.org/issues/6880 I have disabled IPv6 completely for "WAN2" (actually OPT1 ;) ). (As soon as this issue is solved, I maybe use WAN1 for some VLANs and WAN2 for others. Currently for IPv4 I have a setup where some VLANs use WAN1 with fallback to WAN2 and for some others the other way around.)
- For most VLANs I have IPv6 enabled using "track interface", but for some I have disabled it.
- I use "Stateless DHCP", so SLAAC for address configuration. (DHCP e.g. to distribute the name server, but my DNS doesn't include any local DNS entries apart from the one of pfSense that pfSense adds automatically.)
- I block basically all IPv6 communication between VLANs using a block rule with "xxx net". I need this, because I want to allow Internet traffic where I need an "allow to any". I haven't found any other way to block IPv6 traffic between my VLANs, but allow it for Internet. For IPv4 it's easily done with one "block 192.168.0.0/16" rule, but as discussed above this doesn't work when I get my prefix dynamically via DHCP without a variable or an automatically generated alias that contains the whole prefix or whatever. The downside with the "xxx net" approach is that for n VLANs you need n*n rules (so in my setup 5*5=25) instead of just n, or even 0, because with an alias I could already exclude local traffic from the "allow to any" rule.
- I "don't care" (at least in the context of this discussion) what happens within my VLANs, because when IPv6 is used there somewhere "automatically", it's just an implementation detail. If I want to control the traffic within a VLAN, I have to go down to layer 2. What does it help when I block IPv6 there and the devices use another never-heard-of protocol on top of layer 2. My switches (Cisco SG300) have some layer 2 filtering capabilities I think, but I haven't used it so far.
Well, I think that's it basically. I will move on further as soon as more pfSense features support dynamic prefixes. For example when 6880 is solved and NPt support dynamic prefixes, I will try to extend my Multi-WAN setup to IPv6. As I will then also have ULAs, I will probably then also set up IPv6 DNS entries for my NAS etc. Haven't thought about how to allow only individual hosts to some destinations then (regarding the temporary address problem), but I think I still have some time to think about that before I get to that point. ;) But probably that's not even an issue, because I think all use cases where I need this is some kind of server-to-server communication (e.g. mail server to NAS for backups) that don't need temporary addresses anyway.
