Creating DMZ on ASA for Virtual Infrastructure (Part 2)

The first post focused on configuring the firewall for our new DMZ's but this post will focus on the physical switch configuration.  The physical switch is what provides end to end connectivity from our ASA firewall to our virtual infrastructure.  In the previous post we saw the overall logical design of our internal, external, and DMZ networks.  Below is a simplified version of the physical topology.

The Inside interface of the ASA plugs into our 3Com 4200G on port gi 1/0/1.  This port on our 3Com switch needs to be changed from Access mode to Trunk mode to tag the packets as they egress towards the ASA.  We will need to create VLAN's 9 and 10 on the switch as well.  This is a layer 3 switch and it is noteworthy that I am not creating an interface for VLAN 10.  I do not want packets to have the opportunity to route without crossing through the ASA for access control and inspection.  Below are the configurations for both a 3Com and a Cisco switch.


[3COM]

<3comS1>system-view
[3comS1] vlan 10
[3comS1-vlan 10] description dmz_internal
[3comS1] vlan 9
[3comS1-vlan 9] description dmz_external
[3comS1] int gi 1/0/1
[3comS1-GigabitEthernet1/0/1] description trunk to asa
[3comS1-GigabitEthernet1/0/1] stp disable
[3comS1-GigabitEthernet1/0/1] port link-type trunk
[3comS1-GigabitEthernet1/0/1] port trunk permit vlan all

[CISCO]

CiscoS1#conf t
CiscoS1(config)#vlan 10
CiscoS1(config-vlan)#description dmz_internal
CiscoS1(config-vlan)#vlan 9
CiscoS1(config-vlan)#description dmz_external
CiscoS1(config)# int gi1/0/1
CiscoS1(config-if)#description trunk to asa
CiscoS1(config-if)#spanning-tree portfast
CiscoS1(config-if)#switchport mode trunk

Next step is to find the interfaces on the switch that connect our VMware servers.  These ports were also in Access mode by default.  We need to change these to Trunk mode to pass/tag multiple VLAN's destined for the VMware servers.

[3COM]

<3comS1>system-view
[3comS1] int gi 1/0/2
[3comS1-GigabitEthernet1/0/2] description trunk to vhost1
[3comS1-GigabitEthernet1/0/2] stp disable
[3comS1-GigabitEthernet1/0/2] port link-type trunk
[3comS1-GigabitEthernet1/0/2] port trunk permit vlan all

[CISCO]

CiscoS1#conf t
CiscoS1(config)# int gi1/0/2
CiscoS1(config-if)#spanning-tree portfast
CiscoS1(config-if)#switchport mode trunk
CiscoS1(config-if)#description trunk to asa

We have now created trunk ports on our switch connecting our ASA and our Virtual Infrastructure.  There is end to end connectivity that will pass all VLAN's created on either the ASA or in the virtual environment.

Creating DMZ on ASA for Virtual Infrastructure (Part 1)

Recently I was tasked with creating a DMZ on our Cisco ASA 5510 for use with virtual machines in our vSphere environment.  In a physical environment I would have created a DMZ off another physical interface on the ASA and attached our physical servers to that but with the virtual infrastructure I had to design it a bit different.  Since our virtual infrastructure currently resides on the inside of our network we need to find a way of extending a secure DMZ into that environment.  To do this we will need to use sub-interfaces, 802.1q trunks, and typical ACL's on our ASA.  VMware refers to this as a "Partially Collapsed DMZ with Virtual Separation of Trust Zones".  Basically what that means is you use both physical and virtual pieces to enforce security.  Virtually separate the servers into different port groups on separate VLAN's and then enforce security between these port groups with a physical firewall device like our ASA.  This first post will focus solely on initial design and configuration of the Cisco ASA firewall device.

Currently we have a very flat network with a single VLAN and basic configuration.  The ASA has an inside and outside interface and all network switches operate on VLAN 1.  I will be adding two new sub-interfaces on the ASA for a multi-tiered DMZ as well as the associated VLAN's on our switches and virtual infrastructure.

Name       Interface    IP Address
Outside:     eth0/0         1.1.1.1
Inside:        eth0/1         172.20.6.0/24
dmzint:       eth0/1.10    192.168.10.0/24
dmzext:      eth0/1.9      192.168.9.0/24

Our virtual infrastructure resides on our inside network hung off of interface eth0/1.  I mentioned before that I would normally use for example eth0/2 to create a separate physical DMZ.  To take advantage of virtualization and avoid using addition physical ports on the ASA/network switch I opted to create virtual sub-interfaces on eth0/1.  Each sub-interface will serve as a DMZ network with different security levels.

asa1#conf t
asa1(config)#int eth0/1.10
asa1(config-subif)#vlan 10
asa1(config-subif)#nameif dmzint
asa1(config-subif)#security-level 50
asa1(config-subif)#ip add 192.168.10.1 255.255.255.0

asa1(config)#int eth0/1.9
asa1(config-subif)#vlan 9
asa1(config-subif)#nameif dmzext
asa1(config-subif)#security-level 25
asa1(config-subif)#ip add 192.168.9.1 255.255.255.0

What this does is create virtual sub-interfaces on our inside interface.  For eth0/1.10 the sub interface ID is 10 and will tag outgoing packets with VLAN 10.  For eth0/1.9 the sub-interface ID is 9 and is tagged with VLAN 9.  The interface ID and VLAN number do not have to match but it will ease administration if you do so.  The security levels chosen are relevant because they determine the default interface security.  The ASA by default allows an interface of higher security to pass traffic to an interface of lower security. What this means is the Inside interface (security level 100) will pass all traffic to the Outside interface (security level 0) without needing an ACL because there is an implicit allow rule.  Once we start implementing ACL's these implicit rules will drop off and we will need to manually configure security.

The overall logical ASA design will look like the picture below.

We have the ability to control which traffic will flow between which networks as well apply additional NAT rules for further obfuscation.  We have also opened the option of dual homing servers in both demilitarized zones.  You can see from the picture below the enhanced isolation/segmentation we gain from this topology.  In the next segment I will discuss the switch and vSphere configuration.