When OPNsense routes traffic through an incorrect gateway, such as a WireGuard tunnel to Sweden instead of your local WAN, sites detect the wrong geographic location. This issue typically stems from misconfigured Gateway Groups or policy routing rules that fail to prioritize the correct interface. By verifying gateway status and adjusting system settings, you can restore accurate IP-based geolocation for all outbound connections.
Understanding the Root Cause
The primary reason OPNsense senses the wrong gateway is often related to how the firewall handles multiple available paths. In many setups, users configure a secondary connection, such as a WireGuard tunnel, for specific purposes like privacy or access to region-locked content. However, if this secondary interface is marked as "Active" in the default gateway group, all untagged traffic may route through it. This causes external services to see the IP address associated with the tunnel endpoint rather than your primary broadband connection.
Another common culprit is the interaction between Unbound DNS and DNSMasq. If Unbound is configured to forward specific queries but the underlying routing table does not align with these forwarding rules, DNS resolution may succeed while the actual HTTP traffic takes a different path. This discrepancy leads to situations where name resolution works correctly, but the source IP used for the connection is unexpected. For more details on similar network blocking issues, you might find Troubleshooting pFsense: Issues with Blocking RFC1918 Networks for LAN helpful for understanding broader routing logic.
Verifying Gateway Status
The first step in troubleshooting is to ensure that OPNsense correctly identifies which gateways are online. Navigate to Diagnostics > Gateways in the web interface. Here, you will see a list of all configured gateways along with their current status (Online/Offline) and latency metrics. It is crucial to verify that your primary WAN gateway shows as Online and has low latency. If the WireGuard gateway is also marked as Online, OPNsense may load-balance or fallback to it depending on the configuration.
If both gateways appear online, check the "Preferred Gateway" column. The system uses this setting to determine which interface to use by default. Ensure that your local WAN is set as the preferred gateway for general internet traffic. Any deviation here can cause immediate geolocation errors. Additionally, review the "Monitor IP" field. If the monitor IP is unreachable, the gateway will be marked offline, potentially forcing traffic to the backup interface unexpectedly.
Configuring Gateway Groups Correctly
Gateway Groups define the order in which OPNsense attempts to use gateways. Go to System > Routing > Gateway Groups. You will likely see a group named "Default" or similar. Inspect the members of this group. If your WireGuard interface is included here, it becomes a candidate for all outbound traffic unless explicitly overridden.
To fix this, you have two main options. First, remove the WireGuard gateway from the Default Gateway Group entirely. This ensures that only your local WAN is considered for standard traffic. Second, if you need the WireGuard tunnel for specific applications, create a new Gateway Group that includes only the WireGuard interface. Then, assign specific firewall rules to use this new group, leaving the Default group for general browsing. This separation prevents accidental leakage of traffic into the tunnel.
Adjusting Policy Routing Rules
Once the gateway groups are structured correctly, verify your firewall rules. Navigate to Firewall > Rules > WAN (and LAN if necessary). Check if any rules specify a particular gateway. By default, rules should leave the gateway field blank, allowing the system to use the Default Gateway Group. If a rule explicitly selects the WireGuard gateway, all matching traffic will bypass your local ISP.
Ensure that your inbound and outbound NAT rules are also aligned. Incorrect NAT configurations can sometimes mask the true source IP, leading to confusion during troubleshooting. Review the NAT rules to confirm that they reference the correct interfaces and do not force translation through the tunnel. For more information on interface mismatches, consider reading Troubleshooting Access Point IP and Router Gateway Mismatch.
Final Verification Steps
After making changes, clear the cache and test the connection. Visit a site like whatismyipaddress.com to verify that your public IP matches your local ISP's range. If the IP is still incorrect, check the Unbound configuration again. Ensure that Unbound is not inadvertently pushing DNS queries that trigger specific routing policies. Restart the Unbound service via Status > Services to apply any recent changes. Consistent monitoring of gateway status will help prevent future occurrences of this issue.
Frequently Asked Questions
Why does my IP change only after restarting the router?
Your IP changes because the reboot resets the gateway selection process, often causing OPNsense to re-evaluate link states. If the WireGuard tunnel comes up faster than the local WAN, it may temporarily take over as the active gateway until manual intervention or script adjustments correct the priority.
Can I use a single gateway for both DNS and traffic?
Yes, but it is safer to separate them using policy routing. Using a single gateway for both can lead to DNS leaks if the tunnel drops, exposing your real IP to the destination server. Separating them ensures that DNS queries remain consistent even if the data path changes.
What happens if I disable the WireGuard interface completely?
Disabling the interface removes it from the routing table entirely, guaranteeing that no traffic passes through it. This is the most effective way to stop geolocation errors if you no longer need the tunnel for any specific application or service.
How do I check if Unbound is affecting my gateway selection?
You cannot directly check this in Unbound, but you can observe the behavior by disabling Unbound temporarily. If the correct gateway resumes functioning immediately after disabling Unbound, the issue lies in how Unbound forwards queries or interacts with the routing table.
Is it safe to leave both gateways active in the default group?
No, it is not safe if you require consistent geolocation. Leaving both active creates unpredictable routing behavior based on load balancing algorithms or failover triggers. Always designate one gateway as the primary for general traffic to maintain stable IP identification.