Cisco IPSec VPN-client ports

by jimmy on 11 April, 2012 · 2 comments


“I cannot connect with my Cisco IPSec VPN-client when I am behind a firewall”

“I can connect my VPN-client but can´t get any traffic thru”

“I have changed the settings on the Transport-tab and now I don´t know which settings are correct”

 

Have you heard them all? I have, plenty of times! In fact, IPSec can be really messy to get to work, because when it was invented there was no such thing as NAT devices and IPSec doesn´t play very well with address translations. There are workarounds. Alot of them. And that´s why it is a bit messy.

 

Client settings

 

In the client there are settings under the transport tab tha changes how the client communicates with the head end. Unfortunately, these settings are not protected which means that the end use can (and will!) changes these settings. So, what does the different settings mean?

 

Enable Transparent Tunneling: No

This mode is the vanilla way of IPSec by the book. The tunnel is setup by using ISAKMP (udp/500) and the actual data is sent as ESP (ip/50).

Because of the way ESP works it doesn´t work well if the client is behind a firewall or other NAT device. If outbound ISAKMP is allowed, the client can connect and authenticate. But the ESP-data will never get thru and the user will experience that the tunnel is broken even if he was able to login.

 

Enable Transparent Tunneling over UDP

 This is the most common way to overcome the limitations of ESP. The tunnel setup is still being done over ISAKMP (udp/500) but the actual data is encapsulated in udp-packets (udp/4500).

For this to work, the head end must be configured with ‘crypto isakmp nat-traversal‘. This command will cause the head end to tell the client during tunnel setup to send data over udp/4500 instead of ESP. Without this configured in the head end, the client will experience the same thing as when Transparent tunneling is disabled (see above) because it will still use ESP for data-transfer unless told otherwise by the head end.

 

Enable Transparent Tunneling over TCP

This setting is rarely being used. It was invented in the Cisco VPN3000 concentrator and is also supported in pix/ASA. By tunneling traffic over a TCP/port both the tunnel setup and the actual data is sent over that port. That means that ISAKMP (udp/500) is not being used when doing IPSec over TCP. The default port (and most common) is tcp/10000 but any port will do good. But, the port must be specified in the head end with the ‘crypto isakmp ipsec-over-tcp port 10000′ command.

 

 

Answers

 

So, what are the answers for the end user questions on top of this post? I would say:

Q: “I cannot connect with my Cisco IPSec VPN-client when I am behind a firewall”

A: Make sure that the firewall administrator at the current location makes sures that the following ports are opened outbound:

  • udp/500 (ISAKMP)
  • udp/4500 (IPSec nat-traversal)
  • udp/10000 (IPSec over TCP)

 

Q: “I can connect my VPN-client but can´t get any traffic thru”

A: Enable transport tunneling over UDP in the Transport-tab and try again. If you can still connect but not communicate, make sure that the firewall administrator (at the site to which you are trying to connect!) enables nat-traversal with the ‘crypto isakmp nat-traversal’-command.

 

Q: “I have changed the settings on the Transport-tab and now I don´t know which settings are correct”

A: Duh! How would I know? :-) Ask your firewall administrator or IT helpdesk. If you still has a copy of the original .pcf-file, try to delete your current profile in the vpn-client and import the .pcf-file again.

 

My recommendations

Since there are a number of ways to configure the VPN client and the central firewall, which one should we use? Which one gives us least headache? I would say that you should choose from the below, in given order:

 

  1. Don´t. :-) Use AnyConnect instead of the old IPSec-client. There are zillions of reasons why, but they doesn´t fit into this blog post. Anyway. Migrate to AnyConnect if possible!
  2. Use Transparent Tunneling over UDP. Make sure that the central firewall is configured with NAT-traversal as explained above.
  3. Use Transparent Tunneling over TCP. But don´t. There is an extra overhead in encapsulating the end user traffic in yet another layer of TCP-sessions. UDP is better. But if you want to use TCP, use port 10000 because it is already entered by default in the vpn client.
  4. Use the client without transparent tunneling. You use GRE and will never get the client to work from behind a firewall. :-)

 

 

 

 

 

{ 2 comments }

New product: Cisco ASA CX

February 29, 2012

Yesterday at the RSA Conference Cisco released a new product named ASA CX. As usual when Cisco releases information about new products you have to dig alot to see thru all marketing material and find technical details. And so is defenately the case here also.   There are a few videos recentely uploaded to Youtube [...]

Read the full article →

Basic ASA Lan2Lan VPN Example

February 27, 2012

Or – ASA Lan2Lan-VPN for dummies.   I often get questions related to Lan2Lan-tunnels in ASA. This post serves as a cheat-sheet for different software versions. Pix v6.x   isakmp enable outside isakmp policy 1 authentication pre-share isakmp policy 1 encryption des isakmp policy 1 hash md5 isakmp policy 1 group 1 isakmp policy 1 [...]

Read the full article →

Cisco ISE Profiler in action

February 20, 2012

I am a huge fan of Cisco ISE and Trustsec. I have done a few live implementations as well as at home (anyone should run Trustsec at home! ). There will probably be a lot of ISE-related posts here in the near future.   Here I just want to reflect on how well the built-in [...]

Read the full article →

Cisco Live 2012 in London – short resume of my sessions

February 10, 2012

I just returned home after spending almost a week in London attendingCisco Live. Much can be said about the event and many has already summarized their experience, so the plan for this blog post is to make a short resumé of the sessions I attended to. Many were great, most were good but a few [...]

Read the full article →

Quick note: Inactive Anyconnect sessions not removed.

February 6, 2012

I recently had a TAC-case regarding a Cisco ASA 5510-firewall with Anyconnect-clients which had issues with VPN-clients not being able to connect due to “no address available”. It turned out that the “show vpn-sessiondb anyconnect”-command showed 50+ anyconnect-sessions that were over one month old! Like this:   sh vpn-sessiondb anyconnect Session Type: AnyConnect Username : [...]

Read the full article →

Cisco Ironport WSA – what happened?

January 30, 2012

I have recently implemented a few Cisco Ironport WSA-solutions. When doing a follow-up after the implementation, the customer usually reacts with “Oh… WSA? We forgot about that. It probably works…” But what difference does it make? If the customer forgets about their web proxy, what good does it do? Lets have a look at an [...]

Read the full article →

How to play case status table-tennis with Cisco TAC

January 26, 2012

The problem have you ever had an open TAC case with Cisco, just waiting for them to provide either a solution or some other kind of feedback, and all that happens is that the TAC engineer sends you an email telling you that they “have work in progress” or something else not-making-the-case-evolve? If so, I [...]

Read the full article →

Happy new year – Again! :-)

January 24, 2012

When purging and cleaning ancient posts I found this post where I wished everyone a Happy New 2011. And I felt that it was time for an update.   So, what happened during 2011 – did I become a Cisco CCIE Security? The short answer is: No.   In february 2011 my written CCIE Security exam [...]

Read the full article →

RSS-feeds with partial content sucks!

January 22, 2012

I am fan of RSS readers. I use Google Reader all the time to keep track of interresting blog and news sites. Actually, i rarely visit blog sites direct, just from my RSS reader. And I love it.   But there are a few really good blogs that are configured not to post the full [...]

Read the full article →