The cloud technology is spreading like wild fire all over the world. And like everything else in technology, unfortunately security is the last thing that vendors consider while developing technology. The same happened with the cloud. At the beginning, nobody thought about security in the virtual cloud. After several security weaknesses have been identified related with cloud and virtual environments, vendor started now to develop security products for cloud and virtual devices.

Cisco introduced the Virtual Security Gateway (VSG) some time ago. Now, it brings the proven and trusted Cisco ASA technology in the cloud to complement the VSG offering. The new ASA cloud product is called Cisco ASA 1000V Cloud Firewall.

The product employs the mainstream ASA (Adaptive Security Appliance) security technology that has been optimized for virtual environments. It works with the Cisco Nexus 1000V virtual switch and also integrates with the Cisco VNMC (Virtual Network Management Center) for administration and management purposes.

The ASA 1000V comes as a software package which is downloadable as an Open Virtualization Format file. It works with the VMware vSphere 4.1 or later releases with VMware ESX or ESXi servers.

This is a question that I get from time to time in my work environment either from colleagues or customers. I will show you a couple of ways to do this.

In ASA, for traffic to pass through interfaces, several conditions must be met. Since we are talking here for inside and outside interfaces, this means from higher security level (inside) to lower security level (outside). The most important conditions to examine here is the NAT (if used) and the access control list. Lets see more details below:

Traffic from inside to outside using NAT

This is the most common scenario. NAT is most commonly used in real networks to hide the internal network range and to translate the non-routable private addresses (internal network) to publicly routable IP addresses on the outside.

We can have two types of NAT:

1. Dynamic NAT (with Port Address Translation – PAT being a subcategory of this)
2. Static NAT (internal addresses are permanently mapped to external public addresses)

Here we will examine the most common scenario which is PAT. This is a many-to-one translation which allows us to translate all internal IP addresses into a single public IP address which is assigned to us by the ISP and exists on the outside of the ASA. For ASA to keep track of all these many-to-one translations, it uses port numbers. A different port number (out of the range of 65000) is assigned to a different internal IP address.

Lets see the configuration for allowing all traffic from inside to outside using PAT:

Assume the following:

inside LAN range: 192.168.1.0/24
Public IP addresses available: 100.100.100.1 – 100.100.100.32
ASA outside interface IP address: 100.100.100.1

Option1:

Using the ASA interface IP (100.100.100.1) to translate all internal addresses:

ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0
ciscoasa(config)# global (outside) 1 interface

Commands for ASA version 8.3 and later:

ciscoasa(config)# object network internal_lan
ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0
ciscoasa(config-network-object)# nat (inside,outside) dynamic interface

Option2:

Using one of the other available public IP addresses for translation:

ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0
ciscoasa(config)# global (outside) 1 100.100.100.2 netmask 255.255.255.255

Commands for ASA version 8.3 and later:

ciscoasa(config)# object network internal_lan
ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0
ciscoasa(config-network-object)# nat (inside,outside) dynamic 100.100.100.2

After taking care of the NAT commands, we need to see our access-list commands. By default, if you don’t have an access-list applied on the inside interface, then all traffic is allowed to pass because the inside is the highest security level (100). However, if for any reason you apply an access-list to the inside interface, then you must explicitly allow all IP traffic to pass using the ACL.

ciscoasa(config)#access-list INSIDE_IN extended permit ip any any
ciscoasa(config)# access-group INSIDE_IN in interface inside

Traffic from inside to outside without NAT

There are some cases where we don’t want to have NAT between inside to outside. In this scenario, the ASA works like a router but it still applies firewall inspection to the traffic. All you have to do here is to disable NAT and then allow traffic with an ACL:

ciscoasa(config)#no nat-control
ciscoasa(config)#access-list INSIDE_IN extended permit ip any any
ciscoasa(config)# access-group INSIDE_IN in interface inside

Thats it.

What is Cisco ASA Identity Firewall?

Traditionally, Cisco ASA policies and rules are enforced mainly using an Access Control List (ACL) which allows or denies access to certain network resources based on the source/destination IP addresses and port numbers. For example, lets say we want source IP 10.1.1.1 to be able to access server with IP 10.2.2.2 and port 80. We would create an entry on an ACL which states explicitly that the specific source IP is allowed access to the specific destination IP at port 80.

Now, from Cisco ASA version 8.4(2) the concept of Identity Firewall is introduced. Basically, the new feature enables the firewall to allow or deny access to network resources based on the username identity instead of a simple source IP address. For example, now we can create a rule that says user “john” can access server 10.2.2.2 at port 80. As you can see, the new feature introduced the concept of “user-based authentication” instead of pure IP based authentication.

The way this feature works is to integrate Cisco ASA with Microsoft Active Directory. A special Active Directory Agent software needs to be installed on a server (usually installed on the AD itself). This agent provides username to IP address mappings to the ASA. So, when user “john” logs in to AD, the agent will obtain the IP address of the computer that john is using (i.e 10.1.1.1 to be consistent with our example above). So, ASA will know that user john has IP address 10.1.1.1 and will apply network rules accordingly.

Other Network Firewalls such as Fortinet, Checkpoint, Palo Alto etc have been offering the user-based authentication feature for a long time now. Cisco is catching up eventually on this as well.

A normal Layer3 Routing device, when receiving a packet on one of its ingress interfaces, first checks the destination IP address of the packet and then consults its routing table in order to forward the packet to the proper outgoing interface. This is the most basic operation of a router.

A stateful firewall (like the Cisco ASA), on the other hand, has a much more complicated work to do on an incoming packet. There are several steps and decision points that the packet has to go though before being allowed and forwarded by the firewall. This is called “conditional forwarding” because the packet must satisfy several rules and conditions before passing through the firewall.

The diagram below shows a simplified traffic flow of a packet through a Cisco ASA device:

As shown on the figure above, the packet coming from the Input Interface is being checked first if it is a part of an existing connection. If yes, it skips many of the intermediate steps and is only checked if it satisfies the Layer7 inspection rules.

Now, if the packet is a new connection, the firewall needs to store in its state table all the pertinent information of this new connection. Some of the information that is stored in the state table include the source and destination IP addresses, the source and destination port numbers, TCP sequence numbers etc. Since the packet is a new connection, it will have to go through several steps and checks before being forwarded to the output interface.

First the firewall checks if there is a Layer3 route for the destination address of the packet in the routing table. After that, it checks if the Access Control List (ACL) on the input interface allows the specific connection to pass. If this is ok, then it checks to see if there is a NAT rule configured for this specific connection. After that, the device verifies that any Layer7 inspection rules allow the specific connection. After all the previous steps have been satisfied successfully, only then the packet is allowed to exit the output interface.