OPNsense Forum

Archive => 21.7 Legacy Series => Topic started by: bimbar on August 10, 2021, 11:05:17 am

Title: Regarding IPv6 support
Post by: bimbar on August 10, 2021, 11:05:17 am
I just transitioned over to a DS-lite internet with 4in6 tunnel and dynamic prefix allocation.

What works well is the DHCPv6-PD and tracking interfaces.

Everything else is a bit lacking.

- I saw a change discussion regarding dynamic aliases for ipv6 firewall rules, so that seems mostly fine. What I would suggest to add beyond that is that predefined aliases like "LAN network" should be usable in network groups.
- IPv6 virtual secondary IP addresses are urgently needed for configuring ULA addresses for internal communication while using dynamic prefixes for external communication which IMO is the only good way to do that.
- 4in6 tunnel support so AFTR routers for DS-lite can be used

That said most of those are not as big of a deal if using static IPv6 prefixes. But in case providers are changed and a renumbering is necessary, ULA for internal use are still a good idea.
Title: Regarding IPv6 support
Post by: Greelan on August 10, 2021, 12:03:48 pm
ULA is already possible

Interfaces -> Virtual IPs -> Settings

Create an IP Alias on the relevant interface with a /64 address
Title: Re: Regarding IPv6 support
Post by: IsaacFL on August 10, 2021, 02:50:16 pm

- I saw a change discussion regarding dynamic aliases for ipv6 firewall rules, so that seems mostly fine. What I would suggest to add beyond that is that predefined aliases like "LAN network" should be usable in network groups.


You can do this by creating a group (Firewall - Group) with all of the local interfaces as members.  Then you have an Alias of "GROUP Network".

This is what I do, and then I don't need to use ULA's.  ULA's won't be used by any host anyway, as they are the lowest in priority.

For individual hosts, use a dynamic dns (I use CloudFlare as my DNS register), and have the hosts update themselves using a script locally.

Title: Re: Regarding IPv6 support
Post by: bimbar on August 10, 2021, 08:12:47 pm
ULA is already possible

Interfaces -> Virtual IPs -> Settings

Create an IP Alias on the relevant interface with a /64 address

I can only enter netmasks up to /32, so it seems no ipv6 addresses are allowed.
Title: Re: Regarding IPv6 support
Post by: bimbar on August 10, 2021, 08:19:37 pm

- I saw a change discussion regarding dynamic aliases for ipv6 firewall rules, so that seems mostly fine. What I would suggest to add beyond that is that predefined aliases like "LAN network" should be usable in network groups.


You can do this by creating a group (Firewall - Group) with all of the local interfaces as members.  Then you have an Alias of "GROUP Network".

This is what I do, and then I don't need to use ULA's.  ULA's won't be used by any host anyway, as they are the lowest in priority.

For individual hosts, use a dynamic dns (I use CloudFlare as my DNS register), and have the hosts update themselves using a script locally.

Ok, I see what you mean. That can be done, but I don't think it's an especially clean way to do it.

I would use ULA for internal communication, so I can address servers with a static address, even when the public prefix is changed, and that's not possibly right now.

I agree that dyndns is another way to do it, but then I can't do any meaningful firewalling with these hosts.

The best way at the moment, as I see it, is to use IPv4 internally and IPv6 only to access the internet.
But even that is difficult, since I can not easily designate the internet in a firewall rule. I can not filter on in and out interface both.

I have found a way but it doesn't integrate into the rest of the ruleset, for that I would need the interface networks as alias or some other way to define a dynamic ipv6 alias.

In short, it's not really ready for production, if you get dynamic prefixes, but then so are most other firewalls I've seen.
Title: Re: Regarding IPv6 support
Post by: Greelan on August 10, 2021, 11:02:08 pm
ULA is already possible

Interfaces -> Virtual IPs -> Settings

Create an IP Alias on the relevant interface with a /64 address

