Alright, let's dive into a classic Firebox configuration headache that I'm sure someone will blame on 'policy' or 'the network team' before actually checking the box. We've successfully migrated our site-to-site VPNs to a Firebox (M470, if you must know), and general connectivity is fine. Remote users on WatchGuard Mobile VPN (SSL) can reach most of our internal resources.
The maddening exception? An entire /24 subnet housing our legacy application servers. These servers are reachable from *inside* the office LAN and via the *site-to-site* VPN tunnels, but any client connecting via the Mobile VPN client hits a brick wall. Pings die, traceroutes vanish into the void after the Firebox's internal interface.
Before you ask, because I know you will:
* Yes, the Mobile VPN pool (10.254.254.0/24) is correctly defined and clients get an IP.
* Yes, there are policies allowing `SSLVPN` -> `Any-Trusted` and `SSLVPN` -> `Any-Optional` (we've tried both) for HTTP, HTTPS, ICMP, and even a blanket `Any` rule during testing.
* No, it's not a server firewall issue—they respond fine from other internal subnets.
* The route for the problematic server subnet (`172.16.30.0/24`) exists on the Firebox and points to the correct internal gateway.
Here's where my contrarian spidey-sense tingles. The "industry standard" checklist is done, so we must be missing the Firebox-specific *gotcha*. I'm betting the devil is in one of these details:
1. **Split Tunnel Configuration:** The VPN clients *are* using split tunneling. The included routes *should* have that `172.16.30.0/24` subnet. How do we definitively verify the Firebox is actually pushing this specific route to the clients? The generic "route all traffic through VPN" option works, but that's a bandwidth-bloated non-solution.
2. **BOVPN Virtual Interface vs. Traditional:** The site-to-site tunnels to our other offices are using BOVPN Virtual Interfaces. Could there be some quirky interaction where the Firebox is trying to route the Mobile VPN client traffic *through* one of these virtual interfaces meant for another tunnel, instead of treating it as directly attached traffic?
3. **Policy Order/Overlap:** Is there a hidden, higher-priority policy (maybe from a feature like "DHCP Server, WINS, and DNS Configuration" for the VPN) that's taking precedence? The Firebox policy logic isn't always intuitive.
4. **The "Any-Trusted" Fallacy:** We've lumped the server subnet into `Any-Trusted`. What if the Firebox treats traffic *from* the `SSLVPN` zone to `Any-Trusted` differently than intra-`Any-Trusted` traffic? Should we create a separate alias just for this server subnet and build explicit policies?
I'm looking for the kind of insight that isn't in the quick-start guide. The kind you get after wasting an afternoon with packet captures. Has anyone deconstructed this particular issue and found the actual, non-obvious checkbox buried three menus deep that makes it all work?