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. This is illustrated in Figure Site-to-Site IPsec Where the VPN Endpoint is not the Gateway. The device PC1 at Site B sends a ping to PC2 at Site A. The packet leaves PC1, travels through the firewall at Site B, traverses the tunnel, exits the firewall at Site A, and on to PC2. 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. The best practice depends on the circumstances of a given use 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.
Make the VPN endpoint the default gateway and let it handle the Internet connection instead of the existing gateway.

In some situations this is easier than attempting to setup complicated routing, but it may not be acceptable to network administrators or management.