Messages

The 'last updated' column in Firewall/Aliases suggests all my dynamic aliases (including ASN based) are getting updated. I have no cron job enabled for this.
But it is not clear to me what an ASN based alias update entails or if its happening. The Firewall/Log/General shows there is an master ASN list update, but no indication that the IPs in an active ASN based alias are being checked and updated. Is the ASN CIDR mapping something that is confined to the internals of pf?

Quick update-

The DNS storm seems to have stopped overnight but I'm not sure why.

I wouldn't bet on it. When I first noticed the increase in  DNS queries, I left the roku powered down for a short period. After restarting, DNS queries remained low for some time, but eventually returned to once per second for each of various hosts in logs.roku.com. I don't see any performance hits at that level but it is rather irritating and does put me off buying more such devices.

I don't know about the OP but IME the Roku DNS storm is a hissy fit in response to DNSBL. I only forward DNS to the pihole for select clients. Everything else, inclusing the pihole, queries opnsense unbound directly, which is not using any DNSBL.

Annoying isn't it. These roku boxes are infuriating from a networking POV but are a big favourite with older people for easy access to streamed TV because the interface is a masterclass in UX. Sadly I have one here :-( and I resorted to putting it on a smart plug to keep it off most of the day. I put it on its own SSID which is also on a schedule. A bit extreme but at least I no longer see 24hr DNS storms. Whilst they are known to be chatty, something updated a couple of months ago that resulted in much higher rates of queries for those same few hostnames. I have the roku querying a pihole so these requests fortunately don't hit opnsense.

With hardware/driver support limiting what you can do with wifi on opnsense, and concerns you have about wireless access point security, physically separate devices would seem the best choice for you. That or no wireless network.

I have already done some work with openwrt as well and my router is already in bridge mode
I have just never worked through using a wireless access point (I feel so old fashioned, lol)

Much of it is new to me also but in my unqualified opinion an opnsense router coupled with openwrt access point(s) is an appealing combo for a home user. You are able to re-purpose your existing gear or buy cost effective secondhand and there is ample documentation on both. I have a couple of meraki units, running openwrt in 'dumb AP mode', connected via a small managed switch. You can in theory connect the APs directly to the opnsense box, but this can lead to interface issues on the router side. Check out the openwrt guides for access point only mode. Then consult the docs here for opnsense vlans.

Just change the first "2" to a different number (e.g. 10.3.0.2).

I'm glad this solves things for the OP. How come it is accommodated by the remote peer?
I admit I don't understand wireguard at all well despite the fact it seems to be performing admirably for me on opnsense.

For 26,7 someone's going to have to come up with a name that doesn't sound like a dinosaur with a skin condition.

If possible you should avoid Reverse NAT a.k.a. NAT Loopback anyway, so maybe a good moment to consider moving away from it ?!

Why? Genuine question.

It's considered a sub-optimal workaround, less secure. I decided to pass on NAT reflection options, for both pfsense and OPNsense, probably some point after reading documentaion, beginning with https://docs.netgate.com/pfsense/en/latest/nat/reflection.html. I then thought split DNS might be affected by TTL, so avoided that solution. Eventuallly addressing it only when needed, with my own NAT rules. AIUI it's only considered NAT reflection if the redirected traffic 'hairpins' via the WAN.

wg1: Packet has unallowed src IP from peer 1

Might this be complaining about an 'unallowed' IPv6 address?

You need to set up NAT reflection:

https://docs.opnsense.org/manual/how-tos/nat_reflection.html

IIRC that was a consideration when I set up openvpn prior to trying wireguard. It was a while ago and my memory is not great but I do remember deciding against using NAT reflection anywhere after reading the caveats in the docs. Preferring instead to use split DNS or in this case explicit port forwards.

I'm finding when switching from 5g to wifi, I need to turn off/on wifi and wg off/on and then it works correctly again. As if the routing needs to be reset.

Do you ever need to do this?

Other than brief delays when the phone switches from wifi to mobile, no. I never need to restart android client or toggle wifi/mobile. Having said that I am not a heavy mobile user. But the only times I experience VPN connection issues is if I am out and lose mobile signal.

I also use a cloudflare A record for my vpn client conf.
wg client conf specifies a local DNS server (pihole) and search domain (local.lan).
Opnsense's unbound is the upstream server for the pihole.
Wireguard interface wg0 is assigned to a specific interface (VPN) and rules on there permit access to the local pihole instance amongst other things.

When using openvpn, prior to wireguard, I tried various configs to get the smoothest roaming experience. I ended up with port forwarding to localhost (for both WAN and LAN) because I found the openvpn server not reliably listening on all interfaces. When I switched to wireguard, all I did was modify port aliases and of course configure wireguard.

I tried wireguard for first time very recently, after using openvpn for a long time. After setting up the FQ Codel scheduler as per the buffer bloat recipe, I began to see increased openvpn warnings re out of sequence packets. So, thought it a good time to try Wireguard.

I am not sure why you see intermittent connectivity when connected to WG on the LAN. I notice the WG android client log is not very detailed.

Not sure where your issue lies but the way I have done this (for both openvpn and wireguard) is one destination NAT rule on the WAN, and another on the relevant lan interface. Both forwarding wireguard port to 127.0.0.1. I found that to be the most reliable way to get mobile/wifi roaming whilst only using WAN IP in any vpn client config. The WAN version of the port forward and fw rule filters src by my mobile provider's ASN.

There are times when you might want to apply the config regardless. IMO it's preferable to keep the button enabled even when the system deems it unnecessary.