Configure ASA5510 to allow "outbound" VPN connections

Hi Bob,

You may wish to investigate the online Cisco Configuring ASA VPN Quick Learning Modules :

Hope this helps.

Brad Reese BradReese.Com - Global Cisco Systems Pre-Sales Support

Hendersonville Road, Suite 17 Asheville, North Carolina USA 28803 USA & Canada: 877-549-2680 International: 828-277-7272 Fax: 775-254-3558 AIM: R2MGrant Website:

Brad,

Thanks ! - It certainly will help us for several things.

I am still interested in hearing from others that have specific knowledge with complex configurations and VPN tunnels. We spoke with a Cisco engineer about the desired configuration and he left us feeling that NAT-Traversal was our ONLY option, because of the "PAT overload ?"....

The site you shared is filled with "lots" of information !!

Bob

Bob,

You may wish to Email directly Cisco ASA 5510 Expert:

Mr. Mynul Hoda, Dual CCIE No. 9159, Security / Routing & Switching as well as a CISSP.

Email Address:

mhoda at cisco.com

Mr. Hoda is the author of the Cisco Press book - Cisco Network Security Troubleshooting Handbook:

Furthermore, you may find useful Mr. Hoda's Online Archive of Configuration and Troubleshooting Adaptive Security Appliances (ASA)

5500 and PIX 7.0

June 30th, 2006:

January 27th, 2006:

as well as Cisco CCIE, Mr. Glenn Fullager's onlive archive of Troubleshooting PIX/ASA Firewalls,

March 10th, 2006:

Glenn's Email Address:

gfullage at cisco.com

and Omar Santos online archive of Deploying Cisco Adaptive Security Appliances (ASA).

December 22, 2005

Omar's Email Address:

osantos at cisco.com

Sincerely,

Brad Reese Cisco Technical Forums

Brad,

Thanks again !!

I will *absolutely* send the email.

We appreciate your response.

Bob

cannot help with this bit.

i think it is the other way - if you are doing address translation on the ASA, then IPsec is not going to work (or at least the authentication part) - the reason is that the encryption includes the end point addresses, and NAT is going to change that (unless you are set to translate an address to the same address?)

So - UDP or TCP encap is going to be needed to allow the VPN3000 to "talk" to end points where the VPN client sessions cross an address translation point.

Given typical remote access VPN use with many users operating from corporates, or from home where address translation is part of the network border - you probably need it for most applications these days.

FWIW UDP encap works best with reasonably good connectivity, and high speed links (eg a home broadband connection). TCP is OK where the firewall blocks UDP, doesnt keep session state for some reason, or where you have a poor connection (classic example for me is across a GPRS link). But TCP can cause a lot of slowdown, since the TCP session will back off under packet loss, affecting all traffic for that VPN link.

You just -might- be able to use IPSec over TCP,

The 3000 supports clients connecting over TCP 10000. I do not know if that is enabled by default. If it is not, then I suspect you would have as much policy problems getting it enabled as you face for getting NAT-T enabled.

Note that Cisco documents this as being for "client to security appliciance only" and that "It does not work for LAN-to-LAN connections". I'm not entirely certain what they mean by that, particularily as they mention the 3002.

The manual section above that, on limitations of NAT-T, is also informative about issues that could occur with IPSec over TCP (or UDP).

Having to send everything out over the same IP address is a problem, as IPSec and PPTP both naturally use protocols (AH and ESP; GRE) that do not have "ports" that can be NAT'd. If you cannot encapsulate at some level (in the ASA, or in the clients running "behind" the ASA) then you have a fundamental communications problem.

You were both correct. Encapsulation is required and we were able to work with the network folks to enable (support) it on their end.

I believe there official resolution was that they enabled port 4500 for UDP.

Thanks for the help !

You were both correct. Encapsulation is required and we were able to work with the network folks to enable (support) it on their end.

I believe there official resolution was that they enabled port 4500 for UDP.

Thanks for the help !