Earlier this week I was having a look at an ISA (2004) to Cisco ASA (or PIX) IPSEC VPN connection. Their appeared to be some routing issues going on as the internal subnet was able to connect fine across the VPN but the ISA itself was unable to communicate across the tunnel. There are lots of documents that talk about correctly setting up IPSEC VPN’s between two ISA servers, or ones that include Cisco devices but none that cover how you need to correctly configure it to allow the ISA to route to the VPN subnet as well.
Part of the issue with IPSEC VPN’s is they do not create a “virtual network adaptor” on the host system so its quite common to experience routing issues. When traffic is destined for the remote network it is wrapped up in an IPSEC layer & then sent out of the external interface. At the other end the wrapper is removed & the traffic is passed to the remote network.
Due to the way that IPSEC VPN’s work traffic from the ISA server itself will not appear as originating from the “internal” subnet but will appear to come from the external IP of the ISA. This means when the traffic arrives at the other end it is decrypted by the ASA and then dropped as it does not come from a valid network range.
This can cause all sorts of issues including upsetting HTTP access (as the ISA tries to proxy the connection from clients in Subnet A to Subnet B) resulting in “connection timed out” errors. Also if you have a NAT relationship between your local network and the VPN subnet then this would prevent any traffic from passing across the tunnel correctly
I will assume for this article that you have already configured the VPN and have successfully been able to connect so that traffic can pass from clients at either end of the VPN tunnel. If not there are plenty of good articles out there, including some on Technet
Note that I have obfuscated large parts of the screen prints and changed IP’s so as not to give away anything potentially sensitive!
My configuration was as follows:
If you are configuring an ISA to ISA VPN to allow both ISA’s to route traffic correctly from themselves you need to make sure you include the address for the remote server in the “address” portion of the VPN network (ISA even reminds you of this “to allow HTTP proxy or NAT traffic between sites, this network must include the remote site gateway IP address.”) . So in my case that would mean taking the value listed in the “Remote Server” column (blanked out) and adding it the address range dialogue:
After applying that change Subnet A computers could still ping Subnet B machines but ISA could not ping Subnet B
This is because you need to make the equivalent change on the ASA…
First you need to find the correct external IP on the ISA that you need to add into the ASA. From a command line run “netsh ipsec dynamic show qmfilter all”. Search down the list and find the IPSEC tunnel that has the “source address” listed that matches your “remote server”. Make a note of the IP listed in the “Destination Address”, this should be an address on the external interface of the ISA.
(195.195.195.195 shown here as the source IP is the public IP of the remote gateway)
In my example here that would be 10.10.10.10. This IP is normally the primary external IP on the ISA server unless you have configures specific static routes to use alternative paths.
Log into the Cisco device and add an extra entry into the existing VPN Crypto Map. You need to make sure that the IP you collected above is added in as a “protected” IP.
Next create a NAT exception for the same IP address:
Then make sure you apply the settings (don’t save until your happy!), break the VPN connection to ensure it gets re-established according to the new settings and then hopefully your ISA will have connectivity to the remote subnet!
I have tested this with ISA 2004 & 2006 connecting to an ASA but see no reason why the same fix should not also apply for Cisco PIX devices (with ISA 2006 i have seen the ping just report a continuous “Negotiating IP Security” rather than timing out).
Thanks to Ian as well for his help with the Cisco side of the troubleshooting!
