Short for IP Security, IPSec is an Internet Engineering Taskforce (IETF) standard suite of protocols between 2 communication points across an IP network that provide data authentication, integrity, and confidentiality. It is supported by different vendors. OpenSSL can still be preferred over IPSec.

ASAv(config)# username admin password cisco123 ASAv(config)# aaa authentication ssh console LOCAL ASAv(config)# crypto key generate rsa ASAv(config)# ssh 192.168.100.0 255.255.255.0 MGMT TEST from the Management PC. File Size 4 files. Create Date April 21, 2018. Last Updated April 21, 2018.

We are going to configure an IPSec VPN between a Cisco ASA and a pfSense Firewall. Cisco ASA is a Cisco proprietary firewall that provides VPN/Firewall solutions to small, medium and large enterprises. The pfSense Firewall on the other hand is a free and open source distribution of FreeBSD customized for use as a firewall and router. pfSense is lightweight and can be installed on a PC with two NICs. You can get a copy of your pfSense from here. At the time of this writing, the latest version is v2.4.4.

In this lab, we will configure a Site-to-Site IPSec VPN between a Cisco ASAv and a pfSense Firewall.

Prerequisites

• Cisco ASAv with configured interfaces, ASDM as well as other basic configurations.
• pfSense Firewall, WAN and LAN configured interfaces.
• IP Addressing and ensure connectivity between the ASAv appliance and pfSense.
• Basic routing configuration on the Cisco L3 router for internet access.

Build the topology on EVE-NG

I have built the topology on my EVE-NG lab and configured the two firewalls.

• Cisco ASAv
• 2 x Cisco Multi-layer switch images (you can still use a layer 2 switch image. It’s not very necessary to use L3)
• pfSense Firewall
• Internet Router. Cisco L3 image.
• A Cloud image (management(Cloud0)) that will connect both Site A and Site B to the internet through our Internet Router.

We are going to have two Sites. Site A and Site B that are going to be connected to an internet router which will provide some routing to the internet.

In our next step, we will set up a site-to-site ipsec vpn between the two sites that use different firewall solutions from two giant vendors.

Set up site-to-site IPSec implementation

There are two phases in IPSec implementation. Phase 1 and Phase 2.
ISAKMP/Phase 1 attributes are used to authenticate and create a secure tunnel over which IPsec/Phase 2 parameters are negotiated.
We will begin by configuring the our ASAv with the phase I and phase II attributes.

IPSec ISAKMP Phase I

IPSec Phase II

That’s it from our ASAv side of things. Lets jump to our pfSense firewall on Site B

Phase I

Login in to the pfSense web configurator and navigate to VPN > IPsec

Click on Add P1 on the Tunnels tab which we are going to add our Phase I attributes as below.

Leave the rest as is and save your changes. Once done you should have Phase I set up as below

Phase II

Click on Show Phase 2 Entries button and click on Add P2 to add our phase 2 attributes

Next configure your IPSec phase 2 attributes as below.

Click the Save button to save changes and go back to the Tunnels tab where you can view a summary of your Phase 1 and Phase 2 configuration.

Our IPSec configuration is complete on both ends. To very this we are going to check the vpn connection status on the pfsense firewall as well as on the show ipsec status on the ASA firewall. To do that, on the pfsense menu, go to Status > Ipsec and click on Connect VPN button. Connection should be established.

If you followed keenly on the configuration, you should get an established connection from the pfsense above as well as the ASAv firewall below

In our ASAv firewall, we can issue the below command to confirm our ipsec status

That marks the end of our lab: Configuring Site-to-Site IPsec VPN between Cisco ASAv and pfSense Firewall.

We’ve likely all heard of Cisco even if we haven’t used it, that’s just how big they are in the networking world — that is until it comes to public cloud. It came as a surprise to me when I could only find sparse snippets of information available online; Cisco’s documentation is there but leaves a little to be desired and a few PDFs from what looks like a Cisco conference but sometimes that’s enough to get started.

So today that’s what I’m going to write about;

How to deploy Cisco ASAv in Azure and the gotchas discovered during setup.

Cisco, like many vendors, do have a marketplace image available to deploy, so this was an obvious starting point for us to test from. Deployment is simple as ever with some basic information needed, subnets, credentials, version etc.

