Routing and gateway considerations

When the VPN endpoint, in this case a AZTCO-FW firewall, is the default gateway for a network there are normally no problems with routing. As a client PC sends traffic, it will go to the AZTCO-FW firewall, over the tunnel, and out the other end. However, if the AZTCO-FW 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 AZTCO-FW firewall is the gateway at Site B, but not Site A, as illustrated in Figure 55: Site-to-Site IPsec Where AZTCO-FW is not the Gateway. A client, PC1 at Site B sends a ping to PC2 at Site A. The packet leaves PC1, then through the AZTCO-FW firewall at Site B, across the tunnel, out the AZTCO-FW firewall at Site A, and on to PC2. But what happens on the way back? The gateway on PC2 is another 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 AZTCO-FW firewall. Even with this route, additional complexities are introduced because this scenario results in asymmetric routing .
• A static route could be added to the client systems individually so that they know to send that traffic directly to the AZTCO-FW firewall 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 AZTCO-FW firewall the gateway and let it handle the Internet connection instead of the existing gateway.