I can only enter netmasks up to /32, so it seems no ipv6 addresses are allowed.
Enter a valid IPv6 address in the box and then click out of it. OPNsense will automatically detect that it is IPv6 and allow a /64 netmask (will either pop up automatically or you can select it in the dropdown).
Title: Re: Regarding IPv6 support
Post by: bimbar on August 11, 2021, 01:46:27 am
ULA is already possible

Interfaces -> Virtual IPs -> Settings

Create an IP Alias on the relevant interface with a /64 address

I can only enter netmasks up to /32, so it seems no ipv6 addresses are allowed.
Enter a valid IPv6 address in the box and then click out of it. OPNsense will automatically detect that it is IPv6 and allow a /64 netmask (will either pop up automatically or you can select it in the dropdown).

Interesting.

From preliminary testing, it seems that virtual IPv6 have the potential to bug radvd out so that it only advertises the ULA and forgets about the public address.
Title: Re: Regarding IPv6 support
Post by: Greelan on August 11, 2021, 02:06:12 am
Sometimes dhcp6c (if you are using that to get GUAs) can act up, particularly after a network change. Try reloading the WAN interface under Interfaces -> Overview.

Believe me, though, I have been using ULAs on all my LAN/VLANs on OPNsense for 10 months (ever since I set it up) and they work absolutely fine.
Title: Re: Regarding IPv6 support
Post by: bimbar on August 11, 2021, 10:32:07 am
It doesn't seem ready for production to me.

If I enable v6 on an interface, it automatically configures radvd AND dhcpdv6 for that interface, which it should not.
Enabling custom dhcpdv6 config, I can disable dhcpdc6 by enabling and then disabling it again.
I am quite unable to get it to push v6 nameserver configuration to the clients (radvd + dhcpdv6 for dns).
Sometimes dhcpdv6 picks up the ULA address and sometimes the public address, and I can not determine why it detects which one, it seems random to me.

I hope this gets better once more people use IPv6, but for now it doesn't seem widespread enough to be tested as much as it should be.
Title: Re: Regarding IPv6 support
Post by: franco on August 11, 2021, 10:47:22 am
If you hammer the reconfiguration the upstream server will likely ignore you leaving you without a GUA as Greelan suggested.

I know there are particular issues with the code but making it sound like radvd and dhcp6c do what they want seems a rather uneducated guess from my point of view.


Cheers,
Franco
Title: Re: Regarding IPv6 support
Post by: Greelan on August 11, 2021, 11:43:31 am
Also there is some confusing of dhcp6c (which is the client that gets the WAN GUA and PD) and dhcpd6 (which is the server handing out GUAs for LAN clients). If DHCPv6 is not wanted internally, just enable manual RA/DHCPv6 config on the internal interfaces and then configure as desired. In my case I use SLAAC only
Title: Re: Regarding IPv6 support
Post by: bimbar on August 11, 2021, 12:22:46 pm
I'm beginning to see how it works, after I found the stealthily popping up "Router Advertisements" menu option, but I have to say, with the dynamically opening interface choices, it's properly cryptic. In fact I only found out by reading bug reports.
Me using BIND doesn't help either.
For the moment I'm using unmanaged and that seems to work reasonably well.

Still it's difficult to properly firewall dynamic IPv6 networks, can't wait for the dynamic alias support.
Title: Re: Regarding IPv6 support
Post by: bimbar on August 11, 2021, 01:12:21 pm
A question: How would I configure my LAN interfaces if I have a cluster of two opnsense firewalls both getting (different) prefixes via dhcpv6-pd?

I seem to have the problem that some clients don't propery associate address and gateway, so they use the address from fw1 and the gateway from fw2 which doesn't seem to work? But possibly I'm on the wrong track there.
Title: Re: Regarding IPv6 support
Post by: bimmerdriver on August 11, 2021, 04:14:44 pm
I've been using IPv6 since I started using OPnsense and I think it works very well. Yes, some of the settings aren't obvious and yes, probably some improvements can be made, but to suggest that it's "not ready for production" isn't reasonable.