Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have configured a Remote Access VPN on my ASA5510 running 8.4 and enabled it on the outside interface.

For some reason if an inside host uses a VPN client to connect through the firewall they end up taking port udp/500 (udp/isakmp) or tcpudp/4500 (IPSec NAT-T).

Inside hosts use PAT to translate to the outside, but I would have thought the ASA would never provide PAT translations that override its own ports (like 500 and 4500).

I am seeing the packets drop during negotiation and authentication. If I disconnect the VPN client on the inside host the remote access clients can connect again.

Here is some of the config (scrubbed for obvious reasons):

access-list vpnclient_splitTunnelAcl standard permit 10.0.0.0 255.0.0.0
ip local pool vpnclient-pool 10.0.254.5-10.0.254.249 mask 255.255.255.0
group-policy remote_access internal
group-policy vpnclient attributes
 dns-server value 10.0.0.2
 vpn-tunnel-protocol ikev1
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value vpnclient_splitTunnelAcl
 default-domain value example.local
tunnel-group vpnclient type remote-access
tunnel-group vpnclient general-attributes
 address-pool vpnclient-pool
 authentication-server-group RADIUS
 default-group-policy vpnclient
tunnel-group vpnclient ipsec-attributes
 ikev1 pre-shared-key ***********
tunnel-group vpnclient ppp-attributes
 no authentication chap
 no authentication ms-chap-v1

How can I prevent inside hosts from taking ISAKMP and IPSec NAT-T ports on 8.4 ASA5510?

share|improve this question
1  
What do you mean by "taking" the ports? The system setting the source port of a PAT-translated connection to 500 or 4500 should have absolutely no bearing on whether or not the firewall is still listening and accepting communication on the VPN ports. Connections (and the tracked fake connections that are used for NATing the UDP) are identified by the IP and port of the node on both ends; the port is not committed to the PAT connection. What symptoms are you seeing? –  Shane Madden Jun 20 '12 at 18:40
    
I am seeing ACL Denies in the syslog for VPN hosts attempting to access the internal hosts that have those xlates. I agree, this is very odd. Technically those translations should be locked to based on the original destination IPs for the connections that caused the xlates to be created. –  Alain O'Dea Jun 20 '12 at 19:45
    
What are you seeing the packet drop for - tunnel traffic to 500 or 4500, or the traffic that should be encapsulated in the VPN? Can you provide the relevant logs and tunnel config? –  Shane Madden Jun 20 '12 at 19:48
    
I am seeing traffic drop for 500. Then after putting in a gruesome hack of adding a NAT for the outside IP to the outside interface on port 500 I see drops on 4500. Same hack works to fix those, but I don't like it at all. It seems like I have other things wrong for this to happen. –  Alain O'Dea Jun 21 '12 at 11:48

2 Answers 2

up vote 1 down vote accepted

A combination of IPSec Pass-through and a NAT hack resolves the issue with ports 500 and 4500 being 'stolen' by inside hosts for me:

configure terminal
 object network VPN-endpoint
  description Prevent inside hosts from stealing VPN endpoint with PAT
  host 172.16.0.1
  nat (any,outside) static interface service udp isakmp isakmp
  exit
 access-list ipsecpassthroughacl extended permit udp any any eq isakmp
 access-list ipsecpassthroughacl extended permit object-group TCPUDP any any eq 4500
 class-map ipsecpassthru-traffic
  match access-list ipsecpassthroughacl
  exit
 policy-map type inspect ipsec-pass-thru iptmap
  parameters
   esp
   ah
   exit
  exit
 policy-map inspection_policy
  class ipsecpassthru-traffic
   inspect ipsec-pass-thru iptmap
   exit
  exit
 service-policy inspection_policy interface outside
 exit
share|improve this answer
    
I am confused as to why this would work though since IPSec Pass-through apparently isn't supported with PAT. Anyone who can post an answer to this that explains this will get the points. I believe this is caused by a change in ASA 8.4 vs 8.2. This worked in 8.2 without the policy-map or NAT hack. –  Alain O'Dea Jun 26 '12 at 12:26
1  
Could you accept this as an answer so others can be sure to find your solution? –  Mike Pennington Jul 1 '12 at 19:54
    
Strictly speaking the fix is to upgrade to 8.4(4.1) since this is a bug, but this workaround avoids that in mission critical environments without failover. –  Alain O'Dea Jul 18 '12 at 18:54

Do you have crypto isakmp nat-traversal 20 enabled on the destination and source firewalls? This is a common issue, and bits of your story are consistent. There may be something else off in the config, though. Can you post the rest?

share|improve this answer
    
I have "crypto isakmp nat-traversal 30". Is the additional 10 seconds between keepalives going to make a difference. –  Alain O'Dea Jun 21 '12 at 17:46
    
It will take me a while to scrub the config, but I'll try to post it in the next couple of hours. Thank you for your help :) –  Alain O'Dea Jun 21 '12 at 17:50
    
I've been instructed not to post the config even if it is scrubbed. I'll have to go to TAC. I'll post the outcome later. –  Alain O'Dea Jun 22 '12 at 11:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.