IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA)
-
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
- Ok, that sounds even worse. So, how does it work? That's a no go too then?
Right, I just tried it out and I see what you meant. Now I'm entering comedy night zone.
Say I got a slaac host with the address [dynamic prefix]:[id]:[slaac static suffix] [56]:[8]:[64] bits respectively
I know the last 72 bits. But there's no way to reference them in a rule for a different interface, right?
If I make the rule for single host or alias, I can't supply a bitmask. And I can't make an alias for a suffix either.
And if I try and make the rule for network, only 32bit masks are supported for ipv4.So yea, back to the original problem. There really is no way to make an incoming traffic rule for a SLAAC host even if you were to know the last 127bits of its address, correct?
I'm not sure whether to classify this as a bug or feature request or what. It's essential functionality. As in the software doesn't serve much purpose without it.
Considering there is no regulation enforcing ISPs to provide static prefixes and considering that android refuses to use dhcp6, what even is the point of firewall rules with ipv6?
And it's not only android either. I got freebsd jails that only work with slaac.Until these concerns are addressed the only viable recommendation seems to be turn off ipv6 completely.
-
@Bob-Dig said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
It is most probably here:
Spoiler
Good. I can stick with 2.7.0.
-
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
As for my other 2 questions, I take it then that I wasn't missing any critical info, it is what it is.
If you absolutely must choose your own address, you could change the MAC, if allowed.
I have never used DHCPv6 on the LAN, as Android won't work with it. So, I can't provide any advice on that. I do have both GUA and ULA and they both work fine with SLAAC.
-
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
So yea, back to the original problem. There really is no way to make an incoming traffic rule for a SLAAC host even if you were to know the last 127bits of its address, correct?
That is why I advised to use DHCPv6 for those hosts.
-
@JKnott said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
As for my other 2 questions, I take it then that I wasn't missing any critical info, it is what it is.
If you absolutely must choose your own address, you could change the MAC, if allowed.
I would consider spoofing my own MAC to my own firewall, absurd as it sounds, if that was the only issue.
But evidently, there's far bigger issues currently, so I'm thinking it would be wiser to just pull the kill switch on ipv6 entirely for now and wait for further development.
-
@Bob-Dig said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
So yea, back to the original problem. There really is no way to make an incoming traffic rule for a SLAAC host even if you were to know the last 127bits of its address, correct?
That is why I advised to use DHCPv6 for those hosts.
And that's why my original question was specifically for hosts that refuse to use DHCPv6 (and who are far from the minority mind you).
It's alright, appreciate the insights. My concern was mainly if there's some hidden functionality that I wasn't aware of.
Because this situation seemed absurd for network security. Maybe I was just missing something. I refused to believe this is the situation we're in with ipv6 in 2023.Both yours and @JKnott replies confirmed that this is, sadly, the actual situation, take it or leave it.
My network clients won't be happy, but I'm gonna have to leave it if I can't secure it.
-
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
I refused to believe this is the situation we're in with ipv6 in 2023.
Yep. Maybe this will change in the future but I have my doubts.
-
@Bob-Dig said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
I refused to believe this is the situation we're in with ipv6 in 2023.
Yep. Maybe this will change in the future but I have my doubts.
Maybe it's just me, but I find this very funny. -2 osi layers for +2 ip levels. Gotta keep the scale balanced.
Not sure how this kind of policing would be better than reverse bit masking which would solve the SLAAC issues I was describing earlier, but I'm guessing there's even bigger issues the developers are trying to tackle that I'm not aware of.
-
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
But evidently, there's far bigger issues currently, so I'm thinking it would be wiser to just pull the kill switch on ipv6 entirely for now and wait for further development.
I'm not sure I understand your problem. Why do you have to use your own IP address? If it's for the firewall, just use the consistent SLAAC address. You can use cut 'n paste to do that.
I've been using IPv6 for over 13 years and have never needed to remember an address. I just put it in my DNS.
-
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
It's alright, appreciate the insights. My concern was mainly if there's some hidden functionality that I wasn't aware of.
Because this situation seemed absurd for network security. Maybe I was just missing something. I refused to believe this is the situation we're in with ipv6 in 2023.Both yours and @JKnott replies confirmed that this is, sadly, the actual situation, take it or leave it.
My network clients won't be happy, but I'm gonna have to leave it if I can't secure it.
I find many people have issues with IPv6, because they're stuck in the IPv4 mind set. Why won't those clients use DHCPv6? Other than Android devices, I can't think of any reason for not using it.
-
@JKnott said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
It's alright, appreciate the insights. My concern was mainly if there's some hidden functionality that I wasn't aware of.
Because this situation seemed absurd for network security. Maybe I was just missing something. I refused to believe this is the situation we're in with ipv6 in 2023.Both yours and @JKnott replies confirmed that this is, sadly, the actual situation, take it or leave it.
My network clients won't be happy, but I'm gonna have to leave it if I can't secure it.
I find many people have issues with IPv6, because they're stuck in the IPv4 mind set. Why won't those clients use DHCPv6? Other than Android devices, I can't think of any reason for not using it.
Why won't they use it. Various reasons. In android's case I guess it's to evade local moderation for ads, tracking and anything else nefarious you wanna imagine. In freebsd's case probably lack of development resources. In iot cases there can be even legitimate concerns of wanting to avoid the overhead of a dhcp client in the stack.
Whatever the reason might be, malicious or legitimate, it wouldn't be that bad if ISPs were required to provide static prefixes. But that won't happen anytime soon and maybe it's for the best. Not sure I'd want an ip I can't get rid of.
So the actual, actionable problem is that pfsense and the likes haven't caught up yet and they don't offer the required mechanisms to moderate ipv6 traffic adequately. I'm hoping that will change sooner rather than later, because I don't see any of the other 2 contributing factors backing off. Neither dhcp6, nor static prefixes are getting mandatory ever.As for why do I have to use my own IP address, I could list a dozen reasons. Doesn't matter why. Maybe for security, maybe for convenience, maybe just because. This bit is absolutely unacceptable for pfsense. Heck, openwrt does it on a shoestring budget. Pfsense itself does it when not tracking. Why won't they give an option while tracking is beyond me. But as I said, it's the least of the issues here and could be circumvented by spoofing if need be, so whatever. I'd much rather they fixed SLAAC host targeting first.
And please, don't lecture me about being stuck in an ipv4 mind set. I'm stuck in a security mindset which is rather appropriate for a firewall forum I would think. None of the very real problems I presented have anything to do with ipv4 habits. I don't wanna NAT the hosts, I just want to be able to make firewall rules that work.
After much deliberation I've decided to not kill ipv6 on the network completely. Just switched to managed RA only, traffic allowed out exclusively for GUAs registered in dhcp6 for now, and got rid of the ULAs as they serve no actual purpose if you got ipv4 for internal addressing. Not like I'm running out of private ipv4 subnets anytime soon to require ULAs for internal use. And that's how it's gonna stay in my network until pfsense or whoever else gives me a way to deal with SLAAC properly.
If you've decided to allow SLAAC host traffic in your network, I offer you my sympathies and wish you best of luck.
-
@stefj You are touching a VERY important problem here that also caused me to back off IPv6 for most of my networking needs. But to be honest I think the problem is deeper rooted than just pFsense missing a “simple” way to create ruleset for clients if they are not DHCPv6 clients, and if you are not using static IPv6 prefixes.
You are addressing a major issue with IPv6 itself as it is too fragmented and “not standardized” properly.
Some clients do not do DHCPv6, Some do not follow SLAAC properly, some uses SLAAC with the original proposal of using the MAC address in the suffix, but some of those then use privacy MAC addresses (virtual random MAC addresses). Some uses Privacy random SLAAC addresses, som uses multiple ephemeral random privacy SLAAC addresses for outbound Internet sessions, and the list goes on.
IPv6 does not offer controls to actually centrally force clients on any given network to behave EXACTLY as you want them to (fx. Use only ONE address type and register it in DNS - otherwise Firewall access is denied).This all combines to make it completely impossible to regulate internal clients on a Firewall unless there is an actual Firewall Agent running on the Client (To identify the client to firewall by other means than an IP address).
BTW: What controls do OpenWRT offer to allow you to create better IPv6 rules?
Love the no fuss of using the official appliances :-)
-
@keyser said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
You are addressing a major issue with IPv6 itself as it is too fragmented and “not standardized” properly.
Some clients do not do DHCPv6, Some do not follow SLAAC properly, some uses SLAAC with the original proposal of using the MAC address in the suffix, but some of those then use privacy MAC addresses (virtual random MAC addresses). Some uses Privacy random SLAAC addresses, som uses multiple ephemeral random privacy SLAAC addresses for outbound Internet sessions, and the list goes on.
IPv6 does not offer controls to actually centrally force clients on any given network to behave EXACTLY as you want them to (fx. Use only ONE address type and register it in DNS - otherwise Firewall access is denied).This all combines to make it completely impossible to regulate internal clients on a Firewall unless there is an actual Firewall Agent running on the Client (To identify the client to firewall by other means than an IP address).
BTW: What controls do OpenWRT offer to allow you to create better IPv6 rules?
And I think that's the goal to be perfectly honest. Probably not the goal of the team designing ipv6 back when, but I'm pretty sure it's the goal for most -if not all- major players at the moment. Confuse, obfuscate, invalidate downstream moderation.
Dunno what netgate is doing, but they sure take their sweet time coming up with viable solutions for ipv6 problems. Maybe there's a conflict of interest, maybe it's indeed that hard to sort it out. Then again, that simple thing I was talking about earlier is such a red flag. It's a feature that's offered for static addresses which are typically available only in corporate installations for many parts of the world and it's withheld for no good reason for pppoe end users. It's hard to swallow as an oversight. Seems indicative of policy. Hope I'm wrong.
As for openwrt, I was talking about this thing specifically, allowing you to pick interface ip from the pd when tracking. Which they of course offer. Because why wouldn't they. Seriously, what's wrong with you netgate, why can't I set an ip for my interface? Bah.
-
@keyser said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
BTW: What controls do OpenWRT offer to allow you to create better IPv6 rules?
Some (all?) Linux based firewalls support filtering on MAC addresses.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@JKnott There is experimental support for that in 23.05 as well now - Havent tried it yet though.
-
@JKnott said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
@keyser said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
BTW: What controls do OpenWRT offer to allow you to create better IPv6 rules?
Some (all?) Linux based firewalls support filtering on MAC addresses.
And the good thing with mac filtering -at least for now- is that there's no excuse for clients. I'm not aware of any os that spoofs mac addresses without offering an option not to. Even android -again, for now- allows you to turn off fake macs.
Then again it's such a weak security measure against most actual threats for a firewall. There's a reason L2 is for routing behind the firewall. Many good reasons in fact.
-
@keyser said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):
@JKnott There is experimental support for that in 23.05 as well now - Havent tried it yet though.
This is an old thread, but wanted to say thanks for the reminder. I was trying to timed-block Internet on my son's Chromebook, but have no control over the school-managed OS, and being Android it doesn't use DHCPv6. Scheduled rule to pass, rule to block, both based on MAC.
