We've had issues with our Exchange 2010 server (running on ESXi 4.1) since its default gateway was changed to our new ASA 5510. They manifested as frequent Outlook client connection dropouts or as IP address conflicts whenever Exchange was rebooted. The temporary fix was to disable the Exchange server NIC, bounce the ASA and enable the server's NIC again. We saw poor performance from Exchange after a while again, but after some research and testing I realised that disabling proxyarp on the inside interface fixed the problem permanently.
However I've now realised that the client VPN no longer routes properly because proxyarp is disabled on the inside interface, so I still have a problem.
Can anyone think of a way to stop the ASA grabbing hold of the Exchange server's IP address, but allow the VPN traffic to come in on the inside interface?
Solved! Go to Solution.
Hi Craig, I don't believe so. The VPN pool was functioning perfectly right up till I disabled proxyarp.
Here's the edited config. Basically the Exchange server has a NAT rule to allow http/https/smtp, which is how the ARP issue arose. Would the ARPRetryCount command be any use, if I enable proxyarp again?
: Written by enable_15 at 11:01:37.416 UTC Tue Apr 3 2012
ASA Version 8.2(5)
enable password xxxxxxxxxxxxxxxx encrypted
passwd xxxxxxxxxxxxxxxx encrypted
name 10.48.254.0 vpnclients-network
name 10.48.1.3 srvex01-internal
ip address 10.48.1.254 255.255.0.0
no ip address
no ip address
no ip address
ftp mode passive
object-group service DM_INLINE_TCP_1 tcp
port-object eq www
port-object eq https
port-object eq smtp
access-list inside_nat0_outbound extended permit ip any vpnclients-network 255.255.255.192
access-list outside_access_in extended permit tcp any host srvex01-external object-group DM_INLINE_TCP_1
pager lines 24
logging asdm informational
mtu outside 1500
mtu inside 1500
mtu management 1500
ip local pool vpnclients 10.48.254.1-10.48.254.32 mask 255.255.0.0
icmp unreachable rate-limit 1 burst-size 1
icmp deny any outside
no asdm history enable
arp timeout 14400
global (outside) 101 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 101 0.0.0.0 0.0.0.0
static (inside,outside) srvex01-external srvex01-internal netmask 255.255.255.255
static (outside,inside) srvex01-internal srvex01-external netmask 255.255.255.255
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
http server enable
http 10.48.0.0 255.255.0.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
sysopt noproxyarp inside
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection statistics access-list
threat-detection statistics tcp-intercept rate-interval 30 burst-rate 400 average-rate 200
ntp server 10.48.1.2 source inside
group-policy DfltGrpPolicy attributes
banner value ** Warning: you are connecting to the
banner value This connection is for authorised users only. If you are not authorised to use this connection you should disconnect immediately. For acceptable use guidelines please refer to the Company IT Policy (HR 062).
group-policy clientvpn internal
group-policy clientvpn attributes
dns-server value 10.48.1.2
tunnel-group clientvpn type remote-access
tunnel-group clientvpn general-attributes
tunnel-group clientvpn ipsec-attributes
policy-map type inspect dns preset_dns_map
message-length maximum client auto
message-length maximum 512
inspect dns preset_dns_map
inspect h323 h225
inspect h323 ras
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
Looking at your configuration the inside network has a class B so the VPN clients are assigned address that overlap with the assigned addresses.
Please see the following.
If you are unable to access the internal network after the tunnel establishment, check the IP address assigned to the VPN client that overlaps with the internal network behind the head-end device.
Always make sure that the IP addresses in the pool to be assigned for the VPN clients, the internal network of the head-end device and the VPN Client internal network must be in different networks. You can assign the same major network with different subnets, but sometimes the routing issues occur.
Thanks Craig, so perhaps the VPN only worked correctly beforehand was because the proxyarp was making up the shortfall? Would you suggest a completely different subnet?
That sounds correct, yeah I would use a different subnet (not used anywhere in the network).
Thanks Craig, I think you're right as I've found another thread with a similar issue to mine and the same answer -
I tried changing the vpnclients subnet to something completely different and it really upset one of our older switches on the LAN and caused chaos!
The business is really busy this weekend with easter, so I'll wait till next week before trying this again and cycling the old switch afterwards if need be.
Thanks Craig you were spot on. I also had to go into Routing and Remote Access on our old ISA server (the LAN's current default gateway) and create a static route for the VPN traffic before I could close out the issue.