VPN - Routing traffic from VPN tunnel to another VPN site [VPN Routing]

This article explains how to route traffic from a site-to-site tunnel into another tunnel to reach devices behind a site-to-site connection. It explains how to route traffic from site A to Site B through HQ firewall / gateway (route site-to-site through site-to-site tunnel), troubleshoot issues/problems, routing rules if you want your client VPNs to reach a server that's located on another Site (client-to-site through site-to-site), SecuExtender IPSec configuration.

 

 

Alternative 1: Routing traffic from Remote VPN tunnel to another site-to-site VPN

 

1) Setting Up VPN Tunnels

Prerequisite: A site-to-site connection between the locations must already be established.

Once the tunnel is established, we will connect it using L2TP over IPSec.

For instructions on how to set up a VPN, please refer to:

VPN - Configure IPSec Site-To-Site VPN

You can find information about L2TP over IPSec:

VPN - Configure L2TP over IPSec VPN using PSK [Stand-alone mode]

To simplify the process, you can use the wizard for creating a VPN tunnel and L2TP over IPSec.

 

2) Configuring Routing Policies

To allow traffic between the main headquarters (HQ) and Site B, you need to set up policies and routes for the VPN tunnel.

On the HQ Firewall:

1. Create a policy route that routes incoming requests from the the L2TP tunnel into the Site B tunnel. This is routing incoming requests from the L2TP tunnel through HQ Firewall into the Site B tunnel

   • Source: L2TP client subnet
   • Destination: Site B subnet
   • Next-hop: VPN Tunnel "Site B tunnel"

Note that the Destination Address is our client's address.

 

2. Create a policy that allows responses from Site B and routes them into the tunnel to Site B. This is crucial for the traffic returning from Site B to HQ.

• • Source: Any
  • Destination: L2TP Tunnel
  • Next-hop: VPN Tunnel "L2TP Tunnel"

 

On Site B:

1. Also, create a policy route that allows incoming requests from HQ and forwards them into the tunnel to Site B. So create a policy route that allows responses from HQ and routes them into the tunnel to Site B:

Ensure that Asymmetric Routing is enabled for seamless connectivity. You can find this option here: 

Configuration > Security Policy > Policy Control

Enabling this feature activates the "triangular" route, allowing the firewall to use an asymmetric route topology in the network and preventing connection resets when responses come back.

 

By following these steps, you can effectively route traffic between your VPN tunnels and maintain a smooth and secure connection between HQ and Site B.

 

Alternative 2: Routing from VPN tunnel to another VPN site

 

1) Route traffic from Site A to Site B Through HQ Site

 

If you want Site A to reach Site B and vice versa, you need to create policy routes on each firewall to let HQ firewall know where to send the requests coming in, and where to send the responses as well. 

 

1.1 Policy routes - HQ Firewall

On HQ firewall, you need to first configure a rule that allows requests coming from Site A that's going to Site B. Those needs to be routed in the tunnel to Site B, and this is important both for ICMP requests (coming from Site A), but also for ICMP replies (coming from Site B and now are going back to Site B again).

Incoming: any - Source: "Site A subnet" -> Destination: "Site B subnet" - Next-hop Tunnel - "Site B VPN tunnel" 

 

Secondly, you need to configure a rule that allows replies coming from Site B that's going to Site A (when you have sent a request from Site A) and those needs to be routed into the Site A tunnel. This is important both for ICMP requests (coming from Site B), but also for ICMP replies (coming from Site B and now are going back to Site A again).

Incoming: any - Source: "Site B subnet" -> Destination: "Site A subnet" - Next-hop Tunnel - "Site A VPN tunnel" 

 

1.2 Policy Routes - Site A Firewall

Then, you need to configure a rule that allows requests coming from Site B that's going to Site A (when you have sent a request from Site B). Those needs to be routed "back" into the Site A tunnel, and this is important both for ICMP requests (coming from Site B), but also for ICMP replies (coming from Site B and now are going back to Site B again).

Incoming: any - Source: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel" 

 

1.3 Policy Routes - Site B Firewall

Then, you need to configure a rule that allows requests coming from Site A that's going to Site B (when you have sent a request from Site A). Those needs to be routed "back" into the Site B tunnel, and this is important both for ICMP requests (coming from Site A), but also for ICMP replies (coming from Site A and now are going back to Site A again).

Incoming: any - Source: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel" 

 

2) Verification / Troubleshooting

When you have configured all the policy routes, it's important to verify that the routing is actually working. Maybe you have conflicting routes in your firewall rules (subnet overlaps, existing policy/static routes etc.) or there is something else wrong. 

 

