Saturday, June 7, 2008

A packet's trip back

Should you find yourself setting up Remote Access VPN for a Cisco PIX firewall (or any Cisco IOS based device) you may find it helpful to keep in mind something that kept me stymied for a few hours.  Packets have to be able to make the trip back.  So if you've got a NAT rule translating all outbound packets so that they look like they're coming from your external IP then packets sent from the dial-up/vpn network wont be able to make the return trip.

 

In this setup, like most SOHO setups I imagine, the remote access VPN network is setup on the outside interface.  That's so that people can access it via their ISP.  Although TCP provides the illusion of a single connection, it's still based on packet switching which means that what you've really got are packets going in 2 directions.  Something like:

 

Source to dest is: Remote ISP -> VPN Server at outside interface -> pix firewall -> internal network on inside interface.

Dest to Source SHOULD be: internal network on inside interface -> pix firewall -> outside interface -> remote ISP

 

but with NAT in place, the trip through the firewall changes the packets to make them look like they're coming from the outside interface's external IP.  Since the remote ISP is waiting for packets from the internal network, it ignores packets that look like they're from the oustide interface's external IP.

 

The solution is to exempt outbound packets going to the vpn group from translation.

 

The other part of the solution is to allow packets from the vpn network (which is on the outside interface, a lower security interface) into the internal network.

No comments :

Post a Comment