Messages

[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

[This is not about requesting a prefix from an upstream router / ISP, but about delegating prefixes to downstream routers in the LAN.]

This is not about requesting a prefix from an upstream router / ISP, but about delegating prefixes to downstream routers in the LAN.

I have a static /48 from my ISP. OPNsense is used as a distribution router and should delegate /56 prefixes to other routers connected to its LAN interface.

Prefix Delegation Range and Prefix Delegation Size are properly configured in Services / DHCPv6 / LAN and downstream routers successfully request prefixes (visible in Services / DHCPv6 / Leases / Delegated Prefixes).
However, OPNsense doesn't seem to add routes for the delegated prefixes to its routing table. So clients connected to the downstream routers can't access the Internet.

Is this working for someone? If so, am I missing something? Or could this be a bug?

*BUMP*

I'm also in the process of switching one LAN to IPv6 only and would like to do DNS64/NAT64 in OPNsense.
FreeBSD supports NAT64 in ipfw and Unbound can do DNS64, so I guess the only thing missing are some options in the WebIf? But I might be oversimplifying things. ;)

Is this on the roadmap?

Thanks!
Maurice

Hi Franco,

Wow, that was quick! I'm seriously impressed.

Initially the patch failed to install, but I figured out I had to apply 97c4edf first. Then it worked.
Flags in RAs are looking good now and the DHCPv6 server can be enabled without specifying an address range.

Going further, there seem to be multiple issues with incorrect or missing RDNSS / DNSSL options in both RAs and DHCP replies. I'll investigate that in more detail and report back.

Thanks again!

Maurice

Hi Franco,

I wouldn't say something is wrong, but something is missing. I did some more research and it seems that this was added to pfSense after the fork: https://github.com/pfsense/pfsense/pull/1033
Maybe this can be added to OPNsense, too?

Background: There are 3 flags in RAs relevant for address configuration and optional information (DNS servers, domain search list etc.):

• The A flag tells the client to autoconfigure an address using SLAAC.
• The O flag tells the client to query a stateless DHCPv6 server for optional information.
• The M flag tells the client to query a stateful DHCPv6 server for an address.

In Services / DHCPv6 / Advertisements there are 4 operating modes:

• Router Only sends RAs without any of these flags. Clients have to be configured in another way.
• Unmanaged sets the A flag only. Clients may autoconfigure an address and use the RDNSS / DNSSL options in RAs to get DNS servers and domain search list.
• Managed sets the M + O flags. Clients may query a stateful DHCPv6 server for an address and all the optional information.
• Assisted is like Managed but additionally sets the A flag so clients may autoconfigure an address (in additon to the address they get from DHCPv6).

What is missing is a mode which sets the A + O flags, indicating that clients may autoconfigure an address and query a stateless DHCPv6 server for optional information only.
Also, it should be possible to enable the DHCPv6 server (Services / DHCPv6 / Server) without specifying an address range so it is running in stateless mode.

Thanks

Maurice

Hello all,

This is my first post! :) I'm currently virtualizing a router by migrating from an old embedded Linux box to a fresh install of OPNsense 17.7.7_1 in a Hyper-V VM. Pretty straightforward so far, but now I'm stuck at setting up stateless DHCPv6 for the LANs.

In the existing setup, clients use SLAAC for address autoconfiguration. Clients which don't support the RDNSS / DNSSL options in RAs (like older Windows versions) use stateless DHCPv6 for DNS server and domain information.

In OPNsense, the Router Advertisement "Assisted" mode seems to be the only one which sets the required A and O flags in RAs. But it also sets the M flag which indicates stateful DHCPv6. There seems to be no "A + O flag only" mode. Also, the DHCPv6 server can not be enabled unless you specify an address range.

I've never used an IPv6 router which doesn't support this, so I'm not sure whether this is really missing or I just can't figure out how to configure it (these are my first steps with OPNsense).

Thanks

Maurice