Note that this can be very confusing as there are many routes that you need to take care of. The easiest way to do this is to manually map out all the packet flows on a paper (PC -> Gateway A - gateway needs to route to HQ, HQ needs to route to Site B - Site B needs to route the reply back to HQ again ... etc.), ask yourself - "who is responsible for routing, and is the routing in place?".

 

Down below you will find two scenarios where you might need to change configurations for the routing to work.

 

2.1 Test by Pinging the firewall

The first is testing by pinging from a PC to Site A to a server or PC on Site B:

Red Arrow - ICMP [ping] Request

Green Arrow - ICMP [ping] Reply

 

2.2 Policy Routes - Site B Firewall

The first test that you can do is to ping the firewall, however, because the routing that you now have created is ONLY for Incoming any (Excluding Zywall), it means that the routing will not apply if the ping comes from Site A, reaches Site B Firewall and then the Firewall is responsible for responding to that request. The ICMP response will then look like this:

ICMP Request

PC (ICMP Request) -> Site A Gateway -> VPN tunnel to HQ -> HQ Gateway sends traffic to Site B Gateway

ICMP Reply

Site B Gateway (ICMP Reply) -> Site B Gateway -> VPN tunnel to HQ -> HQ Gateway Sends traffic to Site A Gateway -> Site A Gateway sends packets back to PC 

 

Therefore, this policy route is needed:

Incoming: ZyWall- Source: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel" 

 

2.3 Policy Routes - Site A Firewall

If you're pinging the Site B Gateway from the Site A Gateway (built-in ICMP tool), the policy routing on Site A will not apply for the responses back from the Site B, if Site B is trying to ping Site A Gateway.

 

Therefore, we need a policy route that looks like this:

Incoming: ZyWall- Source: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel" 

 

2.4 Test by Pinging a server / PC

Because the PC is located on the 192.168.20.0/24 network, and the Server is located on 192.168.30.0/24 network, the server doesn't recognize the 192.168.20.0/24 network and therefore the server will very likely block ICMP packets coming from unknown subnets. Therefore, when performing tests, always:

• Disable any built-in firewall (e.g. Windows Defender / Firewall)
• Disable other anti-virus and end-point security softwares installed on the server / PC.

 

 

 

Route Client-to-Site Traffic through a Site-to-Site Tunnel

Attention: This didn´t work with Dynamic VPN! Please select only Site2Site VPN!

 

 

 

1) Configure SecuExtender IPSec VPN

In order to route IPSec VPN clients into another tunnel, they need to use fixed IP addresses.

If it is required to route many different clients it is recommended to use IPs that are close to each other so a range can be created. This reduces the number of necessary routes.

The subnet in which the IP addresses are located does not have to be present on the firewall.

 

 

Enter the fixed IP address on the IPSec VPN Client

 

 

2) Configure Firewall Routing

 

On the firewall, navigate to

Configuration > Object > Address

and click on

Add

 to create the range for the IPSec VPN Client IP addresses.

 

 Now we can add the necessary routes under

Configuration > Network > Routing

 with a click on the

Add

 

 

2.1 On Site A Firewall

We need to create two routes:

• One for the outgoing traffic, so from the dynamic VPN-client tunnel to the remote subnet over the site-to-site tunnel.

 

 

• One for the incoming traffic, so from the remote subnet over the site-to-site tunnel into the VPN-client tunnel.

 

The new routes should look similar to this:

 

Another way for the incoming traffic from the remote subnet over the remote VPN tunnel to pass, you can enable "asymmetric route": 

This will enable the "triangle" route which makes the firewall permit the use of asymmetrical route topology in the network and not reset the connection when the response comes back.

 

2.2 On Site B Firewall

On the remote site, it might be necessary to have similar routes created so the device on the main site knows how to handle the traffic from the VPN-clients coming from the branch site.

 

On the HQ site, we create the IP-range for the remote VPN clients so we can use it to route the traffic.

 

 

Now we create the corresponding routes on the HQ site as well. 

One outgoing route, so from the HQ subnet over the site-to-site tunnel to the remote VPN-clients.

 

 

And one incoming route, so from the remote VPN-client range over the site-to-site tunnel into the local LAN of HQ. If traffic is routed into a local subnet we select "Auto" as next-hop, the USG manages this automatically.

 

The routes should look something like this:

 

 

+++ You can buy licenses for your Zyxel VPN clients (SSL VPN, IPsec) with immediate delivery by 1-click: Zyxel Webstore +++