Deployment via any method will result in an image with SSH already enabled and ready to use from anywhere you have a connection to the new VM.
For those that prefer a friendly GUI the ASDM software is available to download from the management IP you created during the deployment:

Anyone who has worked with ASDM before will know this isn’t enough, you’re going to need a version of Java installed locally before you can open the app. I found Java 8 to be the most compatible.
Now you will need to enable the ASDM feature, using SSH you can run the following commands to enable everything necessary for ASDM to connect.

First, I will need to enter administration mode:

This will prompt for a password update to the default admin password, this can be different to the one you used for SSH access.

Now I need to enable the configuration terminal, this allows for commands to be entered that enable services or changes to the ASAv:

Finally, I can enable the ASDM feature by first setting authentication, then starting a http service and finally allowing access to the ASA via the management interface from anywhere (you can change the IP and subnet to lock this down to increase your security measures):

Once everything is complete ASDM should now be able to connect using the management IP and the credentials created during deployment.

By default the ASAv is barely configured and will require the interfaces to be setup and routes to be added for each interface.

The interfaces should receive an IP from Azure via DHCP and unlike other VMs it is best to make these static within the VM as well as at the Azure level.

Something you will likely have noticed during the marketplace deployment is the requirement for 4 NICs, this is mainly forced by the marketplace template but isn’t strictly necessary.
I found that 4 NICs was 1 too many and decided to customise the template for my own needs. The template is available to download from the marketplace and comes in the standard Azure RM template format.

Be mindful that if you are deploying via Azure RM Templates that you will need to accept the Terms and Conditions of the marketplace image, this is normal a tick box via the portal but it will cause your deployment to fail if you don’t do this first:

Run this command using the Azure CLI to find the string value of the terms:

Once complete, take the returned value and use it in the below command to accept the terms, this is at the subscription so be mindful of what you are accepting

Taking the template, I was able to strip out the unnecessary resources including public IPs (this is an internal firewall after all). So now I have a template that can deploy a 3 NIC ASAv into my existing Azure infrastructure.

Deploying the code via Azure CLI or PowerShell is easy enough and there’s plenty of documentation available for that so I’m going to skip over it but here are a few links that might help:

This 3 NIC setup was created to allow the following interfaces:

Management
A connection to a management subnet which I can use to connect to the device from inside the network (unless you are adding a public IP, I don’t advise you do that)

Trusted
The inside interface, this is where all Azure services will forward traffic to get outside Azure or to other environments depending on how you utilise the ASAv.

Untrusted
The outside interface, anything that wants to communicate with Azure must enter the platform through this interface. In this case the traffic is coming via ExpressRoute or Virtual Network Gateway from an on-premise environment.

With these 3 interfaces I now have a very sturdy gateway between Azure and everything else but Azure by default allows traffic to flow everywhere (ignoring NSGs for now). All of my VMs can still go directly to the internet and my Virtual Network peering connections allow traffic to communicate between environments… this defeats the purpose of the ASAv! What I need now is to control my traffic flow and that’s were Azure Route Tables comes in. Azure Route Tables are a very simple concept, but one wrong move and you can break everything!
Azure route tables allow us to forward all traffic for a network range to a virtual appliance, in this case my ASAv.

Ignoring HA for now, we’ll get to that later, all of my traffic will flow to the ASAv on its trusted network interface and now I can add rules in the trusted ACL. This is very useful for inter-vnet traffic and brings vnet peering under the control of the new firewall.

Static routes will need to be added to allow traffic from the Untrusted networks to the trusted networks and vice versa. By default, the ASA sends all internet bound traffic out via the management interface, not beneficial if you plan to make the untrusted interface public facing. You can override this but you will need to be mindful of how your traffic flows in and out of the device, traffic can’t go out one interface and back in another.

So what about NSGs, well I still needed them and one of the biggest discoveries I had was how to surround the ASAv. No matter where your ASA exists it needs to have its own NSG that is not shared with any of your infrastructure even if it’s all in the same vnet.

Azure traffic is inspected at the NSG level BEFORE the routing level and this caused endless problems as I never really had a great picture of how the traffic flowed.

This discovery was an important step in getting all traffic to flow correctly. By creating a new NSG and moving my ASA into that I could segregate it completely and manage the ASA on its own.

