TAC Security Podcast Episode #33 - Virtual Security: The ASA1000v and Virtual Security Gateway

[Jay Johnston]

 

Episode Name: Episode 33 - Virtual Security: The ASA1000v and the Virtual Security Gateway

Contributors:  Rama Darbha, Michael Robertson, Magnus Mortensen, Jay Johnston, David White Jr.

Posting Date: June 10, 2013

Description: In this Episode, the podcast team is joined by two special guests:  Rama Darbha and Michael Robertson who join us to talk about Cisco's virtual security devices.  Specifically the Virtual ASA (ie: the ASA 1000v) and the Virtual Security Gateway (VSG).  We discuss the role of these security devices in the network, how they differ from physical devices, and how the packets flow through them.  We also cover standard use cases for these devices.  We hope you enjoy this episode!  Please leave us comments below.

Listen Now    (MP3 15.9 MB; 22:01 mins)

Subscribe to the Podcast in iTunes by clicking the image below:

About the Cisco TAC Security Podcast

The Cisco TAC Security Podcast Series is created by Cisco TAC engineers. Each show provides an in-depth technical discussion of Cisco product  security features, with emphasis on troubleshooting.

Complete show listing and show information

Show Notes

VSG Interface Design

ASA 1000V Interface Design

VSG - Profile Mapping

ASA 1000V - Profile Mapping

ASA 1000V Block Diagram

VSG Packet Flow - Permitted Connection

VSG Packet Flow - Denied Connection

ASA 1000V Packet Flow - Inbound Connection

ASA 1000V Packet Flow - Outbound Connection

[Julio Carvajal]

Hello,

Another great Podcast,

Thanks

Julio Carvajal

[libertysys]

Hey guys,

Love your work, and it's great to see another podcast.  (Although David, please speak up. A lot.)

Can you confirm for me that i've understood the details correctly: ASA1000v supports ONE (1) protected subnet.  No VLANs, no DMZ, no customisable zones, just ONE subnet.  Did i hear that right? 

If i understood that correctly, who in their right mind would ever deploy it?  1.5 GB RAM per instance is a lot for one subnet.  Vyatta Core can do arbitrary zone-based rules in a third of that.

Please tell me my ears need fixing. 

Thanks,

Paul

[David White]

Hi Paul,

First, apologies for not speaking up!  I'll do better next time.

You understood correctly.  The ASA 1000V only supports a directly connected L2 network on the protected side.  No VLANs or other DMZ interfaces can be added.  You can sub-divide that L2 network and apply different Security Profiles to it, but you cannot add an L3 router to the inside and put hosts behind it.  Nor can you add an additional interface to the ASA 1000V.

That said, no need to go to the Dr. to get your ears checked :-)  But, it is what it is.

Sincerely,

David.

[mirober2]

Hi Paul,

It's true that the ASA 1000V's inside interface needs to protect 1 subnet, but this doesn't mean you're limited to a single set of policies (or a logical zone) because of the security-profile interfaces that we discussed.

Imagine a subnet that contains web servers, FTP servers, and database servers. The inside interface has to be the default gateway for all of these protected servers, but you can still apply different policies to all of these servers despite the fact that they're behind the same interface of the ASA.

For example, you could have 3 security-profile interfaces for each of these logical groups of servers. The security-profile for the web servers could apply a NAT rule and a connection limit. The security-profile for the FTP servers could apply FTP inspection, an ACL, and a different connection limit. This way, you can apply different policies to different logical groups/zones of servers on a single edge firewall.

If you add VSG on top of that, you can also create a policy that prevents the FTP servers and database servers from talking to each other even though they're in the same subnet.

The ASA 1000V doesn't support sub-interfaces, but you can use this as an analogy for the security-profile interfaces. All traffic has to enter the firewall on the inside interface, but based on how it's tagged by the VEM (similar to how a VLAN tag would work on a trunk), we can apply different policies to it. The only difference is that we don't have different L3 routing.

Hope that helps clarify things. Thanks for listening!

-Mike

[libertysys]

FWIW, David, you are consistently quieter than Jay and Magnus.

[libertysys]

Thanks Mike & David for the replies.

I remain skeptical about the usefulness of a product with such basic restrictions, but to assuage my curiousity:

