Messages

It's not clear to me if your problem is about DHCP or about internet access after DHCP. When one of the affected systems doesn't "have internet", have you confirmed whether or not it actually has started using the statically assigned address from the range that should "have internet"?

Note that (AFAIK) DHCP does not provide any way for a server to rescind a lease. It's expected that once a lease is granted, it will be honoured until it expires. Moving a client to a different lease requires a request for renewal from the client. At point, the server can refuse to renew an existing lease, and offer a new one with a different address.

I wonder if your rebooting the firewall is causing your clients to ask for new leases.

If you've confirmed that the clients are actually using the statically assigned addresses and still don't "have internet", further investigation would be required....

I suppose so. I'm currently focused on the "out of box experience" - i.e. I just want to plug in the credentials supplied by my ISP and I expect basic internet access (including IPv6) to "just work". It seems unfriendly that I have to configure something that seemingly could easily be derived from the DHCP response.

Actually it could have helped me, but we got there in the github discussion.

In my case, at least, the issue was (in part, at least) my failure to pay attention to the "Prefix delegation size" for the WAN interface. In my mind, this should be determined from the DHCP response, so I shouldn't have to configure it statically. Apparently when this setting is 64 (the default) it causes the prefix allocation for LAN interfaces to use the entire delegation (not sure why). So I think it's partly a user error, partly a shortcoming (should be automatic) and partly a bug (the weird end result).

Filed https://github.com/opnsense/core/issues/10070

Something appears to be rather broken with LAN prefix assignment in 26.1.x. I just attempted a new configuration from scratch (with the intent to document the process for my ISP's community). I have a /56 prefix delegation from the ISP. When my LAN interface is configured for "Identity Association", OR even when configured for "Track Interface (legacy)", it (the LAN interface) gets assigned the entire /56 prefix, where it should be given the first available /64. If I try to change "Assign prefix ID" to 1 (instead of 0) (shouldn't have to do this, but as a data-point...), it says that that's out of range.

@melectronics, did you open a bug for this yet?

I'd still tend towards the client going to sleep (in some sense). Perhaps the GL.inet is periodically broadcasting something that causes it to stay awake?

A client with multiple interfaces doing DHCP on the same LAN segment is kindof unusual, and I don't think it's really catered for in OPNsense. It appears that the proper way to do it would be to use a combination of DUID and IAID, but the UI (at least) doesn't provide a way to configure that.

I haven't tried to use dnsmasq yet, but looking at the UI, there is a place for "Hardware addresses", as well as "Client identifier" when configuring "Hosts". I don't know if that would accomplish what you need, but it might be worth checking out....

What is the purpose of the virtual NICs? Presumably they are on different LAN segments? You should be able to create static mappings with the same DUID on different interfaces (at least with ISC - I haven't looked at dnsmasq integration yet)...

What have you selected as the protocol for your "Domain"? If it's not "https", there'll be no certificate to get.

Have you added a firewall rule on your WAN interface to allow access from outside?

A self-signed cert will always show as insecure unless you have told your browser to trust it explicitly. This would have been the case for the original WebUI cert before you changed hostname.

You probably want to select "route-noexec" under Miscellaneous/Options, assuming your intent is to recreate policy-based routing (as well as outbound NAT)

You didn't say what release you're running - I think the UI changed a bit - but in 25.1(.5), go to System -> Trust -> Certificates, click '+' button to create a new one, with method "Create an internal Certificate", set type to "Server Certificate", and fill in the blanks as you wish.

Some NAS boxes block access from anything other than the local LAN )the subnet they're directly connected to).

I suspect that the Windows hosts on the same VLAN are using something other than DNS to resolve eachother.

What do you have configured for:

Services > Unbound DNS > General > Register ISC DHCP4 Leases

System > Settings > General > Domain

?

If you connect the notebook directly to OPNsense, you'll have to configure it to handle the tagged VLAN, which is likely to cause you even more confusion.

Are you still having issues after configuring the OPNsense switch port to tag VLAN 10? Or maybe you haven't had a chance to try that yet?