Messages

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?

You could use a ULA prefix for your LAN and NPTv6 to map it (dynamically) to your delegated prefix.

Feel free to offer a PR to the docs. I only added the bare minimum there that only explains one simple common setup.

I know there are probably 100 edge cases but if you know what to improve please do. Thank you.

It (the second link in the original post) seems just wrong (or possibly outdated) to me. It suggests setting the VLAN interface (igc1_vlan7_PPPoE) IPv4 Configuration Type to PPPoE. You can't do that (in contemporary releases, at least) - you have assign the *PPPoE device* (not the VLAN one) to the *WAN* interface, and configure *that* with IPv4 Configuration Type "PPPoE"

As a side note; I find statements like "Create a VLAN interface on the WAN interface." unfortunately confusing, as the term "interface" is a bit overloaded - maybe better to say something like "Create a VLAN on the network device connected to the WAN"

What you've done sounds fine to me. You could have created the PPPoE device and assigned it as your WAN interface without using the wizard, but either way should be good. The documentation ... well, there's some "room for improvement".

I'm rather confused by your problem description.

You state that udpbroadcastrelay was required to make Google Home work, but also state that Google Home doesn't work if some rule relating to udpbroadcastrelay is enabled. What does this rule do, exactly? Is it a firewall rule, or something else?

Also, you suggest that you have a "flat network" with a single subnet (10.0.0.0/24). If so, what udpbroadcastrelay relaying between? Normally it would be used to relay between multiple LAN interfaces/subnets.

Your hack may seem to make the problem go away for now, but it seems that you haven't really diagnosed and solved the root issue.

1:1 NAT may work for this case (if "all ports" is a requirement), but the remote user would need to connect to 99.99.99.99, since (as pointed out already) 192.168.x.x is private (RFC 1918) IP space that is not routable on the internet. If use of the 192.168.40.26 address on the remote client is a requirement, a VPN would be the only way (if it's possible on the client side).