1. How many hosts are supported on the internal interface?  Are you seeing customers use subnets larger than a /24 behind the ASA1000v?
2. Is the expectation that the main users of ASA100v would be service providers running multi-tenant clouds?
3. What is the expected size of the VMware host/cluster that runs the ASA1000v? (The Nexus 1000v requires VMware Enterprise Plus, and i'm guessing that licensing the combination of Nexus 1000v, ASA1000v, and VSG is still going to cost considerably more per host than the cost of the VMware license, even for people getting 50+% off RRP.)
4. How many instances of ASA1000v are you typically seeing customers run on the same host/cluster?
5. Are there ways to use the ASA1000v & VSG in combination that support something functionally equivalent to a traditional corporate firewall where there might be 2 segregated internal LANs, 2 segregated DMZs, and 2 outside interfaces on the uplinks of different ISPs?  Any chance you could briefly describe how such a setup would work?

It seems to me that the VSG is a much more useful product.  But then, ASAs have never seemed like a very good choice to me in the first place, except perhaps at the very high end, where their clustering and 10 Gbps capabilities come to the fore.

Regards,

Paul

[mirober2]

Hi Paul,

1) The ASA doesn't enforce any restrictions on the number of VMs on the inside. The data sheet provides some guidance on the scalability of a single ASA 1000V instance (again, you can simply deploy multiple ASA 1000Vs if the environment requires more performance):

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps12233/data_sheet_c78-687960.html

2) This is not necessarily an expectation, but it is definitely a prime use case.

3) I've seen customers deploy ASA 1000V in environments ranging from 1 or 2 hosts all the way up to ~20 hosts. Again, the ASA 1000V doesn't really enforce any requirements on the host/cluster other than the requirement for its compute resources. I haven't seen anything on the pricing side so I can't speak to that part.

4) Again, I've seen it range from 1 ASA 1000V to upwards of ~20.

5) You can use a concept we call service chaining to combine ASA 1000V and VSG functionality within the virtual data center. You can use VSG policies to restrict VM-to-VM traffic and logically group VMs into zones for access control. You can then use ASA 1000V policies to apply edge firewall protection (additional ACLs, NAT, site-to-site VPN, application inspection, etc.). Here is what the N1K config looks like with only a VSG policy applied:

vservice node VSG type vsg

  ip address 10.60.1.1

  adjacency L2 vlan 60

!

port-profile type vethernet Servers

  org root

  vservice node VSG profile servers-local-profile

Here is an example of service chaining to combine VSG and ASA 1000V policies:

vservice node ASA type asa

  ip address 10.100.1.1

  adjacency l2 vlan 100

!

vservice path VSG-ASA

  node VSG profile servers-local-profile order 10

  node ASA profile webserver-public-profile order 20

!

port-profile type vethernet Servers

  org root/PodX

  vservice path VSG-ASA

In my opinion, there are always multiple ways to solve a problem and how appropriate a particular solution is depends on the scenario. ASA 1000V certainly doesn't fit in every use case, but when you need more advanced firewall control at the edge of the virtual environment the ASA 1000V can help.

For basic access control, VSG certainly does the job. When you need things like NAT and inspection policies that follow the VM throughout the data center, or you need to secure traffic through a VPN all the way up to the edge of the virtual infrastructure, the ASA 1000V fits in well.

-Mike

[shajimoorkoth]

Hi All,

We have scenario where Servers are in Virtual enviorment and Physical with same subnet. If we Place ASA1000v, it will create a second L3 subnet between physcal server and virtual server. Is there any way we can retain Physical server and Virtaul servers in same subnet.

Regards,

Shaji

[Rama Darbha]

Shaji,

The only way to deploy the ASA 1000V is as a Layer3 hop in the path. There is no way to retain Physical Server and Virtual Servers in the same subnet.

As a workaround, you can use NAT on the ASA1000V to translate the Virtual servers IP address to be in the same subnet as the Physic Servers.

- Rama

[shajimoorkoth]

Rama,

Thank You for your reply. Challenge is requirement is for exisiting network. The critical server IP address are not allowed to change. I am just working on possibility of VXLAN and ASA and VXLAN Gateway for mapping VLAN to VXLAN.

Thanks and Regards

Shajimon M