IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA)

JKnott

@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):

Is there a way to reference a host for firewall rules etc. if that host uses SLAAC exclusively and your prefix is dynamic?
It won't give me a DUID, the prefix keeps changing, but at least the suffix is consistent with SLAAC I think? How you go about targeting such a host?

I was going to suggest ensuring don't release prefix, on the WAN page, is selected, but it appears to be gone from 2.7.0. Hopefully, that's the default now. If not, I'm going back to 2.6.0.

If your prefix is changing, you can use ULA to access devices on your LAN.

Bob.Dig

@JKnott said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):

I was going to suggest ensuring don't release prefix, on the WAN page, is selected, but it appears to be gone from 2.7.0.

It is most probably here:

stefj

@JKnott said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):

I was going to suggest ensuring don't release prefix, on the WAN page, is selected, but it appears to be gone from 2.7.0. Hopefully, that's the default now. If not, I'm going back to 2.6.0.

If your prefix is changing, you can use ULA to access devices on your LAN.

I already have ULAs for my subnets on top of the GUAs using VIP and RA subnets. But if I make a firewall rule targeting a ULA, it won't apply to any GUAs the host might be using.
Or is there some way to make the rule apply to every ipv6 address a host might be using just by referencing its ULA?

As for my other 2 questions, I take it then that I wasn't missing any critical info, it is what it is.

Oh, as for the don't release prefix bit, I believe its been moved to Advanced>Networking>IPv6 options. Which seems like a strange choice for multiwan scenarios. Previously you could have a static PD on one interface by not releasing and a dynamic one on another. Theoretically at least, I haven't tried it, but was considering the option. Now it's a global choice apparently. Seems weird, unless the previous implementation was broken anyway.

EDIT: I see you found the option too. Yea, was already aware of it, however the ISP needs to respect it too and mine doesn't.

Bob.Dig

@stefj I am with you but also you could ask yourself:

Why do you need to know that, there is the built-in "alias" for that
You can use ::suffix in your rules on that interface only but better use DHCPv6
You can have that simultaneously, select "assisted" in RA and provide the ULA in the Subnets field.

stefj

@Bob-Dig said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):

@stefj I am with you but also you could ask yourself:

Why do you need to know that, there is the built-in "alias" for that

You can use ::suffix in your rules on that interface only but better use DHCPv6

You can have that simultaneously, select "assisted" in RA and provide the ULA in the Subnets field.

That's what I ended up doing, but it's far from ideal. For once it's a waste of resources and time making extra aliases and referencing them everywhere, both for the user and the firewall. Secondly, and most importantly you are still advertising your interface's mac address for no good reason. Since you can do it when assigning static IPv6, you should be able to do it when tracking too. You got the whole prefix in your disposal after all.
This seems like a good suggestion, assuming it works on different interfaces too, to forward incoming traffic for the host from WAN for example. Gonna try it out and see how it pans out.
This is what I was doing, but in assisted mode, SLAAC hosts get to make their own GUAs automagically even if you only have the ULA subnet listed in RA. And in managed mode they get nothing, just link local. I think I tried every combination I could think of. If there's a way to give GUA only through dhcp6 and still support SLAAC with ULA, please let me know.

stefj

@stefj said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):

@Bob-Dig said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):

You can use ::suffix in your rules on that interface only but better use DHCPv6

This seems like a good suggestion, assuming it works on different interfaces too, to forward incoming traffic for the host from WAN for example. Gonna try it out and see how it pans out.

Ok, now I remembered what the problem was. It doesn't work for the dns resolver or aliases, making it a pain to do most common tasks.
It's better than nothing, but I'm not sure I'd call it viable longterm.

Bob.Dig

@stefj You missing my point,

for the firewall addresses itself there are already aliases, you don't have to create anything
don't assume, it is not working like this
Not as far as I know but why are you afraid, let them have it all. Or better create more virtual interfaces (vlans) and separate by interface and not by hosts. This is especially true with IPv6.

stefj

@Bob-Dig said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA):

@stefj You missing my point,

for the firewall addresses itself there are already aliases, you don't have to create anything

don't assume, it is not working like this

Not as far as I know but why are you afraid, let them have it all and use your rules wisely.

I'm not sure what you mean. My interfaces get addresses of the format [prefix][mac] and these are the addresses they advertise for services in their subnets. I don't want to advertise the interface's mac address to the clients.
Ok, that sounds even worse. So, how does it work? That's a no go too then?
Well that's the problem, innit. I can't make rules when I can't reference the hosts. It's either block all or allow all. It's all very reminiscent of the DoH fiasco. Rendering local security measures obsolete.

stefj

@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.

JKnott

@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.

JKnott

@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.

Bob.Dig

@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.

stefj

@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.

stefj

@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.

Bob.Dig

@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.

stefj

@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.

JKnott

@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.

JKnott

@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.

stefj

@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.

keyser

@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?