Messages

I don't think that's completely accurate about it showing your ISP name, although I may be wrong.

I quoted crt333 who didn't enable forwarding in unbound and didn't configure anything to make unbound use a VPN. My comment was meant to be specifically for this situation. crt333 stated that dnsleaktest.com showed the IP address(es) of the ISP's name servers. That's not supposed to happen and would mean something very fishy is going on. It should show the WAN IP address of OPNsense.

However, unbound doesn't seem to want to forward requests through the VPN. Whenever I tried setting unbound to use the VPN tunnel it failed.

Unbound (with forwarding enabled) not using the gateways specified in System / Settings / General indeed seems to be a bug. I would try disabling forwarding and using the Outgoing Network Interfaces option in the unbound settings. If this doesn't work for VPN connections then you could still try the second option (enable forwarding in unbound and create a static route to the external DNS server).

Whenever I enable unbound and then run dnsleaktest.com it shows my underlying ISP nameservers

Did you double check? When running unbound as a resolver, dnsleaktest.com should show your own public IP address. Of course it shows your ISP's name, because this is where you get your IP address from. (If you don't have a public IP address (CGNAT), then it will show an IP address of your ISP's NAT gateway.)

• If you don't need to resolve internal hostnames, just disable unbound and use external DNS servers. Since your clients query these servers directly, traffic will always go through the VPN tunnel(s).
• If you need to resolve internal hostnames and have one VPN tunnel, make unbound send all queries through the VPN tunnel. You can specify Outgoing Network Interfaces in Unbound DNS / General / Advanced, but I don't know if this works for VPN connections. If it doesn't, enable forwarding in unbound and create static routes to your specified external DNS servers, using your VPN gateway as next-hop.
• If you need to resolve internal hostnames and have multiple VPN tunnels and need unbound to send queries through a specific VPN tunnel depending on what LAN interface the request is coming from... you're out of luck. You would need multiple instances of unbound running. This won't work with OPNsense.

I checked the DHCP v4 log for the IP, and two old entries showed up:

Code Select Expand

Mar 28 20:19:34 dhclient[30019]: DHCPACK from 10.233.128.1
Mar 23 21:37:13 dhclient[29618]: DHCPACK from 10.233.128.1

Does that help any?

Yes. It shows that 10.233.128.1 is your ISPs DHCP server. This is where you get your public IP address from. Just disable the firewall rule like mentioned in my previous post. (Or, if you want to be more specific, you could create a rule allowing only incoming UDP packets to port 68 from this IP address.)

It's most likely your ISP's DHCP server. Those sometimes use private IP addresses, even if they hand out public addresses.
Have a look in Services / DHCPv4 / Log File. You might find lines like this:

Code Select Expand

dhclient[28340]: DHCPREQUEST on hn1 to 10.233.128.1 port 67

This would be OPNsense sending a request to the DHCP server. If so, you might want to disable the firewall rule by unchecking Block private networks in Interfaces / WAN.

Sorry for the delay.

You're right, a simple workaround (reading the dhcpd output) most likely won't work.
It seems that routes for delegated prefixes are currently created by parsing the DHCPv6 lease file and matching address assignments (IA_NA) to prefix delegations (IA_PD). I think this was implemented pre-OPNsense, probably as some kind of "quick fix to get it working somehow". This seems fundamentally broken to me since it relies on the requesting router also requesting an address. Also, it is considered best practice to use link-local addresses as next-hop on links between routers, not Global Unicast addresses.

Others solved this by patching the ISC DHCP server so it makes link-local addresses of requesting routers available to custom hooks:
https://github.com/mpalmer/isc-dhcp

See also this very interesting discussion:
http://bird.network.cz/pipermail/bird-users/2017-April/011152.html

Unfortunately porting this to OPNsense is beyond my capabilities, but I think it should be put on the roadmap. Having reliable Prefix Delegation is becoming more and more important.

What type of Internet connectivity do you have? DHCP / PPPoE / static / ...? Public IPv4 or CGNAT?

(This has nothing to do with your LAN. The packets are coming from a DHCP server on the WAN side (Internet). They are blocked by OPNsense because you should not have packets with private IP addresses coming in from the Internet.)

My guess would be: Your WAN interface is configured as DHCP client and your ISP uses private IP addresses (CGNAT). So the "device wanting an IP" is actually your OPNsense router.

Don't know exactly what the error message is supposed to mean, but some things to consider:

• The wildcard needs to be entered as an Alt Name, the Common Name should to be set to the parent domain.
  Common Name: example.com, Alt Names: *.example.com
• Wildcard only allows challenge type DNS-01 for validation, not HTTP-01.

