Messages

Hi all,

I'm trying to get a simple Dual WAN / Dual LAN setup running:
Two WAN interfaces (DHCPv6), two LAN interfaces (LAN1 tracks WAN1, LAN2 tracks WAN2). The WAN1 gateway (WAN1_DHCP6) is the default one. To get traffic originating from LAN2 being routed via WAN2, the gateway is set to WAN2_DHCP6 in the allow-all firewall rule for LAN2 (Policy Based Routing).

No success. LAN1 works just fine, but there is no Internet access from LAN2. This is not a DNS issue (DNS servers are set to external public servers in Router Advertisements). A traceroute from a host in LAN2 to a public IPv6 address doesn't get further than the first hop (router). As expected, switching the default gateway to WAN2_DHCP6 gets LAN2 working and breaks LAN1 Internet connectivity.

Ideas? This should be pretty straight forward, but maybe I am missing something.

Cheers

Maurice

Are you sure we are talking about the same thing? franco mentioned "Register DHCP leases in the DNS Resolver" which is an unbound setting. If this is set, A and PTR records are created when clients request a DHCPv4 lease. This does not work for DHCPv6 leases in my setup.

(Not to be confused with "Enable registration of DHCP client names in DNS" which is a DHCP setting.)

You can also enable "Register DHCP leases in the DNS Resolver", but that would require said static DHCPv6 server which you can't use with the tracking setup yet.

I couldn't get that to work even with a static prefix. My guess would be that currently only DHCPv4 leases are being processed by this feature.

I don't know. It's part of the problem of IPv6 without NAT.

It's a problem of dynamic IPv6 prefixes. Those are harmful for anything but the most basic home networks. ISPs know that and (ab)use them for justifying the higher prices of business plans (with static prefixes).

Maybe someone else has solved this?

Some (closed source) firewalls solved this by allowing the use of interface identifiers instead of full IPv6 addresses when creating firewall rules, static DNS records, DHCPv6 reservations and so on. The dynamic prefix will then be added automatically. Pretty much like JasMan suggested in the last post. But it seems OPNsense does not support that yet.

That means in conclusion OPNsense is not usable as firewall and/or internal DNS server on connections with dynamic prefixes at the moment.

I'm afraid I have to agree. Static prefix or other firewall it is.

The workaround would be to use NATv6.

You really don't want to go there.

DHCPv6 does not work like DHCPv4. DHCPv6 address assignments do not contain prefix or router information. That's why they are considered /128. Clients learn prefixes and routers from Router Advertisements only. If an on-link prefix from RAs matches an address from DHCPv6, local traffic won't go through the router.

Well, wherever it fits your needs. ;)

If you want to allow getting pinged from the WAN: On the IPv6 WAN interface. Or you could create a floating rule and allow it from anywhere to anywhere (useful if you have multiple LANs and want to allow pinging between them).

The only issue now according to the IPv6 test site is that my firewall is filtering ICMPv6 messages. Any ideas on how to rectify this, if it can be, would be very welcome.

Just create a firewall rule allowing ICMPv6 Echo Request.

That assumes there's no LAN PCs/Servers that don't need DNS resolution, if it's required then a LAN DNS server is needed or have I missed something obvious?

That's correct. DNS resolution of local hostnames won't work.

How is the OPNsense itself going to lookup hostnames?

By querying the specified (Google) DNS servers directly.

As far as i know, searching for updates, aka. "check updates" will probably not work anymore or will OPNsense just use the DNS configured in the general page aswell, even without any forwarding feature enabled?

It will. That's what the setting "Do not use the DNS Forwarder/Resolver as a DNS server for the firewall" is for.

Never had this setup before so i am really curious.

This is a pretty common setup. Think of corporate networks with existing DNS infrastructure. You typically don't want a firewall involved in DNS resolution / forwarding in such scenarios.

If DNSmasq AND Unbound are disabled, who is going to do the forwarding to the Google DNS? ;)

There won't be any forwarding because it's not required. If dnsmasq and unbound are disabled, the DHCP server assigns the DNS servers configured on the General page to the clients. So the clients query the Google DNS servers directly. In this scenario OPNsense is not involved in DNS at all.

Not sure whether OPNsense is right for you, but it seems you came to the same conclusion. ;)

But here you go:

I see that under System: Settings: General, under "DNS servers" there is a place where you can specify up to five DNS servers, but I'm not quite clear on how that's used.

Enter the Google DNS servers here.

There is a dropdown next to each DNS server field under "Use gateway" and the choices are "NONE" or "WAN_DHCP - wan - (wan IP address)" - which should I use?

