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
A while ago I did a run through on site to site VPNs from Cisco ASA to Fortigate firewalls. Back then I said that the default settings were a bit ‘shoddy‘ and that I’d revisit it once I had more time.
What do you mean shoddy? Well, Cisco and Fortinet are both guilty of enabling ‘Everything’ to make the tunnel come up, so people can just use a wizard and not put to much thought into the process, for most people thats absolutely fine. However I’ve found ‘Many Times‘ I’ve been trying to put a VPN into third party and it’s like a game of ‘Encryption Bingo‘ e.g. ‘Can you change it from AES128 to AES256 and change the hash to SHA512‘, or ‘Do you not support elliptical curve’. Who are these people? Do they expect Tom Cruise to come rappelling out of a skylight to steal the details of their 2016 Christmas golf event!
I digress, so here’s how to set up a site to site VPN using IKEv2 with some weapons grade encryption. Here’s a pretty picture of what it will look like;
And here’s what my test bench topology looks like in EVE-NG.
Configuring the Fortigate for Site to Site VPN
After saying don’t use the wizard, I’m going to use the wizard to do the Fortigate end, then I’ll edit the tunnel it creates and make it a bit more ‘fit for purpose’.
From the web management portal > VPN > IPSec Wizard > Give the tunnel a name > Change the remote device type to Cisco > Next.
Give it the ‘public’ IP of the Cisco ASA > Set the port to the ‘outside’ port on the Fortigate > Enter a pre-shared key, (text string, you will need to enter this on the Cisco ASA as well, so paste it into Notepad or something for later) > Next.
Local interface will be in the ‘inside’ interface on the Fortigate > Enter the local subnet(s) > Enter the remote (behind the ASA) subnet(s) > Next.
Review the settings > Create.
Select IPSec Tunnels > Select the new tunnel > Edit.
In the Authentication Section > Edit > Change the IKE Version to 2 > Edit the Phase 1 Proposal.
Note: If you can’t see this option, change the tunnel type to custom.
You can do the first couple of steps together, but I like to do the Phase1 and Phase 2 proposals first, then tie it all up at the end. Configuration > Site to Site VPN > Advanced > IKE Policies > IKEv2 Policies > Add.
Local Passphrase: An alphanumeric string of characters (it’s a pre-shared key it must match the one you set on the Fortigate).
Remote Passphrase: Set the same at the local passphrase.
Scroll down.
Make sure your IKE Phase 1 policy is in the list, (you may have many) > IPSec proposal > Select > locate yours and add it in > OK > OK > Apply.
The last thing to do is make sure that the traffic travelling over the VPN DOES NOT get NAT translated > Firewall > NAT Rules > Select the top one > Add >Add Nat Rule Before.
Source Interface: inside
Destination Interface: outside
Source Address: any
Destination Address: {The group you created above for the network address behind the Fortinet}
Source NAT Type: Static
Disable Proxy ARP : Tick
Lookup Route Table: Tick
OK > Apply
Don’t forget to save the changes > File > Save Running configuration to flash
Finally send some interesting traffic across the VPN to bring up the tunnel.
Related Articles, References, Credits, or External Links
We mac users always get overlooked. If I had a pound for every time I’ve heard ‘Yeah we don’t support macs?” I would be a rich man. But thankfully this makes us work things out for ourselves usually!
Firstly you will want to download the VPN package (and have a valid client/user certificate, [see the link above]).
Obviously the installer is for Windows, but within the ZIP file you download, it has a copy of the XML file with the settings in it, and a copy of the Root CA certificate you used.
So your first job is to ‘import‘ the client certificate, it will be in PFX format, (if you followed my instructions), so you will need to supply the password you specified when creating the PFX file (not the mac password), when prompted to install it (double click on it).
The engineer in me isn’t quite sure why the client needs the Root CA certificate on it, (because that’s not how certificates work!) But Microsoft insist it’s necessary, so also double click and install the Root CA Certificate, (it’s inside the VPN Package).
You don’t need to install VPN software onto the mac, (it has its own built in). Click the Apple Logo > System Preferences > Network > Add > Interface = VPN > VPN Type = IKEv2 > Service Name = Azure-Client-VPN > Create.
Now open the XML file from within you VPN client software ZIP file, and locate the FQDN of the ‘Gateway’ address in Azure > Copy it to the clipboard.
Paste the server address into BOTH Server Address AND Remote ID > (Leave Local ID blank for now) > Authentication Settings
WARNING: I’m using mac OS Catalina, so I choose ‘None’ (NOT CERTIFICATE). But for mac OS Mojave (and older) CHOOSE CERTIFICATE). It’s a bug that causes an error (see below) if you don’t.
Select > Choose the CLIENT certificate you imported earlier, (Take note of the name in brackets, this is the common nameon the certificate). You will need this in a minute! > Continue > OK.
Put the Common Name from the certificate into the Local ID section > Apply > Connect.
All being well it should connect, (though it may prompt for you to enter your user password). BY DEFAULT the option ‘Show VPN Status in Menu Bar‘ should be ticked, if it isn’t then tick it.
With that option ticked, you can connect and disconnect the VPN quickly without needing to go back into System Preferences like so;
Given my background I’m usually more comfortable connecting to Azure with a Route Based VPN from a hardware device, like a Cisco ASA. I got an email this afternoon, a client had a server in a private cloud and a server in Azure, they needed to transfer files from the Azure server to the server in the private cloud. Now on further investigation this client had a Cisco vASA so a VPN was the best option for them, (probably).
But what if they didn’t? Or what if they were ‘working from home’ and needed to access their Azure servers that were not otherwise publicly accessible?
Well the Microsoft solution for that is called an ‘Azure Point to Site VPN‘, even though in the current Azure UI they’ve called it ‘User VPN Configuration‘, because ‘Hey! Screw consistency and documentation that goes out of date every time a developer has a bright idea, and updates the UI’ Note: I have a thing about things being changed in GUIs!
So regardless whether you are on or off the corporate LAN, you can connect to your Azure Virtual Networks.
Azure VPN (Remote Access)
This is not a full Azure tutorial, I’m assuming, as you want to connect to existing Azure resources, you will already have most of this setup already. But, just to quickly run through. You will need a Resource Group, and in that Resource Group you will need a Virtual Network. (Note: I like to delete the ‘default‘ subnet and create one with a sensible name).
So far so good, within your virtual network you will need to create, (if you don’t already have one,) a ‘Gateway Subnet‘. To annoy the other network engineers, I’ve made it a /24, but to be honest a /29 is usually good enough).
Now to terminate a VPN, you need a ‘Virtual Network Gateway‘.
Make sure it’s set for VPN (Route Based) > Connected to your Virtual Network > Either create (or assign) a public IP to it. I told you I’d be quick, however the Gateway will take a few minutes to deploy, (time for a coffee.)
Now launch ‘certmgr‘ and you will see the two certificates. Firstly, export the client certificate.
Yes you want to export the private key > You want to Save it as a .PFX file > Create a password for the certificate (MAKE NOTE OF IT!) > Save it somewhere you can get to, (you will need it in a minute).
Secondly, export the Root CA certificate.
You DON’T export the private key > Save as Base-64 encoded > Again save it somewhere sensible, you will also need it in a minute.
Open the ROOT CA CERT with Notepad, and copy all the text BETWEEN —-BEGIN CERTIFICATE—- and —-END CERTIFICATE—- Note: This is unlike most scenarios, when working with PEM files, where you select everything, (it tripped me up!)
Back in Azure > Select your Virtual Network Gateway > Select ‘User VPN Connection’ (seriously, thanks Microsoft be consistent eh!) > ‘Configure now‘.
Pick an address pool for your remote clients to use, (make sure it does not overlap with any of your assets, and don’t use 192.168.1.0/24, or 192.168.0.0/24, Note: These will work, but most home networks use these ranges, and let’s not build in potential routing problems before we start!)
Choose IKEv2 and SSTP > Authentication Type = Azure Certificate > Enter your Root CA details, and paste in the PEM text, you copied above > Save > Time for another coffee!
When is stopped deploying, you can download the the VPN client software.
Azure Point to Site (User VPN) Client Configuration
So for your client(s) you will need the ClientCertificate, (the one in PFX format,*) and the VPN Client software > Double click the PFX file > Accept ‘Current User‘.
*Note: Unless you deployed user certificates already, and your corporate Root Cert was entered into Azure above.
Type in the certificate password you created above > Accept all the defaults.
Yes.
Now install the Client VPN software, you may get some security warnings, accept them and install.
Now you will have a configured VPN connection. I’m a keyboard warrior so I usually run ncpa.cpl to get to my network settings, (because it works on all versions of Windows back to NT4, and ‘developers’ haven’t changed the way it launches 1006 times!)
Launch the Connection > Connect > Tick the ‘Do not show…‘ option > Continue > If it works, everything will just disappear and you will be connected.
Related Articles, References, Credits, or External Links
While working out how to create a VPN on the Cisco FTD (Firepower 1010), I thought I might as well set it up to the Cisco ASA that I have in the Data Center on my test network. This is what I’m connecting;
Create Site to Site VPN On Cisco FTD (using FDM)
Using a web browser connect to the devices FDM > Site to Site VPN > View Configuration.
Create Site-to-site-connection.
Connection profile name: Something sensible like VPN-To-HQ or VPN-To-Datacentre.
Local VPN Access Interface: outside.
Local Network: Crete new network.
Name: This will be your local LAN so give it a recognisable name.
Type: Network
Network: Your local (behind the FTD) network i.e. 10.254.254.0/24
OK.
Remote IP Address: The public IP address of the other device (in my case the Cisco ASA).
Remote Network: Add
Crete new network
Name: This will be the remote sites LAN so give it a recognisable name.
Type: Network
Network: The remote (behind the ASA) network i.e. 192.168.100.0/24
OK.
Check the settings are correct > Next.
I’m using IKEv2 (if your ASA is older than version 8.4 you will need to use IKEv1) > IKE Version 2 Globally Applied > Edit.
Create new IKE Policy.
Priority: 1
Name: S2S-IKEv2-Policy
Encryption: DES Really! (Why is that the default?) Remove DES and replace with AES256
I leave the rest of the settings as they are some people might not like Sha1 if you want to change it to sha254 for example then do so, but remember to change it on the IKEv2 policy on the ASA also. Also DON’T CONFUSEPRF with PFS, we will get the chance to set PFS later. > OK.
Enter (and confirm) the local and remote Pre-Shared Key (I usually set these the same, but they don’t have to be). Scroll down.
Nat Exempt: inside
Diffie Helman Group for Perfect Forward Secrecy (PFS): Leave disabled.
Next
Review the settings > Finish.
FTD VPN One Way VPN Traffic Warning!
At this point if you configure the ASA, the tunnel will come up, and if you’re behind the FTD everything will work. But If you’re behind the ASA and you want to talk to anything behind the FTD, it wont work. This confused me for a while, I could ping from my house to my servers at the DC but they could not ping me!
Resolution: What you need to do is (on the FTD) ALLOW traffic ‘inbound’ on the outside interface, for the subnet behind the ASA. (Yes that’s bobbins I know, it should do that for you, but at the moment it does not).
Policies > Access Control > Add.
Title: Allow-VPN-Traffic
Source Zone: outside_zone
Source Networks: The Network behind the ASA
Source Ports: ANY
Destination Zone: inside_zone
Destination Networks: ANY
Destination Ports/Protocols: ANY
OK
Pending changes > Deploy Now.
It can take a while to deploy, I recheck pending changes, and wait until it says it’s finished.
Create ASA Config for VPN to Cisco FTD
I’ve covered Cisco ASA IKEv2 VPN configselsewhere, so I’ll just post the config here and you can change the details (in red) and copy and paste it into your ASA.
All the traditional command line tools we used to use for VPN troubleshooting are available to you, you will need to SSH into the ‘Management Port’ before you can use them though! Or you can simply do the debugging and troubleshooting on the ASA!
Troubleshoot phase 1 (IKE)
[box]
show crypto isa
debug crypto ikev2 protocol
[/box]
Troubleshoot phase 2 (IPSec)
[box]
show crypto ipsec sa
debug crypto ipsec 255
[/box]
Related Articles, References, Credits, or External Links
Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.
You want a secure IPSECVPN between two sites using IKEv2.
Note: If the device you are connecting to does not support IKEv2 (i.e. it’s not a Cisco ASA, or it’s running code older than 8.4) then you need to go to the older version of this article;
Before you start – you need to ask yourself “Do I already have any IPSEC VPN’s configured on this firewall?” Because if it’s not already been done, you need to enable ISAKMP IKEv2 on the outside interface. To ascertain whether yours is on or off, issue a “show run crypto ” command and check the results, if you do NOT see “crypto ikev2 enable outside” then you need to issue that command.
[box]
PetesASA# show run crypto
crypto ikev2 enable outside << Mines already enabled and its IKE version 2
crypto ikev2 policy 10 encryption aes-256
integrity sha256
group 19
prf sha256
lifetime seconds 86400
crypto ikev2 enable outside
[/box]
1. I’m going to create access control lists next, one to tell the ASA what is “Interesting traffic”, that’s traffic that it needs to encrypt.
So below I’m saying “Don’t NAT Traffic from the network behind the ASA (10.254.254.0) that’s going to network behind the VPN device at the other end of the tunnel (172.16.254.0).
2. Now I’m going to create a “Tunnel Group” to tell the firewall it’s a site to site VPN tunnel “l2l”, and create a shared secret that will need to be entered at the OTHER end of the site to site VPN Tunnel. I also set a keep alive value.
Note: Ensure the Tunnel Group Name is the IP address of the firewall/device that the other end of the VPN Tunnel is terminating on.
3. Now we need to create a policy that will setup how “Phase 1” of the VPN tunnel will be established. It sets the encryption type (AES-256), the hashing/integrity algorithm (SHA-256), The Diffie Hellman group exchange version, and the Level of PRF (Pseudo Random Function). Finally it sets the timeout before phase 1 needs to be re-established. It sets the timeout value to 86400 seconds (That’s 1440 Minutes – or 24 hours if your still confused 🙂 ).
5. Finally we need to create a “Cryptomap”, this is the ‘thing’ that fires up the tunnel, when the ACL INTERESTING TRAFFIC is used, it also defines the transform set for “Phase 2” of the VPN Tunnel, that will also use 3DES and SHA and PFS. And last of all we apply that Cryptomap to the outside interface.
5. Don’t forget to save your hard work with a “write mem” command.
[box]
PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 5c8dfc45 ee6496db 8731d2d5 fa945425
8695 bytes copied in 3.670 secs (2898 bytes/sec)
[OK]
PetesASA(config)#
[/box]
6. Simply configure the other end as a “Mirror Image” of this one.
ASA 5500 Site to Site IKEv2 VPN Copy and Paste Config
Note: This uses AES-256 and SHA-256. It also assumes your outside interface is called ‘outside’. Check! I’ve seen them called Outside (capital O), wan, and WAN.
Site to Site VPNs are easy enough, define some interesting traffic, tie that to a crypto map, that decides where to send the traffic, create some phase 1 and phase 2 policies, wrap the whole lot up in a tunnel-group, and you’re done! But there needs to be a ‘peer address‘ in the crypto map, and if one end of the VPN is on DHCP that address is likely to change, so you cant supply that?
The solution is quite simple, Cisco had to address this years ago when they had remote IPSec VPN clients, you use a Dynamic Cryptomap, and because you can’t have a tunnel group either, you use the DefaultL2LGroup, (this gets used when a specific IP address is not defined).
This covers the, (more modern) Route based VPN to a Cisco ASA that’s using a VTI (Virtual Tunnel Interface).
Virtual Network Gateway Options
With VPN’s into Azure you connect to a Virtual Network Gateway, of which there are TWO types Policy Based, and Route Based. This article will deal with Route Based, for the older Policy Based option, see the following link;
These were typically used with routers, because routers used Virtual Tunnel Interfaces to terminate VPN tunnels, that way traffic can be routed down various different tunnels based on a destination, (which can be looked up in a routing table). Cisco ASA now supports Virtual Tunnels Interfaces (After version 9.7(1)).
Advantages
Can be used for VPNs to multiple sites.
Disadvantages
Requires Cisco ASA OS 9.7(1) So no ASA 5505, 5510, 5520, 5550, 5585 firewalls can use this.
Policy Based
These came first, essentially they work like this, “If traffic is destined for remote network (x) then send the traffic ‘encrypted’ to local security gateway (y).” Note: Where Local Security Gateway is a firewall at YOUR site, NOT in Azure! This is the way traditionally VPNs have been done in Cisco ASA, in Cisco Firewall speak it’s the same as “If traffic matches the interesting traffic ACL, then send the traffic ‘encrypted’ to the IP address specified in the crypto map”.
Advantages:
Can be used on older Cisco Firewalls (ASA 5505, 5510, 5520, 5550, 5585).
Can be used on newer Cisco Firewalls (ASA 5506-x, 5508-X, 5512-x, 5515-x, 5516-x, 5525-X, 5545-X, 5555-x, 5585-X)
Can be used with Cisco ASA OS (pre 8.4) IKEv1 only.
Disadvantages
Can only be used for ONE connection from your Azure Subnet to your local subnet. Note: You could ‘hairpin’ multiple sites over this one tunnel, but that’s not ideal.
Configure Azure for ‘Route Based’ IPSec Site to Site VPN
You may already have Resource Groups and Virtual Networks setup, if so you can skip the first few steps.
Sign int0 Azure > All Services > Resource Groups > Create Resource Group > Give your Resource Group a name, and select a location > Create.
OK, if you’re used to networking this can be a little confusing, we are going to create a virtual network, and in it we are going to put a virtual subnet, (yes I know this is odd, bear with me!) It’s the ‘Subnet Name‘and ‘address range‘ that things will actually connect to, (10.0.0.0/24).
All Services > Virtual Networks > Create Virtual Network > Give the Virtual Network a name, a subnet, select your resource group > Then create a Subnet, give it a name and a subnet > Create.
To further confuse all the network engineers, we now need to add another subnet, this one will be used by the ‘gateway’. If you are a ‘networking type’ it’s part of the virtual network, but is more specific than the subnet you already created.
With your virtual network selected >Subnets > +Gateway Subnet.
You can’t change the name, (you could before, then it wouldn’t work, which was strange, but I suppose it’s fixed now) > put in another network that’s part of the Virtual-Network, but does not overlap with the subnet you created in the previous step > OK.
All Services > Virtual Network Gateways > Create Virtual Network Gateway > Name it > Route Based > Create New Public IP > Give it a Name > Create.
Note: This will take a while, go and put the kettle on! Make sure all running tasks and deployments are complete before continuing.
You can do the next two steps together, but I prefer to do then separately, or it will error if the first one does not complete!
Now you need to create a Local Security Gateway. (To represent your Cisco ASA). All Services > Local Security Gateway > Create Local Security Gateway > Name it > Supply the public IP > Supply the Subnet(s) ‘behind’ the ASA > Select your Resource Group > Create.
Finally create the VPN > Select your Virtual Network Gateway > Connections > Add.
Give the tunnel a name > Site-to-Site IPSec > Select your Local Network Gateway (ASA) > Create a pre-shared-key (you will need this for the ASA config!) > Select your Resource Group > OK.
Configure the Cisco ASA for ‘Policy Based’ Azure VPN
I’m using 9.9(2)36, VTIs are supported on 9.7, but as with all new things, I’d assume that was buggy and go for 9.8 or above.
To Avoid Emails:
What IP do I put on my Tunnel interface / Where do I get that from? Use whatever you want, NO it does not have to be on the same network as something in Azure, in fact I’m using an APIPA 169.254.x.x. address, and it works fine, (think of it like a local loopback address, though do note the difference to the last octet in the route statement!)
Where’s the Crypto Map? It doesn’t need one.
Do I need to do NAT Exemption? NO (Unless you were hair pinning a traditional VPN from another ASA into this tunnel, or an AnyConnect client VPN session.)
There’s No ACL to Allow the Traffic, or an Interesting Traffic ACL? That’s correct, you don’t need any, (unless you apply an access-list to the the tunnel interface).
There are a couple of extra commands you will need, these are sysops commands. Their purpose is to set things globally, and are generally hidden from the config, (i.e ‘show run’ wont show them). These are recommendations from Azure. The first one drops the maximum segment size to 1350.The second command keeps the TCP session information even if the VPN tunnel drops.
The last thing to do, is tell the firewall to ‘route’ the traffic for Azure though the VTI. Note: The last octet in the destination IP is different from the VTI IP!
To test we usually use ‘ping’, the problem with that is, if you are using Windows Servers they will have their Windows firewall on by default, which blocks pings, (bear this in mind when testing). Also your ASA needs to be setup to allow pings, (try pinging 8.8.8.8 that usually responds), if yours doesn’t then configure your ASA to allow ping traffic.
As mentioned above, you might want to turn the firewalls off to test.
On the ASA the first thing to make sure is that the Tunnel Interface is up!
[box]
Petes-ASA# show interface tunnel 1
Interface Tunnel1 "AZURE-VTI01", is up, line protocol is up
Hardware is Virtual Tunnel MAC address N/A, MTU 1500
IP address 169.254.225.1, subnet mask 255.255.255.252
Tunnel Interface Information:
Source interface: outside IP address: 126.63.123.43
Destination IP address: 40.115.49.202
Mode: ipsec ipv4 IPsec profile: AZURE-PROFILE
[/box]
You can also use the following;
[box]
Petes-ASA# show crypto ikev2 sa
IKEv2 SAs:
Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
268975001 123.123.12.1/500 40.115.49.202/500 READY INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/814 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0x7b10e41a/0xfcb4576a
[/box]
Thats Phase 1 connected, you will also need to check Phase 2
[box]
Petes-ASA(config)# show crypto ipsec sa
interface: AZURE-VTI01
Crypto map tag: __vti-crypto-map-11-0-1, seq num: 65280, local addr: 82.21.58.194
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer: 40.115.49.202
#pkts encaps: 32, #pkts encrypt: 32, #pkts digest: 32
#pkts decaps: 33, #pkts decrypt: 33, #pkts verify: 33
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 32, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 123.123.123/500, remote crypto endpt.: 40.115.49.202/500
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: DA3A1C28
current inbound spi : B562D9C6
inbound esp sas:
spi: 0xB562D9C6 (3043154374)
SA State: active
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, VTI, }
slot: 0, conn_id: 11, crypto-map: __vti-crypto-map-11-0-1
sa timing: remaining key lifetime (kB/sec): (3962877/28755)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x000003FF 0xFFFFFFFF
outbound esp sas:
spi: 0xDA3A1C28 (3661241384)
SA State: active
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, VTI, }
slot: 0, conn_id: 11, crypto-map: __vti-crypto-map-11-0-1
sa timing: remaining key lifetime (kB/sec): (4193277/28755)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Petes-ASA(config)#
[/box]
Related Articles, References, Credits, or External Links
The one reason I prefer Cisco over Microsoft is they rarely change things, you learn how to do something and it’s learned. This is the second time have had to write this article purely because the Azure UI has changed!
Virtual Network Gateway Options
With VPN’s into Azure you connect to a Virtual Network Gateway, of which there are TWO types Policy Based, and Route Based. This article will deal with Policy Based, for the more modern Route based option, see the following link;
These came first, essentially they work like this, “If traffic is destined for remote network (x) then send the traffic ‘encrypted’ to local security gateway (y).” Note: Where Local Security Gateway is a firewall at YOUR site, NOT in Azure! This is the way traditionally VPNs have been done in Cisco ASA, In Cisco Firewall speak it’s the same as “If traffic matches the interesting traffic ACL, then send the traffic ‘encrypted’ to the IP address specified in the crypto map”.
Advantages:
Can be used on older Cisco Firewalls (ASA 5505, 5510, 5520, 5550, 5585).
Can be used on newer Cisco Firewalls (ASA 5506-x, 5508-X, 5512-x, 5515-x, 5516-x, 5525-X, 5545-X, 5555-x, 5585-X)
Can be used with Cisco ASA OS (pre 8.4) IKEv1 only,
Disadvantages
Can only be used for ONE connection from your Azure Subnet to your local subnet. Note: You could ‘hairpin’ multiple sites over this one tunnel, but that’s not ideal.
Route Based
These were typically used with routers, because routers use Virtual Tunnel Interfaces to terminate VPN tunnels, that way traffic can be routed down various different tunnels based on a destination, (which can be looked up in a routing table). But Cisco ASA now supports Virtual Tunnels Interfaces (After version 9.7(1))
Advantages
Can be used for VPNs to multiple sites.
Disadvantages
Requires Cisco ASA OS 9.7(1) So no ASA 5505, 5510, 5520, 5550, 5585 firewalls can use this.
Configure Azure for ‘Policy Based’ IPSec Site to Site VPN
You may already have Resource Groups and Virtual Networks setup, if so you can skip the first few steps.
Sign int0 Azure > All Services > Resource Groups > Create Resource Group > Give your Resource Group a name, and select a location > Create.
OK, if you’re used to networking this can be a little confusing, we are going to create a virtual network, and in it we are going to put a virtual subnet, (yes I know this is odd, bear with me!) It’s the ‘Subnet Name‘and ‘address range‘ that things will actually connect to, (10.0.0.0/24).
All Services > Virtual Networks > Create Virtual Network > Give the Virtual Network a name, a subnet, select your resource group > Then create a Subnet, give it a name and a subnet > Create.
To further confuse all the network engineers, we now need to add another subnet, this one will be used by the ‘gateway’. If you are a ‘networking type’ it’s part of the virtual network, but is more specific than the subnet you already created.
With your virtual network selected >Subnets > +Gateway Subnet.
You can’t change the name, (you could before, then it wouldn’t work, which was strange, but I suppose it’s fixed now) > put in another network that’s part of the Virtual-Network, but does not overlap with the subnet you created in the previous step > OK.
All Services > Virtual Network Gateways > Create Virtual Network Gateway > Name it > Policy Based (Note: This will change the SKU to Basic) > Create New Public IP > Give it a Name > Create.
Note: This will take a while, go and put the kettle on! Make sure all running tasks and deployments are complete before continuing.
You can do the next two steps together, but I prefer to do then separately, or it will error if the first one does not complete!
Now you need to create a Local Security Gateway. (To represent your Cisco ASA). All Services > Local Security Gateway > Create Local Security Gateway > Name it > Supply the public IP > Supply the Subnet(s) ‘behind’ the ASA > Select your Resource Group > Create.
Finally create the VPN > Select your Virtual Network Gateway > Connections > Add.
Give the tunnel a name > Site-to-Site IPSec > Select your Local Network Gateway (ASA) > Create a pre-shared-key (you will need this for the ASA config!) > Select your Resource Group > OK.
Configure the Cisco ASA for ‘Policy Based’ Azure VPN
I read somewhere that the ASA had to be at 9.1? That’s not true, I’ve done it with a firewall running 8.3, and I’ve read blog posts from people who have done this with a Cisco PIX (running version 6). But the firewall does have to support AES encryption (‘show version’ will tell you). There are some subtle differences in the code which I will point out below, but essentially you should be running an OS newer than 8.4 for this config to work. (As I’ve said I’ll address 8.4, and 8.3 (or earlier) below).
Connect to the ASA and create an object group for your local subnet, and the subnet that you are using in Azure, (Called Azure-SN above).
[box]
Type help or '?' for a list of available commands.
Petes-ASA> enable
Password: ********
Petes-ASA# configure terminal
Petes-ASA(config)# object-group network OBJ-AZURE-SN
Petes-ASA(config-network-object-group)# description Azure Subnet
Petes-ASA(config-network-object-group)# network-object 10.0.0.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
Petes-ASA(config)# object-group network OBJ-LOCAL-SN
Petes-ASA(config-network-object-group)# description Local Subnet
Petes-ASA(config-network-object-group)# network-object 192.168.100.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
[/box]
Then create an access-list, this will alert the firewall that there is some ‘interesting traffic’ that needs to be encrypted (we will call this ACL later on, from the crypto-map). Then create a NAT rule that stops traffic that’s going over the VPN tunnel from being NATTED.
Our VPN is going to use a pre-shared-key, (you created in Azure above). It will use AES-256 for encryption, SHA for hashing, and Diffie Hellman version 2 for key exchange. So we need to have a matching ‘phase 1’ (that’s ISAKMP) policy.
Enable ISAKMP (version 1) on the outside interface, then configure the parameters that will be used in ‘phase 2’ (that’s IPSEC). Note: If your outside interface is called something else like Outside or WAN substitute that!
Next, you need a tunnel-group, in this case the only job of the tunnel group has is to keep the pre-shared-key (PSK) to the peer you specify. Which in this case is the Azure Gateway.
The thing that ties it all together is the crypto map. Here I’ve called it “AZURE-CRYPTO-MAP”, WARNING if you already have a crypto map, use the name of that one, or all your existing VPNS will stop working, (show run crypto will tell you). This is because, you can only have one crypto map applied to an interface, but you can have many crypto map numbers, i.e crypto map {NAME} {NUMBER} {COMMAND}. And each VPN tunnel has its own number.
There are a couple of extra commands you will need, these are sysops commands. Their purpose set things globally, and are generally hidden from the config, (i.e ‘show run’ wont show them). These are recommendations from Azure. The first one drops the maximum segment size to 1350.The second command keeps the TCP session information even if the VPN tunnel drops.
To test we usually use ‘ping’, the problem with that is, if you are using Windows Servers they will have their Windows firewall on by default, which blocks pings, (bear this in mind when testing). Also your ASA needs to be setup to allow pings, (try pinging 8.8.8.8 that usually responds), if yours doesn’t then configure your ASA to allow ping traffic.
As mentioned above, you might want to turn the firewalls off to test.
On the Cisco ASA you can see the tunnel is established at Phase 1 (ISAKMP)
[box]
Petes-ASA# show cry isa
IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 40.113.16.195
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
[/box]
If yours says something else, (or nothing at all) then phase 1 has not established. You need to Troubleshoot phase 1 of the VPN tunnel. (Probably: Public IP is wrong, or pre-shared-key (shared secret) has been mistyped, check these first).
Assuming that’s working, your next test is to make sure that Phase 2 has established. You should see packets encrypting and decrypting.
[box]
Petes-ASA(config)# show cry ipsec sa
interface: outside
Crypto map tag: AZURE-CRYPTO-MAP, seq num: 1, local addr: 128.65.98.43
access-list ACL-AZURE-VPN extended permit ip 192.168.100.0 255.255.255.0 10.0.0.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
current_peer: 40.113.16.195
#pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 128.65.98.43/0, remote crypto endpt.: 40.113.16.195/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 97624DA8
current inbound spi : D7705547
inbound esp sas:
spi: 0xD7705547 (3614463303)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x0000000F
outbound esp sas:
spi: 0x97624DA8 (2539802024)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Petes-ASA(config)#
[/box] If phase 2 did not connect, then you need to troubleshoot phase 2 of the VPN tunnel. (Probably: Transform set is wrong, or routing being the ASA is not working).
Azure to Cisco VPN ‘Policy Based’ IKEv1 Complete Code Snippets to Copy and Paste
(Change the values highlighted in red)WARNING: re-read the warning about crypto map names above! [box]
Back in Part One, we setup the AD (Groups,) and the Certificate services that will knit everything together. Now we need to configure an NPS server that acts as a RADIUS server for our remote clients, And a RAS Server that our remote clients will connect to.
Step1: Network Setup
Microsoft have an alarming habit of telling you to connect DMZ assets to the LAN. In their defence I’ve seen some documentation where theres is a firewall in front and behind their RAS/VPN server, but then you keep reading and they refer to the NIC on the LAN and the NIC in the DMZ. As you can tell I’m not a fan, I prefer to have an un-authenticated and an authenticated DMZ, and neither of them are connected to the LAN, So then I can control what can, and cannot flow between the DMZs and the LAN.
My way means I have to allow more ports for domain membership etc, but, if you have a Cisco ASA I’ve covered that in the following article,
As for the VPNs and RADIUS you need to allow the following;
From Outside to the RAS Server
UDP 500 (ISAKMP)
UDP 4500 (NAT Traversal)
From the RAS Server to the NPS/NAP Server
UDP 1812 (RADIUS Authentication)
UDP 1813 (RADIUS Accounting)
UDP 1645 (RADIUS Authentication)
UDP 1646 (RADIUS Accounting)
Quite why it needs both pairs or RADIUS ports I’m unsure, I’ve not scanned or packet captured the traffic, but I’m wiling to bet it really only needs 1812/1813 or 1645/1646.
Step2: Install NPS
Server Manager > Manage > Add Roles and Features > Network Policy and Access Services > Complete the wizard accepting the defaults.
Administrative tools > Network Policy Server > Right click NPS (Local) > Register in Active Directory > OK.
Even though its not setup yet, we need to create our RAS server as a RADIUS client > RADIUS Clients > New.
Friendly Name: A sensible name that identifies the RAS server
IP: IP of the RAS server (On the LAN segment)
Shared Secret: Generate a new one and copy it to the clipboard, (you will need it in a minute.)
On the main page, ensure ‘RADIUS server for Dial-Up or VPN Connections’ is selected‘ > Configure VPN or Dial-Up.
Select ‘Virtual Private Network (NPS) Connections > Next > Ensure the RADIUS server you have just created is listed > Next > Ensure ONLY ‘Extensible Authentication protocol’ is ticked > Change its value to Microsoft Protected EAP (PEAP) > Configure.
EAP Types: Remove the one that is listed by default > Add in ‘Smart card or other certificate’ > OK > Under Groups make sure sure you have ONLY added the group you created back in part one > Next > Next.
Next > Next > Finish.
Your connection request policies should look like this.
Your network policies should look like this.
Step 3: Setup RAS
Server Manager > Manage > Add roles and Features > Next > Next > Next > Remote Access > Next.
Select DirectAccess and RAS > Finish the wizard accepting the defaults.
Open the Getting Started Wizard > Select VPN Only.
Administrative Tools > Routing and Remote Access > Right click {server-name} > Configure and enable Routing and Remote Access > Next > Custom configuration.
VPN Access > Next > Finish > Start service.
Once again right click {server-name} > Properties > IPv4 > Note: If you are not going to use your internal DHCP server/scope, then you can set one up manually (as shown) > Ensure ‘Enable broadcast name resolution’ is selected, and the RAS servers internal/LAN interface is selected > Apply.
Security Tab: Authentication provider = RADIUS Authentication > Configure > Add > Enter the IP of the NPS server > Change > Paste in the shared secret you copied, (above) > OK > OK.
Repeat the same procedure for Accounting provider, (below).
Drill down to ‘Ports’ > Right Click > Properties > Select SSTP > Configure > Remove the tick from ‘Remote access connections (inbound only) > OK. Repeat this procedure for ALL the protocols EXCEPT IKEv2, (So when finished, only IKEv2 is set to accept incoming requests).
Step 4: Configure Reference Windows 10 Machine
On a Windows 10 machine* Launch the ‘Change virtual private networks.
*Note: Your logged on user, must have a certificate issued to them, and be a member of the AD group we created earlier.
Add a VPN Connector.
VPN Provider: Windows (Built-in).
Connection Name: Connection-Template.
Server Name or address: (The ‘public’ name we put on the certificate on the RAS server).
Change Adapter options.
Right click the VPN connection > Properties.
Security Tab:
Type of VPN: IKEv2
Data Encryption: Maximum
Use Extensible Authentication Protocol (EAP)
Properties > Enter the name on the certificate on your NAP Server, (I know that does not make sense trust me!)
Tick your Root CA Cert for the domain.
Select ‘Don’t prompt user to authorise new servers or new authorities’.
Connect your VPN to test it.
Make sure everything works.
Note: I had some DNS resolution problems, see the post below to find out how I fixed them;
Now you need to ‘capture’ all those settings so you can give them to your other clients. To do that you need a copy of the PowerShell script MakeProfile.ps1 You will need to edit the script a little, see the example below. Running the script will output two files to the desktop, an PowerShell Script and an XML file
Step 5: Deploying the Settings
At the time of writing you can deploy these settings via three methods, PowerShell Script, SCCM, or Microsoft Intune. I’m simply going to run the PowerShell Script, there are a few restrictions though, you have to be logged on as the particular user. They need administrative rights to run the script, which is a bit of a pain, you can use restricted groups and set the powershell to run at logon with group policy, then remove the policy when configured, but it’s still a bit of a drama. Below I’m simply running the VPN_Profile.ps1 file I generated above.
Now once the user logs in, (and has a valid remote internet connection.) The remote client will auto-connect.
That covers USER tunnels, you can also, (Post 1709 Windows 10 Builds,) have DEVICE tunnels. Which I would write a part three about, but I simply cannot get them to work, so I’m waiting for the bugs to be ironed out, and I will revisit it at some point in the future.
Related Articles, References, Credits, or External Links