I was able to issue two production wildcard certs with OPNsense 18.1.5 / os-acme-client 1.13 (acme.sh 2.7.6_2) using the OVH DNS API.

I'm issuing wildcard certs with plugin v1.13 without any problems.

I can confirm this, works fine!

Correct, primary, which is the delegating router (router A in my example). That's where I manually created the route (which should be created automatically).

No issue on the requesting router (router B in my example).

Thanks, great work!

Here is what I just tried on the delegating router (via Web GUI):

• Add a new gateway: Interface LAN, Address Family IPv6, Name Test_PD, Gateway fe80::215:5dff:fe12:3456%hn0 (the requesting router's link-local WAN address)
• Add a new route: Network Address 2001:db8:feed:bf00::/56, Gateway Test_PD
• The route now properly shows up in the routing table. I have yet to test whether it actually works. It works! A test client connected to the requesting router's LAN interface has IPv6 Internet access.

It is important to specify the correct zone identifier (%hn0 for the first LAN) when creating the gateway. Without it the created route won't show up in the routing table.

So manually adding a route using a link-local address as gateway works. Now this "only" needs to be done automatically using the routine you created. I'm not exactly sure how the steps in the Web GUI translate into using FreeBSD's manual route command, but maybe it helps?

By default the console is password protected, too. This can be disabled via the Web GUI in System / Settings / Administration. Of course you would have to do this before locking yourself out. ;)

But the documentation page you already found also explains what to do if you forgot the password and the console is locked.

[client]

I respectfully disagree. The delegating router always knows where to send packets destined for the delegated subnet to: The address where the PD request came from.

• This issue is specific to OPNsense. Other delegating routers handle PD-only just fine. They route the delegated prefix to the requesting router's link-local WAN address.
• OPNsense's DHCPv6 client has an option to only request a prefix, not an address. This currently only works if the delegating router is a third-party box, but not if it's an OPNsense router, too.
• The current behavior makes it impossible to deploy PD in networks which already run a third-party DHCPv6 server for address assignment. A Windows Server running DHCP with Active Directory integration is a real world scenario found in many places. So it must be possible to use separate DHCPv6 servers for address assignment and PD.
• RFC 3633 says: "Prefix delegation with DHCP is independent of address assignment with DHCP.  A requesting router can use DHCP for just prefix delegation or for prefix delegation along with address assignment and other configuration information."

[AND]

I did some lab testing today with two freshly installed OPNsense VMs. Router A is delegating prefixes via its LAN interface, router B is requesting a prefix via its WAN interface (connected to A's LAN interface). B gets a prefix from A easily, but A only adds a route to the delegated prefix under very specific conditions: An address range must be specified in A's DHCPv6 server AND B's DHCPv6 client must be configured to actually request a WAN address.

If A's DHCPv6 server is used for PD only (no address range specified) OR B's DHCPv6 client is configured to only request a prefix (not an address), then A will still delegate a prefix, but won't add a route pointing to it.

I consider this to be a bug. Prefix Delegation should work independently of assigning addresses via DHCPv6. It is quite common to use a router's DHCPv6 server for Prefix Delegation only and to use a separate machine (e. g. Active Directory integrated Windows Server) for assigning IPv6 addresses (or to simply use SLAAC only).

Should I create a bug report on GitHub?

I couldn't get NAT reflection to work in 17.7 but it "just started to work" some time after the 18.1 upgrade.
My settings are very similar:

In the Port Forward rules:
NAT reflection: Use system default
Filter rule association: Pass

Firewall / NAT / Outbound:
Automatic outbound NAT rule generation

Firewall / Settings / Advanced:
Reflection for port forwards: Enabled
Automatic outbound NAT for Reflection: Enabled

I have only one IPv4 WAN interface and don't use OpenVPN.

Hi Franco,

Thanks for helping out so quickly. I'm on OPNsense 18.1.5-amd64.

These are my OPNsense IPv6 LAN settings:
Static IPv6 address: 2001:db8:feed::1/64
DHCPv6 Prefix Delegation Range: 2001:db8:feed:8000:: to 2001:db8:feed:bf00::
DHCPv6 Prefix Delegation Size: /56

I can see a downstream router getting delegated the prefix 2001:db8:feed:bf00::/56. I expected to find an auto-added route to this prefix in System / Routes / Status, but it's not there.

How could I troubleshoot this?

(BTW, I don't use OPNsense's DHCPv6 server for assigning addresses, so no address range is specified. Downstream routers get their WAN addresses via SLAAC. No idea whether that's relevant, but I better mention it.)

Thanks,

Maurice