Routing wrt PIX site-to-site VPN

[Brian Sullivan]

First, please pardon my lack of expertise in this area. I've searched for similar solutions and haven't found much guidance.

I'm setting up a site to site VPN link between two PIX515 running 6.3(5) and I have some questions about routing. The layout is this:

10.30.29.0/24 -|Remote Pix515|- 216.xxx.xxx.19 ~~~~ Internet ~~~~ 96.xxx.xxx.101 -|HQ Pix515|- 10.30.20.0/24

The remote Pix serves as the gateway/NAT firewall for general internet traffic as well as the VPN endpoint. Its inside IP is 10.30.29.1. The Pix at HQ serves only as the site-to-site VPN endpoint . Its IP is 10.30.20.3. NAT is disabled on VPN traffic and all IPSEC traffic is permitted (by way of

"sysopt connection permit-ipsec").

The gateway for the HQ subnet is at 10.30.20.1.

I need machines on the remote side to be able to "see" shares at HQ. Machines on the remote side don't need to be visible to HQ.

It seems to me the remote PIX will correctly handle routing traffic bound for the HQ subnet through the tunnel using the crypto map/ACLs. And I suspect the HQ PIX will correctly handle traffic bound for the remote subnet if/when it receives such traffic on its inside interface for the same reason. But, I have to get packets leaving machines on the HQ subnet, that are bound for the remote subnet, to the HQ PIX's inside interface somehow, right?

My question: Is it sufficient to setup a static route on the HQ gateway  that routes packets bound for the remote subnet to the HQ PIX? Am I even asking the right question?

Thanks so much,

Brian

[Jouni Forss]

Hi,

If we are talking about just a simple setup of L2L VPN connecting 2 LAN networks and enabling traffic between them then you dont really need any route configurations on the PIX firewalls.

The L2L VPN rules already tell on each site that the other LAN network is located through the L2L VPN connection. And if the NAT0 configurations are correct and the ACL rules permit traffic then the traffic should flow just fine.

I am not sure if I understood the whole setup correctly though. You mention the Remote Site PIX is used for both Internet connectivity and VPN and the HQ Site PIX is used only for VPN. Do you mean that the HQ Site has a separate PIX acting as a VPN device only?

In that case you would need to tell the rest of the HQ network where to reach the Remote Site network. Since if the HQ Site PIX is only acting as a VPN device then the default route of your HQ Site network will probably not be pointing towards this PIX but some other firewall which holds the connection to the Internet.

- Jouni

[Brian Sullivan]

Hi Jouni,

Thanks for the information. You're correct, the PIX at HQ doesn't act as the firewall/gateway for that subnet. We have a Sonicwall device handling that. The HQ PIX acts only as an endpoint for the VPN to the remote site. Your comments seem to support what I was thinking about adding a static route on the sonicwall gateway to route traffic headed to the remote subnet to the HQ PIX.

I arrived at this configuartion due to stability problems with the sonicwall's VPN. I felt that a PIX-to-PIX VPN would be more reliable. However, I have some concerns about opening up another point of access to our HQ network, even though all non-VPN traffic is forbidden on the outside interface (various scans indicate it's locked down).