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.

 

Table of Content

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

1.1 Policy routes - HQ Firewall

1.2 Policy Routes - Site A Firewall

1.3 Policy Routes - Site B Firewall

2) Verification / Troubleshooting

2.1 Test by Pinging the firewall

2.1.1 Policy Routes - Site B Firewall

2.1.2 Policy Routes - Site A Firewall

2.2 Test by Pinging a server / PC

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

3.1 Configure SecuExtender IPSec VPN

3.2 Configure Firewall Routing

3.2.1 On Site A Firewall

3.2.2 On Site B Firewall

 

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.1.1 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.1.2 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.2 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.

 

 

 

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

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

 

 

 

3.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

 

 

3.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

 

 

3.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:

 

 

3.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 +++