Cloning the ASA 1000V
You can deploy multiple instances of the ASA 1000V. You can add one or multiple instances of the ASA 1000V to your deployment by using either of the following methods:
- Factory-shipped OVA template: This method enables you to clone multiple instances of the ASA 1000V with different sets of OVF deployment parameters. The ASA 1000Vs have blank configurations, and you obtain the required configuration settings for each instance from the OVF deployment parameters.
- Configured OVA template: This method enables you to clone a previously configured OVA template. The ASA 1000Vs already have configurations, and you simply reapply the current OVF parameters. The result is that you can clone multiple instances of ready-to-use ASA 1000V instances with the required configurations.
- VMware vSphere API: This method enables you to use application programmatic interfaces to clone an existing ASA 1000V and change the current configuration parameters for each new ASA 1000V instance.
Requirements for Cloning
This section includes the following topics:
Preparing the Master ASA 1000V
To prepare the master ASA 1000V, perform the following steps:
1. Deploy the ASA 1000V, set up management routes, SSH access, the username and passwords, and ASDM access.
2. Register with the VNMC using the steps listed in the Cisco ASA 1000V Getting Stated Guide.
3. Save the running configuration to the startup configurtion using the write memory command.
4. It is critical that that you power off the ASA 1000V.
Note If you clone a powered-on ASA 1000V, there is a slight chance that the original ASA 1000V may crash right after the cloning is completed.
Cloning the Master
To clone the master ASA 1000V, perform the following steps:
1. Export the master ASA 1000V to an OVA template using the vSphere Client GUI or any other equivalent method. For example, you can use ovftool from VMware as follows:
ovftool vi://sample-vc50.example.com/performance-testbed/vm/ASA_1000V asa_master.ova
Note Using VSphere 4.x to create an OVA template removes the vApp properties set in the master. This means that when the clone is deployed in Step 2, all vApp properties need to be specified.
2. Create a cloned ASA 1000V instance using the VSphere Client GUI or any other equivalent method. For example, you can use ovftool from VMware as follows:
ovftool --acceptAllEulas --datastore="datastore1 (1)" "--net:VM Network=525-net-vm" "--net:425-net-vm=60-net" "--net:60-net=425-net-vm" --prop:ManagementIPv4=188.8.131.52 --prop:ManagementIPv4Gateway=184.108.40.206 --prop:ManagementIPv4Subnet=255.255.0.0 --name="ASA Clone 2 " asa_master.ova vi://sample-vc50.example.com/performance-testbed/host/sample-esxhost.example.com/
It is important to change the Management interface IP address in the clone so that it becomes a separate instance. Otherwise, an IP address conflict will occur. All other vApp properties could be changed if different parameters need to be set. Note that if the OVA template is created using VSphere 4.x, then all vApp properties need to be specified in the clone, because these properties are not stored in the template.
Note The ovftool does not export default values if you are using an ESXi 4.1 deployment; however, an ESXi 5.0 deployment does support the export of default values.
The following is an example using ovftool from VMware to set all of the properties:
ovftool --acceptAllEulas --datastore="datastore1 (1)" "--net:VM Network=525-net-vm" "--net:425-net-vm=60-net" "--net:60-net=425-net-vm" --prop:ManagementIPv4=220.127.116.11 --prop:ManagementIPv4Gateway=18.104.22.168 --prop:ManagementIPv4Subnet=255.255.0.0 --prop:ASDMIPv4=0.0.0.0 --prop:HAActiveIPv4=0.0.0.0 --prop:HASubnetIPv4=0.0.0.0 --prop:HAStandbyIPv4=0.0.0.0 --prop:ManagementStandbyIPv4=0.0.0.0 --prop:VNMCIPv4=0.0.0.0 --name="ASA Clone 2 " asa_master.ova vi://sample-vc50.example.com/performance-testbed/host/sample-esxhost.example.com/.
Fields marked with 0.0.0.0 values should be set appropriately if used; otherwise, they can be set as 0.0.0.0.
3. Power on the clone.
Note Cloned ASA 1000Vs regenerate default RSA keypairs with the same settings and delete all other keys.
Firewall Functional Overview
Firewalls protect inside networks from unauthorized access by users on an outside network. Firewalls enable you to control when inside users access outside networks (for example, access to the Internet), by allowing only certain addresses out.
When describing networks connected to a firewall, the outside network is in front of the firewall, and the inside network is protected and behind the firewall. The ASA 1000V allows two data interfaces: one inside and one outside, plus a management interface and one interface for failover. The ASA 1000V allows the creation of multiple security profile interfaces to provide different security policies for the virtual machines (VMs) on the inside interface when they access the outside. (Traffic between VMs is controlled through the use of the Cisco VSG).
The maximum number of concurrent firewall connections allowed on the ASA 1000V is 200,000.
This section includes the following topics:
Security Policy Overview
A security policy determines which traffic is allowed to pass through the firewall to access another network. By default, the ASA 1000V allows traffic to flow freely from a security profile interface on an inside network (higher security level) to an outside network (lower security level). You can apply actions to traffic to customize the security policy.
This section includes the following topics:
Permitting or Denying Traffic with AccessLists (Rules)
You can apply an access rule to limit traffic from the inside security profile to the outside or to allow traffic from the outside to the inside security profile.
Some of the benefits of NAT include the following:
- You can use private addresses on your inside networks. Private addresses are not routable on the Internet.
- NAT hides the local addresses from other networks, so attackers cannot learn the real address of a host.
- NAT can resolve IP routing problems by supporting overlapping IP addresses.
Protection from IP Fragments
The ASA 1000V provides IP fragment protection. This feature performs full reassembly of all ICMP error messages and virtual reassembly of the remaining IP fragments that are routed through the ASA 1000V. Fragments that fail the security check are dropped and logged. Virtual reassembly cannot be disabled.
Applying Application Inspection
Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports.
Applying Connection Limits and TCP Normalization
You can limit TCP and UDP connections and embryonic connections. Limiting the number of connections and embryonic connections protects you from a DoS attack. The ASA 1000V uses the embryonic limit to trigger TCP Intercept, which protects inside systems from a DoS attack that is perpetrated by flooding an interface with TCP SYN packets. An embryonic connection is a connection request that has not finished the necessary handshake between the source and the destination.
TCP normalization is a feature that consists of advanced TCP connection settings designed to drop packets that do not appear normal.
Configuring high availability requires two identical ASA 1000Vs connected to each other through a dedicated Stateful Failover link. The two ASA 1000Vs in a failover pair constantly communicate over a failover link to determine the operating status of each one. The health of the active interfaces is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs.
You can use the GigabitEthernet 0/2 interface on the ASA 1000V as the failover link. The failover link interface is not configured as a normal networking interface; it exists for failover communication only. This interface should only be used for the failover link (and optionally for the Stateful Failover link).
The ASA 1000V only supports Active/Standby failover, in which one ASA 1000V passes traffic while the other ASA 1000V waits in a standby state.
Firewall Mode Overview
The ASA 1000V runs only in routed firewall mode and is considered to be a router hop in the network.
Stateful Inspection Overview
All traffic that goes through the ASA 1000V is inspected using the Adaptive Security Algorithm and either allowed through or dropped. A simple packet filter can check for the correct source address, destination address, and ports, but it does not check that the packet sequence or flags are correct. A filter also checks every packet with the filter, which can be a slow process.
Note The TCP state bypass feature allows you to customize the packet flow. See the “TCP State Bypass” section.
A stateful firewall like the ASA 1000V, however, takes into consideration the state of a packet:
- Is this a new connection?
If it is a new connection, the ASA 1000V has to check the packet against access lists and perform other tasks to determine if the packet is allowed or denied. To perform this check, the first packet of the session goes through the session management path, and depending on the type of traffic, it might also pass through the control plane path.
The session management path is responsible for the following tasks:
– Performing the access list checks
– Performing route lookups
– Allocating NAT translations (xlates)
– Establishing sessions in the fast path
Some packets that require Layer 7 inspection (the packet payload must be inspected or altered) are passed on to the control plane path. Layer 7 inspection engines are required for protocols that have two or more channels: a data channel, which uses well-known port numbers, and a control channel, which uses different port numbers for each session. These protocols include FTP, H.323, and SNMP.
- Is this an established connection?
If the connection is already established, the ASA 1000V does not need to recheck packets; most matching packets can go through the fast path in both directions. The fast path is responsible for the following tasks:
– Verifying the IP checksum
– Performing session lookups
– Checking TCP sequence numbers
– Allocating NAT translations based on existing sessions
– Adjusting Layer 3 and Layer 4 headers
For UDP or other connectionless protocols, the ASA 1000V creates connection state information so that it can also use the fast path.
Data packets for protocols that require Layer 7 inspection can also go through the fast path.
Some established session packets must continue to go through the session management path or the control plane path. Packets that go through the session management path include HTTP packets that require inspection or content filtering. Packets that go through the control plane path include the control packets for protocols that require Layer 7 inspection.
IPsec Site-to-Site VPN Functional Overview
A site-to-site (LAN-to-LAN) VPN connects networks in different geographic locations. The ASA 1000V supports IPsec site-to-site connections (called tunnels) to Cisco or third-party peers when the two peers have IPv4 inside and outside interfaces. IPsec tunnel mode is useful for protecting traffic between different networks when traffic must pass through an intermediate, untrusted network.
The supported protocols for IPsec site-to-site tunnels are IKEv1 and IKEv2 using a preshared key only. A preshared key or shared secret is the string of text that a VPN expects to receive before any other credentials (such as a username and password). Split tunnels are also supported and allow the network administrator to determine which traffic the client passes through the VPN tunnel and which traffic goes straight to the Internet (non-tunneled).
The supported tunnel modes are Encapsulating Security Payload (ESP) alone, and ESP and Authentication Header (AH) combined. AH tunnel mode encapsulates an IP packet with an AH and IP header and signs the entire packet for integrity and authentication. ESP tunnel mode encapsulates an IP packet with both an ESP and IP header and an ESP authentication trailer. ESP and AH can be combined when tunneling, which provides both security for the tunneled IP packet and integrity and authentication for the entire packet.
In addition, NAT traversal is supported and is used by IPsec site-to-site VPN clients to allow ESP packets to traverse NAT.