Now the silly stuff, HA with the Cisco ASAv is… acceptable. The configuration will allow you to setup HA between to ASAv devices, it will work in Active:Standby and it will failover to the second device as it needs to.

However, Cisco documentation for HA in cloud requires that you give the ASAv access to your cloud platform to allow it to manage your route tables, when the device fails over it updates the route tables with the IP of the secondary device, only for the routes and route tables you’ve told it. In Azure a service principal covers this access and the normal process applies for creating service principal, how you manage its permissions is up to you but limiting to route tables only is a good idea!

Now I know what you’re thinking, why not use load balancers and I did on one side of the ASAv because sadly the HA agent is unable to respond to different HA probes from multiple load balancers… Not for the lack of trying trust me!

Note: Azure itself has a limitation on VMs within an Availability Set, which you should be using for HA devices, all VMs within the set can only be associated with two load balancers, 1 public and 1 private.

Cisco documentation shows the load balancer as the outside facing device where traffic flows to the untrusted interface. Seems sensible if this is an edge device but for us it’s an internal device between Azure and on premise.

Now allowing a device to manage small numbers of route tables doesn’t seem that big of a deal but if you are building a shared platform for many projects then allowing a single device to manage all of those route tables can get very dangerous.

This happens to be the case for my project, so some quick thinking and we decided to reverse the load balancer logic, now the load balancer is connected to our Trusted Interface.

In this setup we now have a single IP (the load balancer frontend) for all Azure based infrastructure and the Cisco ASAv now manages 2 route tables, which is much safer with less moving parts.

Here comes the less than acceptable part, HA configuration for Cisco in Azure does NOT allow configuration sync… I’ll repeat that, they DO NOT allow configuration sync. This is crazy, personally I don’t want to have to manage two devices especially when one is a failover device. Quite quickly the standby node will be out of date and failover won’t work.

Some quick research and I found that there are some solutions to this problem and the most promising of these was Ansible. Ansible contains a Cisco ASA module which if used properly and from the beginning can mean all of the ASA configuration is stored in code.

Unfortunately, I have not been able to test this as of yet but based on my experiences so far, I would recommend using something… because the alternative is manual.

There are other caveats when using a Network Virtual Appliance (NVA) in Azure, for any devices I have worked with there is a lack of compatibility with available platform services. Azure Backups, Azure Site Recovery, Log Analytics, none of these work with Cisco ASAv and this makes running them more difficult.

Azure Backups
Not strictly necessary if you are taking Cisco level backups of the saved configuration, this can be restored on a newly deployed device.

Azure Site Recovery
Again not necessary if you do not need a disaster recovery option (but you should), the backup configuration again works here as the devices can be redeployed to another region and the backup restored to them.

Cisco Asav Keygen

Log Analytics
This one is a little more difficult, you get built-in monitoring of traffic within the ASAv itself but if you want VM level information then a 3rd party monitoring system such as Zabbix or Solarwinds will be required.

TL:DR If you plan on deploying a Cisco ASAv into Azure, really, REALLY think about it, there are native options that offer the same functionality that you will get from the ASAv with the added benefits of being supported by Azure and can’t be easily provisioned without any additional requirements such as licensing.

If you are using the ASAv for firewall functions then consider Azure Firewall, if you are using it as a VPN endpoint then consider Azure Virtual Network Gateways. Whilst the Cisco name is longstanding don’t fall into the trap of thinking they are going to be better than Azures native tools because once it’s in place, it can be very difficult to move to something else.

So, after all of that, if you really want that ASAv here’s my recommendations for your deployment:

• Think about the placement of your ASAv, possibly use a central virtual net for the device itself and make this your hub in a hub and spoke peering model.
• If you can, try to automate as much of the configuration setup as possible. In the long run this will make managing the devices much easier and stop configuration drift between your primary and secondary.
• Map it out, drawing the traffic flow can make it easier to see where you need rules added. With NSG and ASAv rules involved it can become difficult to see where traffic is getting blocked.
• Consider limiting your HA service principal to route table updates only, make it secure by default.
• Remember its Active:Standby so ensure you provision enough throughput in your license for a single device not a combination of 2.

Cisco Asav Appliance

Finally, here are some useful links I used during the deployment: