Can I split Cisco ASA outside interface, that has public IP address, for site-to-site VPN, aceess to Internet…from that site-to-site tunnel, and client-ASA VPN connection?
Vpn – Splitting Cisco ASA interface for traffic
cisco-asasplit-tunnelingvpn
Related Solutions
You do have asymmetrical routing, but that shouldn't be the issue. Instead, I suspect the issue is link delay involving your 3G link. Since IPSec IKE uses UDP/500 or UDP/4500 with NAT-Traversal, there's no guarantee of packet delivery. Your VPN client -- the IKE initiator -- sends the first IKE message and is awaiting a response from your ASA. The ASA IKE response message is either dropped or delayed too long that your VPN client sends another IKE message, causing the ASA to log the Duplicate first packet received
.
I would think your DSL link is more reliable -- less delay, less jitter, less packet loss -- than the 3G mobile network. Any reason that's not your default gateway? To test the 3G link as the issue, force the DSL to be your default.
Experiment
There is a lot of conflicting information about what actually happens on a Windows client when using split-dns
. So much that I decided to gather some evidence and see where it points. I set up a simultaneous packet capture on both the VPN-connected Windows client and the ASA to which that client is connected. Here is a diagram of the test setup:
With the packet captures running, I initiated DNS resolution on the client. To do so, I pressed enter on srv1.internal.example.com
in Google Chrome. Here are the resulting packet captures adjusted to sync their clocks and merged together.
Packets with IDs starting with "C" are from the Windows [C]lient.
Packets starting with "A" are from the [A]SA.
Analysis
In orange, we can see four separate DNS queries that are trying to be made by Windows/Chrome: The destinations of the four DNS queries are as follows:
- 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet
C69
) - 10.10.10.3 - the first DNS Server associated with the VPN Adapter (packet
C70
) - 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet
C78
) - 10.10.10.4 - the second DNS Server associated with the VPN Adapter (packet
C81
)
What is most revealing is that the two DNS queries apparently sent to 8.8.8.8 appear at the ASA in packets A95
and A105
with source and destination IPs translated from external addresses to internal addresses. The responses from the DNS server for those translated queries are in A97
and A106
which are themselves then translated to external addresses again in packets C74
and C84
, respectively. These DNS queries ultimately succeed.
Answers to the original questions
If Windows opts to send DNS queries for internal domains to adapters other than the VPN adapter, how can the VPN client ensure all DNS queries for internal domains are tunneled to the internal DNS servers?
Based on the above evidence, the VPN client seems to intercept DNS queries that match the domain configured using the split-dns value
command on non-VPN adapters.
Am I missing something here? Is there something fancy going on that somehow allows the VPN client to intercept DNS queries that Windows sends to the wrong adapter?
The fancy part that was missing is that the VPN client performs a sort of network address translation to make it appear to Windows that DNS queries for the internal domain are being serviced by the public DNS server to which Windows sent its request. In fact those requests are serviced by the internal DNS server.
I'm not sure exactly how this is accomplished, and there doesn't seem to be any documentation from Cisco that speaks to this. I accept that there is some amount of sorcery that the VPN client performs on the Windows end to achieve a functioning split DNS.
Notes on Adapter Binding Order
I tinkered with the oft-cited adapter binding order. Here is what I found. The adapter order seems to have no impact on the efficacy of the VPN Client's ability to intercept and translate DNS queries for internal domains.
Putting the VPN adapter highest in the binding order seems to result in Windows sending DNS requests only to the DNS servers on the VPN adapter initially. Those requests seem to be dropped entirely by the VPN Client (presumably because they don't match the internal domain). This then results in a Windows timeout (or a series of them) until, eventually, Windows attempts DNS resolution using the non-VPN adapter. This creates a noticeable and irritating delay when browsing.
Based on this, it seems that in split DNS configurations the VPN adapter should not be the highest priority.
Related Topic
- Cisco ASA VPN – No Response from Other Network in Site to Site VPN with Sophos UTM
- Cisco ASA 5510 AnyConnect SSL VPN – No Traffic Routed on Windows 3.1
- Cisco AnyConnect – Troubleshooting Internet Tunneling Issues
- Cisco AnyConnect – Internet Connection via L3 Device on ASA
- Vpn – Cisco ASA site to site with Forcepoint stonesoft NGFW
Best Answer
With your comment to Ron Trunk, I am assuming that you are using two ASA firewalls and one (ASA1) is connected to Internet through outside interface and the other ASA2 is having Site to Site connectivity to ASA1 (both are in differnt location and not connected through direct L2 connectivity). You want the user's behind ASA2 inside interface to use the Internet connectivity of ASA1..
If my assumption is correct, we can make it simple as below,
Place default route i.e., 0.0.0.0 towards Internet at ASA1 via its outside interface, so that all unknown public IP's will be routed towards Internet.
Place default route to next hop of ASA2 via outside interface.
Built the tunnel between ASA1 outside interface to ASA2 outside interface. So you have to bind crypto map at outside interface of both firewalls.
Allow ASA2 inside interface subnet (user's subnet) as local proxy and "any" as remote proxy in encryption domain of ASA2
In the encryption domain of ASA1, allow source (local proxy) as "any" and destination(remote proxy) as ASA2 inside interface.
If you want to block ASA1 inside talking to ASA2 inside, place deny statement in encryption domain between ASA1 inside and ASA2 inside *optional
With this, if a user sitting behind ASA2 inside try accessing internet, it will reach ASA2 inside, match the encryption domain, getting encrypted and send to ASA2 through tunnel. At ASA2, it will get decrypt and look for route for its public destination. Since we have default route towards outside interface, it will try to push the traffic through outside interface.
Here, the traffic entered into ASA1 through outside interface (Security level 0 - example) and trying to exit through the same outside interface (Security level 0) but by default, ASA won't allow traffic between the interfaces having same security level. So to make it work we have to permit the traffic between same security level interfaces. Below are those commands.
So if you configure this, the traffic from ASA2 inside interface will take the default route of ASA1 and reaches Internet.
Return communication will happen vice versa.
Cisco link explaining security level - http://www.cisco.com/c/en/us/td/docs/security/asa/asa70/configuration/guide/config/intparam.html#wp1039276
You can built, remote access VPN bind to outside interface of ASA1 for home user connectivity and they can take the same site to site to reach ASA2 inside if required.
If you want further explanation with configurations, I could provide.