Continuing with my ‘Learn some Fortigate‘ theme’. One of the basic requirements of any edge firewall is site to site VPN. As the bulk of my knowledge is Cisco ASA it seems sensible for me to work out how to VPN both those firewalls together, like so;
Well that’s the pretty picture, I’m building this EVE-NG so here’s what my workbench topology looks like;
Disclaimer (Read First! Especially before posting any comments!)
Fortinet prides itself on you not needing to use the CLI, (until you actually need to use the CLI of course!) But both ends are configured using the GUI and ASDM. This is designed for the ‘Let’s just make it work, who cares what’s going on under the hood‘ generation. Which means it enables IKEv1NOTIKEv2 on the Fortigate, and BOTH IKEv1 and IKEv2 gets enabled on the Cisco ASA. Couple that with all the weak Crypto sets that get enabled, because someone might have a hardware firewall from 1981 or something! So in production I’d consider doing things a little more manually. I will post another article on the same subject, but then I’ll make the tunnel as secure as I can, (watch this space). This is an exercise in getting the tunnel up and making it work.
Tech Note: If you just use both wizards it wont work, thankfully I could debug the tunnel on the Cisco ASA to work out why. Fortinet sets all the DH groups to 5, and Cisco sets them all to 2. And Fortinet enables PFS and Cisco don’t. (They do on older versions of the OS, but not on the newer ones).
Create IKE/IPSec VPN Tunnel On Fortigate
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.
Connect to the ASDM > Wizards > VPN Wizards > Site-to-Site VPN Wizard > Next.
You should already have an object for your Local Network add that in > Then add in a new Network Object for the remote (behind the Fortigate) subnet. MAKE SURE that the new object is selected as the Remote Network > Next.
Enter the Pre-Shared key you used (above) > Next > Tick to DISABLENAT > Next > Finish.
Tech Note: Look at all those Ciphers/Hashing/Additional Protocols that are about to be turned on! 🙁 That’s why I work at command line.
Finally you will need to send some traffic over the tunnel to ‘bring it up’.
If you have a problem, see the debugging/troubleshooting links below.
Related Articles, References, Credits, or External Links
I had a call with a client last week, they are in one of my employer’s DCs, and their servers are behind a vASA. They had purchased some Meraki MX devices for their IT team who were working remotely (during the Covid-19 lockdown), and were struggling. Normally we would just suggest AnyConnect, but these guys were building new machines for their clients, and needed access directly to the domain from their home networks to facilitate this. So a Site-to-Site VPN was the ‘best fit’ for them.
But being home internet connections they were on DHCP for their public IP addresses. If we were all Meraki, then Meraki Auto VPN would have them up and running in no time. Conversely if they were all ‘proper’ Cisco we would be OK. In fact if they had static IP’s at home we would be OK.
So how to setup a site-to-site VPN ‘into’ a Cisco ASA with a static IP, from another firewall with a dynamically assigned (DHCP) public IP?
I tested this firstly using a Cisco ASA at the ‘remote/dynamic’ end, then tested with a Meraki MX Device. But the methodology can be applied to any ISAKMP/IPSEC capable firewall with a dynamically assigned public IP that you want to establish a VPN into an ASA with a static IP address.
Solution
Step 1: Investigate Your Remote Device
Do your homework on the remote device, find out what it supports for VPN connectivity, you will need to answer the following questions;
IKE Version: Does it use/support IKEv1 or IKEv2 (or both) Set the ASA config accordingly
Subnet on the remote site: Make sure it does not overlap with your central site, (or anyone else who will also be ‘dynamically’ connecting*).
Pre-Shared-Key: MAKE SURE this is long/complicated and hard to guess.
*Note This may mean your remote sites may need to change their subnets so they don’t overlap!
Step 1 Configure the ‘Central’ ASA
I’ve covered IKEv1 VPNsand IKEv2 VPNs elsewhere on the site, feel free to go and see what what the following configuration is doing. For my Meraki Tunnel I’m going to use IKEv1, Phase 1 (3DES, SHA, Diffie Hellman Group 2, and a Lifetime of 86400 Seconds,) and Phase 2 (3DES, SHA and no PFS). Note: Some would consider this weak, but it’s the default setting on the remote device so lets keep it simple. In production you can slowly make phase1/2 more secure to your liking once you know it’s working.
Change the values in Red;
WARNING: If you already have a crypto map in use then change the keyword CRYPTO-MAP (below) to match yours. (Or all your VPNs will suddenly stop working!) Issue the command show run crypto map, if you’re unsure.
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
I was asked to setup a VPN to help out a colleague this week. When I had a look, one end turned out to be an Edge Gateway, I wasn’t that concerned, I’d done similar things in my prior role, I just didn’t have access to the vCloud or VMware at this datacenter.
Depite my best efforts on the ASA, the tunnel refused to come up, it took a little looking ‘under the covers’ to accurately diagnose the problem. But to save you my pain, I’ll post the setup of both ends so yours will be a little less stressful.
VMware Edge Gateway VPN Setup
Locate the Edge Gateway in vCloud Director > VPN > Create new VPN > Tick ‘Enable This VPN‘ configuration > Set the local and remote networks > Local ID is the local public IP of the Edge Gateway > Remote ID is the pubic IP of the Cisco ASA > Set the encryption protocol as AES256 > Copy the pre-shared-key (Warning: some browsers wont select all of the key, and you will end up characters short, make sure you have it all!) > OK.
On the ‘Firewall’ Tab allow all traffic TO and FROM the remote subnet, (behind the Cisco ASA).
Note: There no need to make a NAT Exemption.
Cisco ASA VPN Setup (For Edge Gateway)
Note: The version of Edge Gateway I was using, was using (once AES256 is selected)
IKE Version: 1
Encryption:AES-256
Hashing: SHA
Diffie Hellman: Group 2
Perfect Forward Secrecy: Enabled (group 2)
I’m aware that newer Edge Gateways support IKEv2 but debugging the incoming requests told me mine was using IKEv1.
You DO NOT have any existing VPNs configured, (if you do, change the name of the CRYPTO-MAP (above) to match the name of your cryptomap and use a higher number, e.g. ‘outside_map 2‘).
Troubleshooting Edge Gateway End of the VPN
You need access to the underlying VMware infrastructure > Select Networking and Security > Locate the NSX Edge > VPN > IPsec VPN > Show IPsec Statistics > Here you can see some meaningful error massages if theres a problem.
Troubleshooting Cisco ASA End of the VPN
I’ve covered this to death in the past, so rather than reinvent the wheel;
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]
This was surprisingly easier than I was expecting! Special thanks to Steve for letting me loose on his test network for the Meraki end of the tunnel. Here I’m using an MX 64 Security appliance, and a Cisco ASA 5510.
Note: The Meraki device will need a static IP.
Solution
Configuring Meraki MX Device for VPN to a Cisco ASA
From your Meraki dashboard > Security Appliance > Site To Site VPN.
If you have no VPNs setup then you will need to select ‘Hub’, then scroll down to ‘Non-Meraki VPN Peers’ > Add a peer.
Give the tunnel a name > Public IP is the address of the ASA > Private Subnets is the network(s) behind the ASA > Preshare secret is a shared key you will enter on the ASA (below). Above select all the networks you have behind the Meraki that you want to participate in the VPN and set their ‘Use VPN’ Status to ‘Yes’
Note: If you click the IPSEC policy you will see what it wants to use for phase 1 and phase 2 of the VPN tunnel. BE AWARE: By default PFS (Perfect Forward Secrecy) is disabled. If you setup your AS VPN from within the ASDM wizard this may be enabled on the ASA. More reason to use the command line options I give you below!
If you don’t know the public IP of your Meraki device, here is where to find it (so you can use it when configuring the ASA).
Configuring Cisco ASA5500 for VPN to a Meraki MX Device
To make things simple, change the values in RED below then you can paste in the command to your Cisco ASA.
WARNING: Below I use a crypto map called CRYPTO-MAP If you already have one then CHANGE the name to match your existing one (‘show run crypto map‘ will show you). e.g. if yours is called outside_map then change the entries below to outside_map 2.
Note: This config uses newer (post 8.3) NAT commands.
I’ve done thousands of firewall VPN’s but not many that terminate on Cisco Routers. It’s been a few years since I did one, and then I think I was a wuss and used the SDM. So when I was asked to do one last week thankfully I had the configs ready to go.
I’m going to use the IP addresses above, and my tunnel will use the following settings;
3. Create a ‘Crypto map’ that is used to apply the phase 2 settings to an interface.
[box]
R1(config)#crypto map VPN-C-MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R1(config-crypto-map)#set peer 1.1.1.2
R1(config-crypto-map)#set transform-set VPN-TS
R1(config-crypto-map)#match address VPN-ACL
[/box]
4. Apply that crypto map to an interface, (usually the Internet facing one).
[box]
R1(config-crypto-map)#interface Serial0/1/0
R1(config-if)#crypto map VPN-C-MAP
*Jan 3 07:16:26.785: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#exit
R1(config)#
[/box]
5. In most cases your router will be doing NAT, if so you will need to change the ACL that is looking after the NAT for you, look in your running config for something that looks like the following;
[box]
R1#show run
Building configuration...
Current configuration : 1249 bytes
------------output removed for the sake of space------------
!
ip nat inside source list 100 interface Serial0/1/0 overload
!
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
!
------------output removed for the sake of space------------
!
line aux 0
!
[/box]
6. To stop our VPN traffic getting NATTED, we need to put a deny in that ACL, and put it before that permit statement. Remember:
Permit=Perform NAT
Deny=Don’t perform NAT
On this router (unlike the ASA‘s that I’m more used to), there is no option to define an ACL line number. So its easier to remove the existing one, add the new line then put the original one back. Finally save the changes.
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#no access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)#access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config)#access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)#exit
R1#
%SYS-5-CONFIG_I: Configured from console by console
R1#write mem
Building configuration...
[OK]
[/box]
7. Now at the other site, the config should be a mirror image. I will post it in its entirety, so you can copy and paste it into the router, I will highlight the bits you need to check and change in red.
[box]
crypto isakmp policy 1
encr aes
hash sha
authentication pre-share
group 2
lifetime 86400
crypto isakmp key SecretK3y address 1.1.1.1
ip access-list extended VPN-ACL
permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
crypto ipsec transform-set VPN-TS esp-aes esp-sha-hmac
crypto map VPN-C-MAP 10 ipsec-isakmp
set peer 1.1.1.1
set transform-set VPN-TS
match address VPN-ACL
interface Serial0/1/0
crypto map VPN-C-MAP
no access-list 100 permit ip 20.20.20.0 0.0.0.255anyaccess-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255access-list 100 permit ip 10.10.10.0 0.0.0.255 any
[/box]
8. Test your VPN with the following commands. Note: you need to send some traffic over the VPN before it will establish!
[box]
show crypto isakmp sa
show crypto ipsec sa
[/box]
WARNING: If you have an ACL applied to the routers outside interface, you will need to allow in the Peer IP, like so;
[box]
ip access-list extended outside-in
permit esp host 1.1.1.1 any
permit udp host 1.1.1.1 any eq isakmp
permit udp host 1.1.1.1 any eq non500-isakmp
[/box]
If you do not, the other end will fail Phase 1 with a WAIT_MSG_3 Error!
Related Articles, References, Credits, or External Links
