I’ve been setting up a VPN solution on the test bench as I’m looking at Always On VPN. When I noticed that I had a problem with my remote VPN connections on Windows. They would connect fine but I could not resolve any FQDNs for my domain?
VPN no DNS Solution
By default, all (Windows) VPN connections are ‘Force Tunnel’ (this means they have the option ‘Use default gateway on remote network’ selected). This also means that, (unless your RAS server is the default Gateway for your network,) you usually don’t have internet access when connected to the VPN.
Now I connected fine, and I could ping IP addresses on my corporate network, but I could not ping my servers by their domain name, in fact Windows was trying to resolve my domain name to a public IP?
Google this problem and you’re simply told to ‘Disable IPv6 on your network card, and this works, (if you want to keep your remote users Force-Tunnelled). But disabling IPv6 is hardly a fix is it?
Also If you want internet access for your remote clients, (Commonly referred to as ‘Split Tunnel’), then even with IPv6 disabled, the problem comes back!
Why is this happening? Well even with Force Tunnel enabled, you can still use your local LAN (Connect to your VPN, and ping your home gateway, or printer or wireless access point if you don’t believe me!) This connection takes precedence over your remote VPN connection, to prove it run a netstat -rn command.
From the above you can see my Ethernet Adaptor has a metric of 6, and my VPN connector, (in this case called Connection Template) has metric of 23. AND THE LOWEST ONE WINS, so your DNS queries are going out of your local internet connection NOT down the VPN tunnel!
How Do I Fix this VPN no DNS?
Well until Microsoft fixes this in Windows 10, (it’s fine on Windows 8 and earlier), you have to manipulate the metrics yourself, like so;
VPN no DNS On Your Physical Adapter;
Start > ncpa.cpl {enter} > Right click your NIC > Properties > Internet Protocol Version 4 > Properties.
Advanced > Untick ‘Automatic Metric’ > Set the Interface Metric to 20 > OK > OK >OK.
On Your VPN Connector;
Start > ncpa.cpl {enter} > Right click your VPN Connector > Properties > Internet Protocol Version 4 > Properties.
Advanced > Untick ‘Automatic Metric’ > Set the Interface Metric to 10 > OK > OK >OK.
Now your DNS look-ups should behave!
Related Articles, References, Credits, or External Links
I’ve seen this pop up a few times in forums, and I’ve even seen people post “It cant be done, you will need to change one of the subnets,” but to be honest, it’s not that difficult.
We simply have to do some NAT. This is the bit people struggle with, with VPNs usually we need to STOP NAT being applied to VPN traffic, and we still do, we simply NAT the traffic before we sent it over the tunnel.
Normally overlapping networks can trip you up, in one of TWO scenarios;
Scenario 1 (The other end overlaps with YOU)
Scenario 2 (Two endpoints overlap with EACH OTHER)
Solution
Scenario 1 (The other end overlaps with YOU)
Firstly you need to pick another subnet for BOTH ends, and this is the subnet the other end will THINK it’s talking to, sometimes this is called an XLATED subnet, or a PSEUDO subnet, or a MASQUERADE subnet.
ASA-1 Config
Firstly we need THREE objects creating, (instead of the usual TWO). Then take note the syntax of the NAT statement;
Note: Above, I’m assuming your interfaces are called inside and outside!
Now you need to create the ACL that will be used to define ‘interesting traffic’, i.e. traffic that will be encrypted, but unlike normal you will specify the XLATED addresses.
[box]
!
access-list VPN-INTERESTING-TRAFFIC line 1 extended permit ip object OBJ-Site-A-XLATE object OBJ-Site-B-XLATE
!
[/box]
The rest of the VPN config is the same as normal, here I’m using IKEv2. If you have to use IKEv1 see the link at the bottom of the page.
WARNING: If you already have VPNs then change CRYPTO-MAP (above) to the name of your existing crypto map.
Scenario 2 (Two endpoints overlap with EACH OTHER)
Firstly you need to pick another subnet for BOTH of the ends with the overlapping subnet, and this is the subnet that your end will THINK it’s talking to, sometimes this is called an XLATED subnet, or a PSEUDO subnet, or a MASQUERADE subnet.
Then you will need to create TWO more, for the remote ends to TALK BACK TO.
Note: If you already have a VPN to one of the sites, then this process will replace that, and create one for the second site. So If you already have one tunnel you are going to need to either REMOVE it or change the NAT and Interesting traffic ACL. (Note: If you delete the ACL used by a crypto map, then it disapears from the crypto map! So you need to manually add it back). From this point forward I will assume we are creating BOTH tunnels from scratch.
ASA-1 Config
We need four objects for each XLATE, and two objects for the actual endpoints, (as two sites have the same REAL subnet we can use the same object for both). Then we create the NAT statements for each tunnel.
Now you need to create the ACL that will be used to define ‘interesting traffic’, i.e. traffic that will be encrypted. But unlike normal you will specify the XLATED addresses.
[box]
!
access-list VPN-2-Site-B extended permit ip object OBJ-Site-A-B-XLATE object OBJ-Site-B-and-C
access-list VPN-2-Site-C extended permit ip object OBJ-Site-A-C-XLATE object OBJ-Site-B-and-C
!
[/box]
The rest of the VPN config is the same as normal, here I’m using IKEv2. If you have to use IKEv1 see the link at the bottom of the page.
WARNING: If you already have VPNs then change CRYPTO-MAP (above) to the name of your existing crypto map.
ASA-2 Config
Unusually, the remote end (sometimes referred to as a ‘spoke’) does not need to be a mirror image of the main site, this is because we are sending VPN traffic ‘back’ from 192.168.1.0/24, to the XLATED subnet 10.1.1.0/24.
WARNING: If you already have VPNs then change CRYPTO-MAP (above) to the name of your existing crypto map.
ASA-3 Config
Unusually the remote end (sometimes referred to as a ‘spoke’) does not need to be a mirror image of the main site, this is because we are sending VPN traffic ‘back’ from 192.168.1.0/24, to the XLATED subnet 10.1.2.0/24.
By default all modern distributions of Windows come with their client firewall enabled. Which is a good thing, most corporate networks simply disable it using the rationale that they have a corporate firewall and security software etc. Again thats fine, but what if you want to leave it on, and still be able to ping that host to see if its alive.
Solution
The firewall exception is already written for you, you just have to enable it.
Open the Window Firewall with Advanced Security console > Inbound Rules > ‘File and Printer Sharing (Echo Request – ICMPv4-In) > Enable Rule > Obviously do the same for IPv6 (if required).
Related Articles, References, Credits, or External Links
You would think by now I would have committed a lot of this to memory, but seeing as I always have to visit my own Subnet Calculator, I thought it was about time I had a ‘handy reference’. Feel free to copy and print it off.
Solution
Click for larger image.
Related Articles, References, Credits, or External Links
If you have HP Access Points on remote sites, you have the choice of either leaving them in automomous mode, or registering them with a controller at another site. This is handy if you want to manage all your VSC’s from one location. You can do this via DNS, or via DHCP at that remote site, (I tend to setup both to be on the safe side).
Solution
Option 1: Set MSM Controller Location via DHCP
1. On your DHCP server, open the DHCP management console.
4. Add >Display name = Colubris > Description = Vendor Class for Colubris Products > Under ASCII Set the value to Colubris-AP > The rest of the values will autofill > OK > Close.
6. Set the Option class to Colubris > Add > Name = MSC > Data type = IP Address > Array = Ticked > Description = List of MSC IP Addressses > OK > OK.
7. Locate you active DHCP scope, and expand it > Right click > Configure Options.
8. Advanced Tab > Vendor Class = Colubris > 001 MSC = Tick > IP Address > Set the IP address(s) of your controller(s) > Apply > OK.
9. Check you can see the option listed, (as below).
Option 2: Set MSM Controller Location via DNS
1. In the forward lookup zone for your domain, you can create A/Host records for your MSM controller(s). Create them in the cnsrv1, cnsrv2, etc format.
WARNING:
You may find that you have a problem with the Access Points flagged as ‘Waiting Acceptance‘, if that happens see the following link.
I did an AnyConnect design for a client recently, and they asked ‘Instead of using the firewall to lease the DHCP addresses to our remote clients, can we use our Windows DHCP Server?” In the past I’ve used Windows DHCP servers for IPSECVPN clients, but more recently I’ve tended to just use the firewall. The client had some valid reasons for wanting to do so, and given the complexity of their network, before I said yes, I wanted to make sure we could give them what they wanted, and have a separate DHCP scope just for the remote clients.
Solution
Setup a New Windows AnyConnect DHCP Scope
1. Server Manager > Tools > DHCP > Expand Server-name > IPv4 > Right Click > New Scope > Name it and follow the instructions.
2. Setup a network with enough addresses to cover all your remote clients.
3. You do not need to specify a router/default gateway, but I setup DNS settings (even though you still set these options on the firewall).
Once the new scope is up, activated and running you need to configure the firewall.
Changing AnyConnect to Use your Windows DHCP Server.
Here I already have the ASA doing DHCP from a local IP pool, so I’m going to remove that pool, and change over to the DHCP server.
1. To use a windows server for DHCP you need to put an entry in the ‘Tunnel-Group’ for your AnyConnect connection (if you only have one DHCP scope that’s all you need to do, but because I want to use a different scope I also need to put an entry in the AnyConnect ‘Group-Policy’ as well. (That’s the group policy on the Cisco firewall, I’m NOT talking about Windows Group Policies!)
Below with a show run tun command I can see the firewall pool I’m using and the name of my group-policy.
3. Then while still in the general-attributes section specify the IP address of your DHCP server. Then you need to edit the group-policy to specify the network address of the DHCP scope you want to use (if you only have one scope skip this step, but if you have more than one scope the ASA will take an address for the first scope it gets to, if you don’t specify one!)
