Client Routing and Gateway Considerations

When the VPN endpoint is the default gateway for a network there are normally no problems with routing. When a client PC sends traffic it will go to its default gateway, over the tunnel, and out the other end. However, if the firewall is not the default gateway for a given network, then other routing measures will need to be taken.

As an example, imagine that the firewall is the gateway at Site B, but not Site A, as illustrated in Figure Site-to-Site IPsec Where the VPN Endpoint is not the Gateway. A device, PC1 at Site B, sends a ping to PC2 at Site A. The packet leaves PC1, travels through the firewall at Site B, across the tunnel, out the firewall at Site A, and on to PC2. But what happens on the way back? The gateway on PC2 is a different router entirely. The reply to the ping will be sent to the gateway router and most likely be tossed out, or even worse, it may be sent out the Internet link and be lost that way.

There are several ways around this problem, and any one may be better depending on the circumstances of a given case.

  • A static route could be entered into the gateway router that will redirect traffic destined for the far side of the tunnel to the VPN endpoint. Even with this route, additional complexities are introduced because this scenario results in asymmetric routing as covered in Bypass Firewall Rules for Traffic on Same Interface.

  • A static route could be added to the client systems individually so that they know to send that traffic directly to the VPN endpoint and not via their default gateway. Unless there are only a very small number of hosts that need to access the VPN, this is a management headache and should be avoided.

  • In some situations it may be easier to make the VPN endpoint the gateway and let it handle the Internet connection instead of the existing gateway.


Site-to-Site IPsec Where the VPN Endpoint is not the Gateway