Doesn't matter, you can leave the default. This is only relevant if you have a more complex network setup (multiple Internet connections, internal DNS servers etc.).

Then at the bottom there are two options, "Allow DNS server list to be overridden by DHCP/PPP on WAN" which is currently checked

Uncheck this. If checked, this will replace the Google DNS servers with your ISP's DNS servers. Which is what you don't want.

and "Do not use the DNS Forwarder/Resolver as a DNS server for the firewall" which is currently not checked

Check this. This makes OPNsense itself use Google DNS instead of its own DNS resolver (unbound).

And also, by default when I set this up, under Services: Unbound DNS: General, "Enable DNS Resolver" is checked

Uncheck this. This will disable unbound completely and Google's DNS servers will be assigned to your clients.
When it's disabled, all other unbound settings don't matter.

Ein IPv6-Präfix von der CB zu bekommen sollte kein Problem sein (wie von NicholasRush beschrieben). Die Schwierigkeit besteht im IPv4 via DS-Lite. Zusätzliches NAT in der OPNsense (wie bei mar_becker) geht natürlich immer(*), aber wenn man das nicht möchte muss die OPNsense den DS-Lite-Tunnel selbst aufbauen. Und das ist noch work in progress. Mit etwas Handarbeit geht es aber wohl schon. Siehe dazu auch dieser Thread: https://forum.opnsense.org/index.php?topic=7788.0

Alternativ wie gesagt transparentes Bridging, mit Einschränkungen der Funktionalität.


(*) Dazu sollte die OPNsense nicht das gleiche LAN-Subnet wie die CB vewenden, also z. B. 192.168.1.0/24 konfigurieren. Außerdem muss "Block private networks" auf dem WAN-Interface deaktiviert werden.

Du müsstest OPNsense als Transparent Filtering Bridge konfigurieren (ohne NAT, ohne Routing); unter diesem Begriff findet sich auch eine Anleitung in der Doku. Es funktionieren dann aber nicht alle Features.

Besser wäre es, den DS-Lite-Tunnel direkt auf der OPNsense einzurichten. Das funktioniert grundsätzlich auch auf einem Router hinter der Connectbox, z. B. mit OpenWrt. OPNsense unterstützt es leider noch nicht, ist aber wohl in Arbeit. Wird hier auch ausführlich im UM-Forum diskutiert: https://www.unitymediaforum.de/viewtopic.php?f=53&t=36774

Did they tell you what kind of system it was? I guess they were happy you didn't "investigate" further... ;)

Moin,

Das ist in diesem konkreten Fall wohl eher ein Bug in der dhcpd6-Konfiguration.

Auf mit "Track Interface" konfigurierten LAN-Interfaces ist der dhcpd6 immer aktiv. Das ist grundsätzlich sinnvoll, da manche Clients mit den RDNSS- und DNSSL-Optionen in RAs nichts anfangen können und für diese Infos auf DHCPv6 angewiesen sind. DHCPv6 und Router Advertisements lassen sich für Track-Interfaces allerdings nicht manuell konfigurieren (dazu gibt es ein Feature Request).

Der Bug ist nun, dass in der dhcpdv6.conf für Track-Interfaces immer die jeweilige Interface-Adresse als DNS-Server eingetragen wird, auch wenn unbound und dnsmasq deaktiviert sind. Über System / Settings / General konfigurierte IPv6-DNS-Server werden zwar in die dhcpdv6.conf übernommen, die Interface-Adresse bleibt bei Track-Interfaces aber immer zusätzlich stehen. Shades Clients lernen diese ungültige DNS-Adresse also höchstwahrscheinlich über DHCPv6, nicht über Router Advertisements.

Ist ein weiterer Bug bei der Konfiguration von DNS- und Domänen-Optionen für dhcpd6 und radvd. Habe das neulich mal genauer analysiert und hier aufgeschrieben, die Liste ist aber offensichtlich noch nicht vollständig.

Grüße

Maurice

18.1 works fine with Hyper-V Gen2. 17.7 indeed had some known issues with Gen2. Tested with Windows Server 2012 R2 and Windows 10.

Does it fail immediately when booting the ISO or after installation (when booting from the VHDX)?

Did you verify the checksum of the ISO? Is it stored on a local drive?

(Settings I use for 18.1: Secure Boot disabled, 1024 MB RAM, Dynamic Memory disabled, dynamic VHDX.)

Maurice, are you a customer of Deutsche Telekom?
If not, how come you were you able to reproduce?

Not a customer myself, but I have access to a Deutsche Telekom DSL line. You mentioned 217.5.98.15 (which is owned by DT) so I tested from the DT line. You're right that it wouldn't be possible to reproduce this from another ISP.