Picture this: It's Monday morning, you’ve just grabbed your coffee, and you're ready to tackle the week. You try to RDP into a critical Windows Server, but instead of the familiar desktop, you're greeted by that cold, impersonal message about a failed connection.
As a system administrator, this scenario is probably all too familiar: A remote employee—perhaps a manager working from home—calls in. They can successfully connect to the main office (the Hub) via mobile VPN, but they can't reach a critical file server or application at your branch office (the Spoke). You check the basics: the Site-to-Site VPN is up, and the Mobile VPN connects fine. So, what's wrong?
This common network topology is known as a "Hub-and-Spoke VPN." The solution lies in properly configuring your firewalls to handle this specific traffic path. At Erkmenhost, this is a challenge we know well, and this guide will show you exactly how to solve it.
Think of your VPNs as two separate bridges. The first bridge (your Mobile VPN) gets a user from the open internet safely to your main office. The second bridge (your Site-to-Site VPN) connects your main office to the branch office. The problem? By default, there’s no road connecting the end of the first bridge to the start of the second.
Technically, the issue stems from three things:
Our guide will focus on WatchGuard firewalls at the Hub, but the principles apply to any modern firewall.
First, we need to tell the Site-to-Site VPN tunnel to consider mobile users as part of the "local" traffic. Navigate to VPN -> Branch Office VPN (BOVPN)
in your WatchGuard interface. Edit your tunnel and go to the "Tunnel Route" tab. Click the "Add..." button to create a new route:
SSLVPN-Users
by default).After completing this step, your tunnel route configuration should look similar to this, with two local networks now able to communicate with the remote network:
Now, let's give the traffic cop instructions to allow passage. Navigate to Firewall -> Firewall Policies
and add a new policy. Configure the rule as follows:
SSLVPN-Users
SiteB-Subnet
)Allow
.This step is critical for ensuring the return communication works. The user's original IP address must be preserved. The best practice is to create a specific **"No-NAT"** rule for your VPN traffic. Navigate to Network -> NAT
and add a new Dynamic NAT rule that sits *above* your general outbound rule. Configure it to ensure traffic between your VPN user pool and the remote site is not NAT'd.
The branch office firewall also needs to know about your mobile users. You must edit the Site-to-Site VPN configuration on that device to add the mobile VPN user IP pool to its **"Remote Network"** definition. This tells the branch office how to send reply traffic back. Finally, create a firewall rule there to allow the incoming traffic.
As you can see, allowing mobile VPN users to access resources at a remote office is a matter of connecting two otherwise separate tunnels. By defining the correct routes, creating explicit firewall policies, and ensuring NAT doesn't interfere, you create a seamless and secure path for your remote workforce.
At Erkmenhost, we know that managing a secure and efficient network involves navigating these intricate configurations. We're here to guide you through the complexities and ensure your business remains connected and secure.