IPv6 ULA + track interface

[skywalker007]

Can someone advise me how to setup IPv6 properly for the following scenario:

4 VLANS
IPv6 assignment to all VLANS via track interface WAN -> works
IPv6 may change during DSL - reconnect (Deutsche Telekom).

piHole as a DNS server in VLAN-DMZ should be reachable as IPv6 DNS server. As my public IPv6 adresses may change, I cannot assign statically an adress from my public range to piHole. Distributing a dynamic adress for a DNS server sounds like a bad idea.
So my idea (open for others) is to assign ULA adresses in addition to the public ones. Then I can distribute the piHole ULA adress via DHCP6 to the clients and they can reach the DNS server.

So far the idea. I couldn't figure out how to set this up in OPNsense though. How can I assign ULA static addresses in addition to the dynamic ones?

thanks!

[Maurice]

ULAs can be added as Virtual IPs, but this doesn't survive a reboot because of a bug in OPNsense:

https://github.com/opnsense/core/issues/3310

If you need this feature, please make noise on GitHub. The bug currently doesn't seem to have a very high priority.

Cheers

Maurice

[skywalker007]

Thanks for the feedback Maurice,
How do other handle scenarios like this? It doesn’t seem so uncommon.
- Till

[BigSnicker]

Have the same issue with Rogers in Canada.

Relevant thread here: https://forum.opnsense.org/index.php?topic=11011.0
Relevant ticket here: https://github.com/opnsense/core/issues/2544

[avanix]

I would also appreciate very much if the IPV6 Tracking issue with virtual IPs would be solved in 20.1.

That bug makes it a mess using Opnsense with VLANs and IPv6 on any DSL line with changing IPV6 prefix:
https://github.com/opnsense/core/issues/3310

Is there a way to contribute to the solution of this issue?
To me it seems that there is some kind of sorting that determines the order of the IPv6 addresses and after a reboot the sorting brings the ULA/virtual IP on the first position -> tracking broken.
Shouldn't be so complicated to fix that sorting function.

[johnsmi]

How do other handle scenarios like this? It doesn’t seem so uncommon.

I'm using an OPT-Interface/vLAN.

Some boxes are on both networks: Prefix-vLAN and ULA-vLAN.

[henningkessler]

And unfortunately it looks like that a fix for this issue is further postponed to 20.7 ;-|

[franco]

All hands on deck welcome.


Cheers,
Franco

[Maurice]

I'm using an OPT-Interface/vLAN.

Some boxes are on both networks: Prefix-vLAN and ULA-vLAN.

Interesting. I once considered this but ultimately went for the (semi-working) Virtual IP solution.

The primary reasons were:

• Connecting a device to multiple VLANs only works via Ethernet (not Wi-Fi) and requires VLAN support in the device (or multiple Ethernet ports). So pretty much servers only. No embedded devices like printers etc.
• If the WAN goes down, the (WAN-tracking) GUA VLANs lose their prefix. So if the WAN goes down, you lose almost all local connectivity, too.

Were you able to work around this?

Cheers

Maurice

[johnsmi]

• Connecting a device to multiple VLANs only works via Ethernet (not Wi-Fi) and requires VLAN support in the device (or multiple Ethernet ports). So pretty much servers only. No embedded devices like printers etc.
• If the WAN goes down, the (WAN-tracking) GUA VLANs loose their prefix. So if the WAN goes down, you loose almost all local connectivity, too.

Were you able to work around this?

Depends on definition of Workaround. I'm working around dhcp not being able to assign multiple prefixes for GUA+ULA  at the same time.


Boxes which can access the internet can also access local devices, traffic is routed from GUA to ULA devices without problems. The other direction with a dynamically changing prefix requires properly resolving names.

The tricky part arises when you have to deal with "local network only" discovery like DLNA and can't/don't want to put the device on the same network (one with internet access and one w/o) and you can't configure multiple nets. If a not-so-smart device can't be configured, then it's broken. That's not the firewalls fault. It's the main reason fo me to use a local only VLAN for those devices.
The advantage of separated networks/vlans becomes a disadvantage here. The more i'd try to interfere here, the more things get messed up.

Whatever uses a client-server structure runs fine.

• Everything which is locally a "server" gets predictable and static ULA. When possible GUA, else just IPv4 for WAN access.
  
• Clients with internet access get GUA plus ULA when possible.

This mostly covers my use cases.

• Everything which runs local only with ULA is fine. Either routed between local networks or no routing required, because the switch takes care of the traffic.
• If WAN goes down, then outbound connections are interrupted anyway.
• so we are talking about GUA <-> ULA connections routed through the firewall.

=> I'm not aware of this might be causing any trouble in my use case.

• If in doubt i could use IPv4 for this. NAT makes IPv4 static on the LAN side, traffic is routed between local networks, there is no NAT on LAN side itself.

This makes sure that those connections which shall persist don't need to use the dynamically assigned prefix/GUA at neither end.

I'm not concerned about interrupted connections at all.




None of my clients has routes configured. Devices which can be configured are attached to the same network(s), thus don't require routes for outbound. Inbound is ULA/IPv4 when possible/necessary.

My WiFi/Router on WAN-side assigns both: dyn prefix GUA and ULA at the same time. There i got one route for the fd00::-networks and one for IPv4 to LAN.



Probably i just mess things up at other places. Usually one would want clearly separated networks in a tree-like structure, properly routed, not interconnected at all. However, this works for me.

[Maurice]

Thank you for the explanation. I'm still not sure I fully understand your solution for the "WAN down -> LAN down" issue, so let me give you an example:

• You have a file server connected to both the GUA VLAN as well as the ULA VLAN.
• You have laptops connected to the GUA VLAN only. They need a GUA for Internet access and can't be on both VLANs (because Wi-Fi).
• Now the WAN goes down, so the laptops lose their GUAs and are stuck with link-local only.
• How are the laptops supposed to reach the file server now? That's my main concern with this solution: I don't want local connectivity to depend on the WAN being up.

You don't have that issue if you advertise both prefixes in the same VLAN. Btw, there is now an (unmerged) patch for the "Virtual IP breaks tracking" issue ready for testing on GitHub (thanks to marjohn56)!

Cheers

Maurice

[johnsmi]

The Thread was about piHole.
I assume the OS running piHole supports VLAN, and one more VLAN wit static IPv6 should be easy to set up. DNS-requests don't require connections persisting for hours.

'm still not sure I fully understand your solution for the "WAN down -> LAN down" issue,

I got your point.

Its not an issue for me, thus perhaps no "solution" necessary for me. I get ULA + dynGUA on my WiFi-Router.


First, would IPv4 hurt for local connections which are supposed to run long term?
e.g. TV on WiFi streams from nas local via IPv4. DNS with GUA to piHole, which has ULA. Internet with GUA or IPv4NAT.


Second, "how down" is WAN? A short interrupt and a new prefix? Or really offline?

Is LAN really down?
I'm not absolutely sure about the networking stuff here, but in general the interface is still up, routes are still there while WAN is not responding.
A new prefix deprecates the IPs and i guess the routes for the old prefix are deleted? Is there the problem? A route for a deprecated IP/net would keep the connection up for some time.

[Maurice]

Ok, it seems the main difference between our setups is that you use Dual Stack in the LANs while mine are mostly IPv6-only. So if the router doesn't advertise an IPv6 prefix, the network is down for good. No fallback to IPv4.
(There is also NAT64 involved and a separate IPv4-only VLAN for legacy devices.)

Not every solution works for everyone. Let's leave it at that. :-)

Cheers

Maurice