2

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?

Improve this question
4
  • 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, 2012 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, 2012 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, 2012 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, 2012 at 11:48

2 Answers 2

Reset to default
2

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?

Improve this answer
3
  • I have "crypto isakmp nat-traversal 30". Is the additional 10 seconds between keepalives going to make a difference.
    – Alain O'Dea
    Jun 21, 2012 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, 2012 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, 2012 at 11:51
1

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
Improve this answer
3
  • 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, 2012 at 12:26
  • 1
    Could you accept this as an answer so others can be sure to find your solution?
    – Mike Pennington
    Jul 1, 2012 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, 2012 at 18:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .