Allow Cisco VPN Client through firewall?

Answered Question
May 6th, 2008

Hi,

How can I allow a cisco VPN client to work from inside our network to an outside IP?

We have clients wishing to use their companies Cisco VPN Client but our ASA is blocking it I think?

Also (sorry to ask) a friend in South America is having the same problem but I don't hink they use Cisco, is there a default port that the Cisco client uses? then I can email them this info?

Thanks

I have this problem too.
0 votes

Generally the ASA will allow IPSEC traffic from inside to the outside. it;s when you want it to originate from outside and to connect to you - that's where it gets creative. Are you limiting outbound traffic at all??? Are you denying any ip/tcp/udp outbound?

But can depend on if the remote end is NAT-T compaitable, and if they have that configured. Another issue could be how they allow VPN traffic to enter?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Correct Answer

Generally the ASA will allow IPSEC traffic from inside to the outside. it;s when you want it to originate from outside and to connect to you - that's where it gets creative. Are you limiting outbound traffic at all??? Are you denying any ip/tcp/udp outbound?

But can depend on if the remote end is NAT-T compaitable, and if they have that configured. Another issue could be how they allow VPN traffic to enter?

whiteford Tue, 05/06/2008 - 01:57

Think their Cisco Client is using IPSec over UDP, and at the other other end I don't think it allows NAT-T.

Does that mean I have to open port 500 or something?

Thing is they don't even get a username and password box pop up, I don't think I have an appropiate rule set up, will I have to do a static nat for the traffic heading back?

You will have to check with them to see if they are using NAT-T - what manufactorer is the remote device - Cisco?

You should not have to open any ports, the client and the remote end should negotiate - if their profile is not already pre-configured. Is the client configured to use "transparent tunneling"? if so is it UDP or TCP?

Do they get any errors, like "remote peer not repsonding" etc?? Have you tried enabling the logging on the client and starting a VPN to see what the client reports??

I have just logged a VPN client sucessful connection:-

1 11:13:00.983 05/06/08 Sev=Info/6 IKE/0x6300003B

Attempting to establish a connection with x.x.x.x

2 11:13:00.999 05/06/08 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Frag), VID(Nat-T), VID(Unity)) to x.x.x.x

3 11:13:01.014 05/06/08 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = x.x.x.x

4 11:13:01.014 05/06/08 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID(Unity), VID(Xauth), VID(dpd), VID(Nat-T), NAT-D, NAT-D, VID(Frag), VID(?)) from x.x.x.x

5 11:13:01.014 05/06/08 Sev=Info/5 IKE/0x63000001

Peer is a Cisco-Unity compliant peer

6 11:13:01.014 05/06/08 Sev=Info/5 IKE/0x63000001

Peer supports XAUTH

7 11:13:01.014 05/06/08 Sev=Info/5 IKE/0x63000001

Peer supports DPD

8 11:13:01.014 05/06/08 Sev=Info/5 IKE/0x63000001

Peer supports NAT-T

9 11:13:01.014 05/06/08 Sev=Info/5 IKE/0x63000001

Peer supports IKE fragmentation payloads

10 11:13:01.014 05/06/08 Sev=Info/6 IKE/0x63000001

IOS Vendor ID Contruction successful

11 11:13:01.014 05/06/08 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NAT-D, NAT-D, VID(?), VID(Unity)) to x.x.x.x

12 11:13:01.014 05/06/08 Sev=Info/6 IKE/0x63000055

Sent a keepalive on the IPSec SA

13 11:13:01.014 05/06/08 Sev=Info/4 IKE/0x63000083

IKE Port in use - Local Port = 0x06D0, Remote Port = 0x1194

14 11:13:01.014 05/06/08 Sev=Info/5 IKE/0x63000072

Automatic NAT Detection Status:

Remote end is NOT behind a NAT device

This end IS behind a NAT device

The above is what you want to see

whiteford Tue, 05/06/2008 - 02:31

Their setting under transport says IPSec over UDP not TCP. I will check their VPN device, should I just get them to turn on NAT-T if not enabled?

whiteford Tue, 05/06/2008 - 02:40

Would UDP encapsulaton of the IPSEC be a rule or under somethin else?

Also what logging level to you have to change to get that log output?

Many thanks

The remote deivce would need to be configured for NAT-T - generally UDP, but you can force it to be TCP. The RFC standard is for UDP and the normal NAT-T port is 4500, this is all negotiated in phase 1 - IKE. You can configure most VPN devices that support NAT-T. What is the remote VPN concentrator make/model?

The settings I use for the best troubleshooting information on the client is attached.

HTH.

Attachment: 
whiteford Tue, 05/06/2008 - 02:54

Just found out it's an ASA too, upgraded from the end of life Concentrator (sad I love them). I guess all they need to do is enable NAT_T and that's it? Or on my ASA would I need to just open UDP 4500 outbound?

OK - in the profile configuration that the remote users are using there should be something like:-

ipsec-udp enable

ipsec-udp-port #(port number)

This is negotiated in IKE, once the client recevies this information, it will create an outbound connection to that port.

They should have a rule in a firewall to allow the udp/xx port to the VPN ASA, if the ASA sits behind a firewall - you should not have to open anything on your side....unless you are blocking from your inside to the outside?

whiteford Wed, 05/07/2008 - 07:01

Hi Andrew,

Have no update today as I'm off site, when I do I will sure let you know.

whiteford Thu, 05/08/2008 - 02:40

Hi Andrew,

Had to add this:

access-list inside_access_in extended permit udp host 192.168.66.77 host 1.2.3.4 eq 4500

1.2.3.4 = Outside address of ASA

whiteford Thu, 05/08/2008 - 02:52

I guess so too, so basically the the VPN client wasn't allowed outbound on UDP 4500?

No sorry - my previous post was incorrect, if the ASA was behind a firewall was one question

The other question was "Are you limiting outbound traffic at all??? Are you denying any ip/tcp/udp outbound?"

To have to input "access-list inside_access_in extended permit udp host 192.168.66.77 host 1.2.3.4 eq 4500 " bascially says you were limiting traffic from the inside to the outside.

Which it appears was the case - it's all good.

Actions

This Discussion