Firebox geolocation denial: find the VPN entry stage first

Someone in another country cannot connect, and the first instinct is to look at the rule that grants access to internal resources. That rule runs after admission, so it cannot be the thing rejecting the tunnel. The blocking stage is somewhere in the entry path, and the Firebox has more than one entry path depending on the VPN service. Work the checks in order and stop as soon as one of them explains the deny.

Check 1: name the incoming service

For Mobile VPN with SSL, Access Portal and BOVPN over TLS, the incoming entry is the WatchGuard SSLVPN policy. Apply the intended restriction there, on the actual configured service, rather than inferring it from a user-access rule that runs later.

IPsec takes a different path. The built-in IPSec policy permits external IPsec traffic to the Firebox for the applicable branch and mobile VPN services, and it takes precedence over a manually created IPSec policy. If your client is IKEv2, you are in that second path, and the SSLVPN policy is irrelevant.

Getting this wrong is the most common wasted afternoon in this area: editing a policy that never sees the packet, then concluding that the restriction does not work.

Check 2: read the deny, not the theory

Make one controlled permitted attempt and correlate four things: the client's public source address, the entry service it hit, the policy that matched, and any Deny reason in the log. WatchGuard's IKEv2 troubleshooting guidance notes that geolocation and default packet handling can deny traffic before built-in policy admission, which means the deny you see may name a stage you have not considered.

Country classification follows the observed network source. A roaming user, an upstream NAT or a different approved path can change what the Firebox sees, so confirm the address rather than the user's description of where they are. Ask for the public address the client sees, and compare it with the source in the Firebox log. When those differ, the classification is following a path nobody mentioned.

Check 3: is the built-in policy still the owner?

If a manual IPSec policy appears to be ignored, check whether the built-in one is still enabled. A manual rule that is shadowed by a higher-precedence built-in rule and a manual rule that is the only admission are different configurations with the same-looking UI.

Decide which one you intend to own the path. If it is the manual policy, the built-in one has to be disabled for that traffic, and that is where the next check begins.

Check 4: plan the replacement before disabling

Disabling the built-in IPSec policy removes its admission for the affected VPN services. That includes branch tunnels you may not be thinking about while you fix one mobile user's connection.

Plan the complete replacement first: which services need admission, which source scopes they get, and how you will manage the box if the change goes wrong. Keep an independent management and recovery path open, because a mistake here can remove the tunnel you would use to fix it. Note the recovery steps in the change record, including how to reach the box if the VPN path is gone. Then test renewal, not just the first connection.

Active connectivity and later renegotiation can both depend on admission. A change that works for the session you tested and fails at the next rekey is a classic outcome of replacing admission without testing renewal.

Check 5: keep identity separate from location

Geolocation adds context to an entry decision. It does not establish who the user is, and it should not replace gateway identity checks, account authorization or MFA.

If the business requirement is only approved users from approved places, you need both controls. A location rule that admits an entire country is not a substitute for authentication, and an authenticated user in a blocked country is a policy question rather than a bug.

Check 6: record it and verify both paths

Write down the service, the entry policy, the intended location scope, the exceptions and the recovery owner. Then test the mobile path and at least one site path after the change, so the restriction stays attached to the service it was designed to control.

Finally, re-read the deny you started with. If it has changed from a location deny to an authentication or authorization failure, the entry problem is solved and a different one is now visible. The WatchGuard IKEv2 denial guidance is the reference for the stage ordering described above.