Messages

It does. You do not have a publicly reachable IPv4 address, anymore.

This was indeed correct, I contacted my ISP and requested a new public IP. It got sorted and after rebooting my opnsense router it's now on the new IP and the Wireguard connection works again. It's a bit annoying that they put me behind CG-NAT without even notifying me.

Sometime in the night between Tuesday and Wednesday this week my public IP changed, which caused my Wireguard clients to not be able to connect. I then updated the endpoint IP which is behind a public DNS record to the response I get with `curl ifconfig.me` from inside the network. But even with the new IP the clients still fail the Wireguard handshake. This is strange, because I know I was using the VPN on Tuesday evening with no issues when I was out on some errands, and now I can't connect even after updating the DNS record. I've also tried restarting the Wireguard service from the dashboard several times to no effect. What's even stranger is that I can see in the Wireguard `Status` page that there are clients attempting to connect as there is some small amount of data shown in the `Sent` column, but none in `Received`.

I found some older threads where similar behavior was discussed but no clear solutions proposed - is this a known issue with the Wireguard service/plugin in opnsense? Or has some config changed with recent versions? I'm currently on opnsense 25.7.11 and planning on upgrading to 26.1 in the weekend.

Right now my plan of action is to just wait until I can upgrade to 26.1 in a few days. If that doesn't fix it, do I need to uninstall the Wireguard VPN and then reinstall it again, or is there anything else I can do? This behavior is a bit worrying, and I'm not confident to switch to DDNS if the change to a new IP doesn't happen smoothly and instead results in my clients suddenly starting to fail their connections silently.

EDIT: One other suspicion I have is that my ISP may have changed something else. The WAN interface IP I have on opnsense is in the range 100.xx.xx.xx/18 but the response from `curl ifconfig.me` shows an IP in the range 178.xx.xx.xx. I'm not sure if this indicates that they've added some layer of CG-NAT to my connection?

Thank you all for your replies, so it behaves like I was guessing, i.e. hitting the WAN address from inside the LAN. This makes complete sense for the behavior I'm observing and gives me peace to know that the ports aren't open to the internet anymore. It also simplifies some things for me as I can share some services to an isolated "work" VLAN which can look up public DNS records pointing to my WAN address and route them locally without having to set up anything more to make it work.

<deleted duplicate post>

I've had http(s) ports open to access from WAN previously, exposing some services to the internet, and am now closing them as my needs have changed. What I had were rules on the WAN interface allowing ingress on the ports which were forwarded to hosts with reverse proxies.

But what I'm not understanding is that after disabling these ingress rules on the WAN interface I still get a response saying the ports are open when checking using netcat like `nc -zv my.public.ip 443` from local VLANs. Is there some other set of config that could still be providing the ingress, or is the WAN IP automatically routed with some kind of loopback behavior inside the LAN which gives me this result? I tried accessing one of the previously exposed services from my phone on mobile network, and at least from there I can't access the ports anymore, but I would like to understand how I'm getting this open port response internally when pointing to the same WAN IP from the LAN.

AGH has the ability to "rewrite" DNS as well, so you can make you own domain point to local IPs using just AdGuard Home. Hence you could put AdGuard first (and maybe you don't need dnsmasq at all anymore?).

Just an idea.

That's excellent, I didn't know AGH could do that with wildcards and exclusions, but it actually can.
I set up AGH to do the same as I've done with dnsmasq so far, and it seems to work correctly, so I'll be uninstalling dnsmasq and the end result is a simplified setup, very nice!

I feel like I need to jump in here and ask for some AdGuard help as well. I'm having issues configuring dnsmasq+adguard on opnsense to be able to distinguish which clients are making which DNS lookups (i.e. retain local client IPs).

I currently have the requests going like `client -> dnsmasq (53) -> adguard (53530)`. The reason why I have dnsmasq is because I own a domain that I route to an internal reverse proxy on the LAN, so dnsmasq is resolving mydomain.com to a local IP and forwarding the rest to AdGuard.

The thread is very long at this point, so apologies if this has already been answered, but how can one go about setting things up so that AdGuard will be able to display the local client IPs in the dashboard, and not just 192.168.1.1 when forwarding via dnsmasq on the opnsense device?

No takers? Is this to say that what I'm looking for can't be done with dnsmasq and/or opnsense?

I'm running dnsmasq as my main dns handler on opnsense, because I split dns for some local use cases.
Recently I set up AdGuard Home and noticed that there is only one client ip shown, 192.168.1.1 of the router.
This I assume is due to dnsmasq acting as a dns proxy to adguard for all reguests going out to the public internet.

To summarize my requests go: client -> dnsmasq (53) -> adguard (53530) -> wan

Is there a way to configure dnsmasq and AdGuard so that requests passing through dnsmasq retain the client ip information which can then be properly displayed by AdGuard Home dashboard?

I'm trying to set up a streamer on a separate IoT network in my LAN so that the Symfonium android app can cast via UPnP to that device from a trusted network, keeping the streamer isolated from other devices but still accessible for casting.

Symfonium is the casting app, with a Wiim Pro streamer and a subsonic media server source. The media server and Symfonium phone is on VLAN "Trusted", and the Wiim Pro is in another VLAN "IoT".

The problem I'm having is that both the android apps for Spotify and Wiim can reach the steamer across my VLANs (I have set up mDNS multicast across the networks), however Symfonium is unable to find the streamer as a UPnP device if the phone is connected to the trusted network. If I connect the phone Wi-Fi to the IoT network, then Symfonium immediately finds the streamer and can cast audio.

I'm wondering what network configuration is needed, or even possible, in order to have UPnP traverse across VLANs?


Additional information:

I have temporarily enabled full network access between the VLANs to minimize any other sources of error. I also have firewall rules opening traffic to 224.0.0.251:5353 both ways between the VLANs to support mDNS multicast, along with a mDNS-repeater between the networks.

Summary

    Spotify and Wiim apps can discover the streamer device across VLANs
    Symfonium can not discover the streamer across VLANs
    Symfonium can discover the streamer if connected to the same VLAN
    Firewall rules are in place to support cross-network discovey with mDNS
    All other traffic between the two VLANs is currently open in order to mitigate other sources of error.

It's likely you'll have DHCP reservations for VPN clients so might as well provision the public resolver in the reservation profile

I'm not following, how does DHCP affect what DNS lookups I can make from inside my LAN?

Nobody?

I think I found the issue. I had accidentally set the egress rule from the Wireguard network to internet invert the source, i.e. it said "! Wireguard net -> allow egress to internet", which didn't work of course.

Use tcpdump on all relevant interfaces to observe where packets start to fail.

I tried packet capture between two sets of interfaces.

First from WireGuard to Trusted, here I can successfully ping an IP in the Trusted network and packet capture shows me the packets as expected.

Then I tried WireGuard to WAN interface and netcatting 1.0.0.1 port 53, in this case netcat fails to reach the destination and packet capture doesn't catch anything either.

I'm not sure else I can look at, what path are the packets expected to take from the WireGuard interface?

Do you have a matching outbound NAT rule on your WAN interface?

Yes, there is an auto-created outbound NAT rule for all networks, including the WireGuard one.