X
X

Hub-and-Spoke VPN: Connecting Mobile and Site-to-Site Tunnels

HomepageArticlesNetwork & SecurityHub-and-Spoke VPN: Connecting Mobil...

 

Hub-and-Spoke VPN: Connecting Mobile and Site-to-Site Tunnels

That Sinking Feeling: When Your Server Won't Let You In

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.

Why Doesn't It "Just Work"? The Anatomy of the Problem

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:

  • Undefined Routes: The Site-to-Site VPN tunnel has no idea that the IP address pool for your mobile VPN users is a legitimate source.
  • Missing Permissions: Your firewall's policies don't have a rule that explicitly allows traffic from the "Mobile VPN User" zone to travel across the "Site-to-Site VPN" zone.
  • The NAT Trap: This is the sneakiest culprit. Your main office firewall might be hiding (NAT-ing) the mobile user's original IP address. When the branch office server replies, it doesn't know where to send the response.

The Action Plan: Configuring the Hub (Main Office Firewall)

Our guide will focus on WatchGuard firewalls at the Hub, but the principles apply to any modern firewall.

Step 1: Expand the Tunnel Routes

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:

  • Local: Select the alias for your mobile VPN IP pool (usually SSLVPN-Users by default).
  • Remote: Select the alias for your branch office's local network.

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:

WatchGuard Tunnel Route configuration showing two local networks connected to one remote network.

Step 2: Grant Passage with a Firewall Policy

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:

  • From: SSLVPN-Users
  • To: Your branch office network alias (e.g., SiteB-Subnet)
  • Policy: Set to Allow.

Step 3: Disarm the NAT Trap (The Critical Step)

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.

Informing the Spoke (Branch Office Firewall Settings)

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.

Conclusion: Connecting the Bridges

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.


Top