ASA CHAPTER 13 (Transparent firewall/Arp Inspection)
24. Transparent Firewall
• Use the subnet 136.X.100.0/24 for IP addressing on the segment.
• Configure the IP address 136.X.100.12/24 for the transparent firewall.
• Permit telnet and pings from the lower to higher security zone.
• Ensure the authenticated BGP session between R3 and R1 could be
established across the firewall.
• Allow R3 and R1 to establish OSPF and PIM neighbor adjacencies.
25. ARP Inspection
• The firewall should enforce consistency in ARP requests and responses.
• Manually configure the IP to MAC address mappings for R3 and R1 Fast
Ethernet interfaces to accomplish this.
• Do not flood unmatched ARP requests between the security levels.
-----------
24. Transparent Firewall
• Use the subnet 136.X.100.0/24 for IP addressing on the segment.
• Configure the IP address 136.X.100.12/24 for the transparent firewall.
• Permit telnet and pings from the lower to higher security zone.
• Ensure the authenticated BGP session between R3 and R1 could be
established across the firewall.
• Allow R3 and R1 to establish OSPF and PIM neighbor adjacencies.
Solution:
-->
-->
Transparent firewall mode turns appliance into a layer 2 bridging device. In this
mode, the firewall acts as a bump on the wire, inspecting traffic transparently as
it flows though. The hosts on the network do not see the firewall as a routing hop.
When configuring the transparent firewall, you do not assign any IP addresses to
the interfaces. However, every interface still needs to have name and securitylevel configured. You must assign an IP address to the firewall unit itself, or it
won’t allow any IP traffic through. Also, the firewall supports a maximum of two
active interfaces (usually the inside and the outside).
As any bridge, the firewall builds MAC address table associated with the
interfaces. You can review this table using the command show mac-addresstable. You may even statically associate MAC addresses with the interfaces
using the command mac-address-table static {inside|outside}
<MAC>if you want to bind the station to a security zone.
The firewall will forward frames based on the destination MAC addresses and the
bridging table. At the same time, it will perform stateful inspection of the traffic
moving from the higher to lower security levels by default. However, some critical
layer 2 traffic is permitted to move from the lower security zone as well, such as:
1) ARP requests and responses - needed to permit IP address resolution. You
may still control ARP packets flow using ARP inspection.
2) Spanning Tree BPDUs are permitted to allow for loop-less topology calculation
by STP algorithm.
However, the firewall only permits IEEE BPDUs and untaggedPVST BPDUs.
Therefore, you want to ensure STP traffic is not blocked by the firewall, you must
observe two rules, when connecting using Cisco switches:
1) Firewall interfaces connect to the access ports in the same VLANs. Cisco
switches send IEEE STP BPDUs out of access ports.
2) Firewall interfaces connect to dot1q trunk links with only one allowed VLAN
which is native on the trunks. In this case, only untagged SSTP BPDUs and IEEE
STP BPDUs are sent by Cisco switches.
In our scenario, the firewall is connected to the access-ports on different
switches. The spanning-tree const on the trunk link connecting two switches is
configured with high STP cost value. This makes the link across the firewall more
preferred by STP than the trunk link between the switches (the trunk is blocked
by STP on VLAN100). Configurations like that one allow for redundancy – if the
firewall fails, the secondary link would unblock and allow traffic to go across the
VLAN unfiltered.
Some other non-IP traffic types (IPX, Apple-Talk and MPLS) could be permitted
using Ethertype access-lists. However, the firewall does not permit protocols like
CDP, ISIS (CLNS) and IPv6 to go through. All unicast IP traffic is permitted from
higher to lower security zones. As usual, only the inspected traffic (HTTP, DNS
and FTP etc) is permitted to return back. As for multicast and broadcast traffic,
the firewall permits UDP multicast (such as RIP, DHCP) to flow from inside to
outside without an explicit permission. Other types of multicast traffic (e.g. OSPF,
PIM, IGMP) should be explicitly permitted even on the inside interface. All traffic
from the outside should be permitted explicitly as well (with except to ARP and
STP BPDUs).
Our scenario requires configuring explicit permissions for ICMP and Telnet traffic
entering from the outside. Additionally, we have to permit OSPF and PIM on both
inside and outside interfaces. Since we apply the inside access-list, we permit
UDP, TCP and ICMP traffic explicitly. Also, some additional tuning is needed to
permit BGP traffic across the firewall, as usual – enabling TCP option 19 and
disabling Initial Sequence Number randomization.
To configure the firewall as a transparent firewall, the command from
configuration mode is “firewall transparent”. To change back to routed mode,
the command is “no firewall transparent”. This command applies to single mode
as well as multiple mode. In multiple mode, apply the command in the system
execution space.
-->
ASA1:
firewall transparent
hostname ASA1
!
! Appliance’s IP address
!
ip address 136.1.100.12 255.255.255.0
!
interface Ethernet 0/0
no shutdown
nameif outside
!
interface Ethernet 0/1
no shutdown
nameif inside
!
! Access-List to apply to outside
!
access-list OUTSIDE_IN permit icmp any any echo
access-list OUTSIDE_IN permit icmp any any echo-reply
access-list OUTSIDE_IN permit tcp any any eq telnet
access-list OUTSIDE_IN permit ospf any any
access-list OUTSIDE_IN permit pim any any
access-group OUTSIDE_IN in interface outside
access-list INSIDE_IN permit ospf any any
access-list INSIDE_IN permit pim any any
access-list INSIDE_IN permit tcp any any
access-list INSIDE_IN permit udp any any
access-list INSIDE_IN permit icmp any any
access-group INSIDE_IN in interface inside
class-map BGP
match port tcp eq 179
!
tcp-map BGP
tcp-options range 19 19 allow
!
policy-map global_policy
class BGP
set connection random-sequence-number disable
set connection advanced-options BGP
!
And then check the output as : sh ip ospf neighbor, sh ip bgp summary.
25. ARP Inspection
• The firewall should enforce consistency in ARP requests and responses.
• Manually configure the IP to MAC address mappings for R3 and R1 Fast
Ethernet interfaces to accomplish this.
• Do not flood unmatched ARP requests between the security levels.
-->
ARP traffic is permitted to flow across the transparent firewall to facilitate in IP
address resolution. However, certain types of network attacks utilize ARP and
might compromise your network security. Most common attack is know as ARP
spoofing, where a malicious user sends crafted ARP packets, to poison other
hosts ARP cache and pretend it is operating under a different IP address. This
allows an attacker to attract traffic not intended for it, for example by taking over
the default gateway’s IP.
ARP inspection prevents this type of attacks by looking inside the ARP
replies/responses and seeing that the IP to MAC address bindings inside match
the pre-configured table. In order to activate this feature, you must first populate
the static bindings table using the command arp {iface} <IP> <MAC>which
binds the IP to the MAC on the particular interface. To enable ARP inspection for
ARP packets entering a particular interface use the command arp-inspection
{iface} enable [flood|no-flood].The floodoption permits ARP
packets that contains IP addresses not matching the static table to be flooded out
on other interfaces. The no-floodoption will permit only valid ARP packets for
IP addresses in the inspection table.
Unlike ARP Inspection in the Catalyst switches, the ASA firewall cannot use
DHCP snooping to populate the ARP bindings table. Therefore, all configuration
burden lies on the system administrator.
-->
ASA1:
arp inside 136.1.100.3 000f.8f14.ad20
arp outside 136.1.100.4 000f.90fb.2d21
!
arp-inspection outside enable no-flood
arp-inspection inside enable no-flood
!
Rack1R3#ping 136.1.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.100.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Rack1R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R3(config)#interface fastEthernet 0/0
Rack1R3(config-if)#mac-address 000f.90fb.2d22
Rack1R3#ping 136.1.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.100.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
!
Firewall Contexts
• Configure the ASA firewall to support multiple contexts mode per the
following requirements:
o Context “CustomerA” interfaces: E0/1.121 (“InsideA”), E0/2
(“DMZ”), E0/0 (“Outside”).
o Context “CustomerB” interfaces: E0/1.122 (“InsideB”), E0/2
(“DMZ”), E0/0 (“Outside”) with the security levels of 100, 50 and 0
respectively.
o Use the security levels of 100, 50 and 0 for the “Inside”, “DMZ” and
“Outside” interfaces respectively.
• The “DMZ” and “Outside” interfaces are shared between the contexts.
• Create a separate administrative context named “Admin”
• Refer to the diagram to configure the interfaces IP addresses (Note that
the IP subnets on the Inside interfaces overlap intentionally).
if you want to make gns3 asa to run in multiple mode , use this command when the asa is booting:
/asa/bin/lina –m
ASA1/System:
!
! Configure physical interfaces
!
interface Ethernet0/0
no shutdown
!
interface Ethernet0/1
no shutdown
!
interface Ethernet0/1.121
vlan 121
no shutdown
!
interface Ethernet0/1.122
vlan 122
no shutdown
!
interface Ethernet0/2
no shutdown
!
! Identify admin context first
!
admin-context admin
context admin
config-url disk0:/admin.cfg
!
! Create context CustomerA and add interface
! Map interfaces to their “virtual” names
!
context CustomerA
description == CustomerA
allocate-interface Ethernet0/0 outside
allocate-interface Ethernet0/1.121 insideA
allocate-interface Ethernet0/2 dmz
config-url disk0:/CustomerA.cfg
!
! Create context CustomerB
!
context CustomerB
description == CustomerB
allocate-interface Ethernet0/0 outside
allocate-interface Ethernet0/1.122 insideB
allocate-interface Ethernet0/2 dmz
config-url disk0:/CustomerB.cfg
ASA1/CustomerA:
!
! Change to context CustomerA
!
changeto context CustomerA
!
! Configure security-levels & IP addressing for interfaces
!
interface insideA
nameif inside
security-level 100
ip address 136.1.0.12 255.255.255.0
!
interface dmz
nameif dmz
security-level 50
ip address 136.1.124.121 255.255.255.0
!
interface outside
nameif outside
security-level 0
ip address 136.1.123.121 255.255.255.0
ASA1/CustomerB:
!
! Change to context “CustomerB” and configure
!
changeto context CustomerB
!
interface insideB
nameif inside
security-level 100
ip address 136.1.0.12 255.255.255.0
!
interface dmz
nameif dmz
security-level 50
ip address 136.1.124.122 255.255.255.0
!
interface outside
nameif outside
security-level 0
ip address 136.1.123.122 255.255.255.0
Firewall Contexts Routing
• Both R1 and R2 are preconfigured to use the firewall as their default
gateway.
• Both security contexts in the ASA should use R3 as the default gateway.
• Ensure that both firewall contexts can reach R4’s Loopback0 interface
subnet as well.
ASA1/CustomerA:
!
! Change to context CustomerA
!
changeto context CustomerA
!
! Static routes - dynamic routing is not possible with fw contexts
!
route outside 0.0.0.0 0.0.0.0 136.1.123.3 1
route dmz 150.1.4.0 255.255.255.0 136.1.124.4 1
ASA1/CustomerB:
!
! Routing
!
route outside 0.0.0.0 0.0.0.0 136.1.123.3 1
route dmz 150.1.4.0 255.255.255.0 136.1.124.4 1
!
Resource Management
• Allocate the Management interface to the admin context created
previously, using the interface name “Mgmt”.
• Configure the interface per the diagram using the security level of 100.
• Allow SSH and Telnet connections on the management interface and
authenticate the remote connections using the local username/password
pair “ADMIN/CISCO”.
• The context “CustomerA” should be allowed to have no more than 1000
host and NAT translation entries. The number of concurrent connections
should be limited to 10000.
• The context “CustomerB” should be limited to no more than 500 host and
xlate entries, and no more than 5000 connections.
• The admin context should use the default resource limits.
ASA1/System:
admin-context admin
context admin
allocate-interface Management0/0 Mgmt
config-url disk0:/admin.cfg
!
class Gold
limit-resource Hosts 1000
limit-resource Xlates 1000
limit-resource Conns 10000
!
class Silver
limit-resource Hosts 500
limit-resource Conns 5000
limit-resource Xlates 500
!
context admin
member default
!
context CustomerA
member Gold
!
context CustomerB
member Silver
ASA1/Admin:
!
! Configure admin context
!
changeto context admin
interface Mgmt
nameif management
!
Failover provides redundancy between the appliances, so if one appliance fails, you can have a redundant appliance take over the failed one. So most of the companies will implement the failover for network security and redundancy.
Failover is a Cisco-proprietary feature unique to the security appliance. Failover provides redundancy between paired appliances: one appliance backs up another appliance. This section will introduce failover concepts.
Failover implementations
There are two implementations that cisco supports for failover.
Active/Standby
Active/Active
Here we are going to learn about Active/Active failover in the ASA
Taken from blog: run992.blogspot.in/2012/06/configuring-activeactive-failover-in.html , only for learning purpose.
Interview Related Question:
Please follow the link below:
http://networkerinterview.net/entries/asa-firewall/asa-firewall-interview-questions-and-answers
24. Transparent Firewall
• Use the subnet 136.X.100.0/24 for IP addressing on the segment.
• Configure the IP address 136.X.100.12/24 for the transparent firewall.
• Permit telnet and pings from the lower to higher security zone.
• Ensure the authenticated BGP session between R3 and R1 could be
established across the firewall.
• Allow R3 and R1 to establish OSPF and PIM neighbor adjacencies.
25. ARP Inspection
• The firewall should enforce consistency in ARP requests and responses.
• Manually configure the IP to MAC address mappings for R3 and R1 Fast
Ethernet interfaces to accomplish this.
• Do not flood unmatched ARP requests between the security levels.
-----------
24. Transparent Firewall
• Use the subnet 136.X.100.0/24 for IP addressing on the segment.
• Configure the IP address 136.X.100.12/24 for the transparent firewall.
• Permit telnet and pings from the lower to higher security zone.
• Ensure the authenticated BGP session between R3 and R1 could be
established across the firewall.
• Allow R3 and R1 to establish OSPF and PIM neighbor adjacencies.
Solution:
-->
-->
mode, the firewall acts as a bump on the wire, inspecting traffic transparently as
it flows though. The hosts on the network do not see the firewall as a routing hop.
When configuring the transparent firewall, you do not assign any IP addresses to
the interfaces. However, every interface still needs to have name and securitylevel configured. You must assign an IP address to the firewall unit itself, or it
won’t allow any IP traffic through. Also, the firewall supports a maximum of two
active interfaces (usually the inside and the outside).
As any bridge, the firewall builds MAC address table associated with the
interfaces. You can review this table using the command show mac-addresstable. You may even statically associate MAC addresses with the interfaces
using the command mac-address-table static {inside|outside}
<MAC>if you want to bind the station to a security zone.
The firewall will forward frames based on the destination MAC addresses and the
bridging table. At the same time, it will perform stateful inspection of the traffic
moving from the higher to lower security levels by default. However, some critical
layer 2 traffic is permitted to move from the lower security zone as well, such as:
1) ARP requests and responses - needed to permit IP address resolution. You
may still control ARP packets flow using ARP inspection.
2) Spanning Tree BPDUs are permitted to allow for loop-less topology calculation
by STP algorithm.
However, the firewall only permits IEEE BPDUs and untaggedPVST BPDUs.
Therefore, you want to ensure STP traffic is not blocked by the firewall, you must
observe two rules, when connecting using Cisco switches:
1) Firewall interfaces connect to the access ports in the same VLANs. Cisco
switches send IEEE STP BPDUs out of access ports.
2) Firewall interfaces connect to dot1q trunk links with only one allowed VLAN
which is native on the trunks. In this case, only untagged SSTP BPDUs and IEEE
STP BPDUs are sent by Cisco switches.
In our scenario, the firewall is connected to the access-ports on different
switches. The spanning-tree const on the trunk link connecting two switches is
configured with high STP cost value. This makes the link across the firewall more
preferred by STP than the trunk link between the switches (the trunk is blocked
by STP on VLAN100). Configurations like that one allow for redundancy – if the
firewall fails, the secondary link would unblock and allow traffic to go across the
VLAN unfiltered.
Some other non-IP traffic types (IPX, Apple-Talk and MPLS) could be permitted
using Ethertype access-lists. However, the firewall does not permit protocols like
CDP, ISIS (CLNS) and IPv6 to go through. All unicast IP traffic is permitted from
higher to lower security zones. As usual, only the inspected traffic (HTTP, DNS
and FTP etc) is permitted to return back. As for multicast and broadcast traffic,
the firewall permits UDP multicast (such as RIP, DHCP) to flow from inside to
outside without an explicit permission. Other types of multicast traffic (e.g. OSPF,
PIM, IGMP) should be explicitly permitted even on the inside interface. All traffic
from the outside should be permitted explicitly as well (with except to ARP and
STP BPDUs).
Our scenario requires configuring explicit permissions for ICMP and Telnet traffic
entering from the outside. Additionally, we have to permit OSPF and PIM on both
inside and outside interfaces. Since we apply the inside access-list, we permit
UDP, TCP and ICMP traffic explicitly. Also, some additional tuning is needed to
permit BGP traffic across the firewall, as usual – enabling TCP option 19 and
disabling Initial Sequence Number randomization.
To configure the firewall as a transparent firewall, the command from
configuration mode is “firewall transparent”. To change back to routed mode,
the command is “no firewall transparent”. This command applies to single mode
as well as multiple mode. In multiple mode, apply the command in the system
execution space.
-->
ASA1:
firewall transparent
hostname ASA1
!
! Appliance’s IP address
!
ip address 136.1.100.12 255.255.255.0
!
interface Ethernet 0/0
no shutdown
nameif outside
!
interface Ethernet 0/1
no shutdown
nameif inside
!
! Access-List to apply to outside
!
access-list OUTSIDE_IN permit icmp any any echo
access-list OUTSIDE_IN permit icmp any any echo-reply
access-list OUTSIDE_IN permit tcp any any eq telnet
access-list OUTSIDE_IN permit ospf any any
access-list OUTSIDE_IN permit pim any any
access-group OUTSIDE_IN in interface outside
access-list INSIDE_IN permit ospf any any
access-list INSIDE_IN permit pim any any
access-list INSIDE_IN permit tcp any any
access-list INSIDE_IN permit udp any any
access-list INSIDE_IN permit icmp any any
access-group INSIDE_IN in interface inside
class-map BGP
match port tcp eq 179
!
tcp-map BGP
tcp-options range 19 19 allow
!
policy-map global_policy
class BGP
set connection random-sequence-number disable
set connection advanced-options BGP
!
And then check the output as : sh ip ospf neighbor, sh ip bgp summary.
25. ARP Inspection
• The firewall should enforce consistency in ARP requests and responses.
• Manually configure the IP to MAC address mappings for R3 and R1 Fast
Ethernet interfaces to accomplish this.
• Do not flood unmatched ARP requests between the security levels.
-->
ARP traffic is permitted to flow across the transparent firewall to facilitate in IP
address resolution. However, certain types of network attacks utilize ARP and
might compromise your network security. Most common attack is know as ARP
spoofing, where a malicious user sends crafted ARP packets, to poison other
hosts ARP cache and pretend it is operating under a different IP address. This
allows an attacker to attract traffic not intended for it, for example by taking over
the default gateway’s IP.
ARP inspection prevents this type of attacks by looking inside the ARP
replies/responses and seeing that the IP to MAC address bindings inside match
the pre-configured table. In order to activate this feature, you must first populate
the static bindings table using the command arp {iface} <IP> <MAC>which
binds the IP to the MAC on the particular interface. To enable ARP inspection for
ARP packets entering a particular interface use the command arp-inspection
{iface} enable [flood|no-flood].The floodoption permits ARP
packets that contains IP addresses not matching the static table to be flooded out
on other interfaces. The no-floodoption will permit only valid ARP packets for
IP addresses in the inspection table.
Unlike ARP Inspection in the Catalyst switches, the ASA firewall cannot use
DHCP snooping to populate the ARP bindings table. Therefore, all configuration
burden lies on the system administrator.
-->
ASA1:
arp inside 136.1.100.3 000f.8f14.ad20
arp outside 136.1.100.4 000f.90fb.2d21
!
arp-inspection outside enable no-flood
arp-inspection inside enable no-flood
!
Rack1R3#ping 136.1.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.100.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Rack1R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R3(config)#interface fastEthernet 0/0
Rack1R3(config-if)#mac-address 000f.90fb.2d22
Rack1R3#ping 136.1.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.100.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
!
Firewall Contexts
• Configure the ASA firewall to support multiple contexts mode per the
following requirements:
o Context “CustomerA” interfaces: E0/1.121 (“InsideA”), E0/2
(“DMZ”), E0/0 (“Outside”).
o Context “CustomerB” interfaces: E0/1.122 (“InsideB”), E0/2
(“DMZ”), E0/0 (“Outside”) with the security levels of 100, 50 and 0
respectively.
o Use the security levels of 100, 50 and 0 for the “Inside”, “DMZ” and
“Outside” interfaces respectively.
• The “DMZ” and “Outside” interfaces are shared between the contexts.
• Create a separate administrative context named “Admin”
• Refer to the diagram to configure the interfaces IP addresses (Note that
the IP subnets on the Inside interfaces overlap intentionally).
if you want to make gns3 asa to run in multiple mode , use this command when the asa is booting:
/asa/bin/lina –m
ASA1/System:
!
! Configure physical interfaces
!
interface Ethernet0/0
no shutdown
!
interface Ethernet0/1
no shutdown
!
interface Ethernet0/1.121
vlan 121
no shutdown
!
interface Ethernet0/1.122
vlan 122
no shutdown
!
interface Ethernet0/2
no shutdown
!
! Identify admin context first
!
admin-context admin
context admin
config-url disk0:/admin.cfg
!
! Create context CustomerA and add interface
! Map interfaces to their “virtual” names
!
context CustomerA
description == CustomerA
allocate-interface Ethernet0/0 outside
allocate-interface Ethernet0/1.121 insideA
allocate-interface Ethernet0/2 dmz
config-url disk0:/CustomerA.cfg
!
! Create context CustomerB
!
context CustomerB
description == CustomerB
allocate-interface Ethernet0/0 outside
allocate-interface Ethernet0/1.122 insideB
allocate-interface Ethernet0/2 dmz
config-url disk0:/CustomerB.cfg
ASA1/CustomerA:
!
! Change to context CustomerA
!
changeto context CustomerA
!
! Configure security-levels & IP addressing for interfaces
!
interface insideA
nameif inside
security-level 100
ip address 136.1.0.12 255.255.255.0
!
interface dmz
nameif dmz
security-level 50
ip address 136.1.124.121 255.255.255.0
!
interface outside
nameif outside
security-level 0
ip address 136.1.123.121 255.255.255.0
ASA1/CustomerB:
!
! Change to context “CustomerB” and configure
!
changeto context CustomerB
!
interface insideB
nameif inside
security-level 100
ip address 136.1.0.12 255.255.255.0
!
interface dmz
nameif dmz
security-level 50
ip address 136.1.124.122 255.255.255.0
!
interface outside
nameif outside
security-level 0
ip address 136.1.123.122 255.255.255.0
Firewall Contexts Routing
• Both R1 and R2 are preconfigured to use the firewall as their default
gateway.
• Both security contexts in the ASA should use R3 as the default gateway.
• Ensure that both firewall contexts can reach R4’s Loopback0 interface
subnet as well.
ASA1/CustomerA:
!
! Change to context CustomerA
!
changeto context CustomerA
!
! Static routes - dynamic routing is not possible with fw contexts
!
route outside 0.0.0.0 0.0.0.0 136.1.123.3 1
route dmz 150.1.4.0 255.255.255.0 136.1.124.4 1
ASA1/CustomerB:
!
! Routing
!
route outside 0.0.0.0 0.0.0.0 136.1.123.3 1
route dmz 150.1.4.0 255.255.255.0 136.1.124.4 1
!
Resource Management
• Allocate the Management interface to the admin context created
previously, using the interface name “Mgmt”.
• Configure the interface per the diagram using the security level of 100.
• Allow SSH and Telnet connections on the management interface and
authenticate the remote connections using the local username/password
pair “ADMIN/CISCO”.
• The context “CustomerA” should be allowed to have no more than 1000
host and NAT translation entries. The number of concurrent connections
should be limited to 10000.
• The context “CustomerB” should be limited to no more than 500 host and
xlate entries, and no more than 5000 connections.
• The admin context should use the default resource limits.
ASA1/System:
admin-context admin
context admin
allocate-interface Management0/0 Mgmt
config-url disk0:/admin.cfg
!
class Gold
limit-resource Hosts 1000
limit-resource Xlates 1000
limit-resource Conns 10000
!
class Silver
limit-resource Hosts 500
limit-resource Conns 5000
limit-resource Xlates 500
!
context admin
member default
!
context CustomerA
member Gold
!
context CustomerB
member Silver
ASA1/Admin:
!
! Configure admin context
!
changeto context admin
interface Mgmt
nameif management
!
FIREWALL FAILOVER
Active/Standby Failover
• Configure ASA1 and ASA2 into standby failover pair, with ASA1 as the
active unit. Use the hostname “ASA” for the pair.
• Configure the IP addressing in the primary unit per the diagram, and
enable RIP as the routing protocol on the inside interface.
• Make the configurations necessary to allow the inside hosts to ping the
outside destinations.
• Configure stateful failover using E0/2 as the failover link with the name
“Failover” and the IP subnet 100.0.0.0/24.
• Assign the IP addresses for the standby unit per the diagram.
• Use the last octet of .254 as for the virtual IP address on both “Inside” and
“Outside” segments.
• The units should monitor each other across both interfaces using the
minimum poll times.
ASA1:
hostname Rack1ASA
!
! Configure basic interface settings
!
interface Ethernet0/1
nameif inside
ip address 136.1.110.12 255.255.255.0 standby 136.1.110.13
no shutdown
!
interface Ethernet0/0
nameif outside
ip address 136.1.120.12 255.255.255.0 standby 136.1.120.13
no shutdown
!
router rip
version 2
no auto-summary
network 136.1.0.0
!
nat-control
nat (inside) 1 0 0
global (outside) 1 interface
!
! Access-control
!
access-list OUTSIDE_IN permit icmp any any echo-reply
access-group OUTSIDE_IN in interface outside
!
! Enable the failover interface
!
interface Ethernet0/2
no shut
!
! Configure failover settings
!
failover lan unit primary
failover lan interface failover Ethernet0/2
failover link failover Ethernet0/2
failover interface ip failover 100.100.100.12 255.255.255.0 standby
100.100.100.13
failover
!
! Configure interface monitoring and failover policy
!
monitor-interface outside
monitor-interface inside
!
! Unit & interface polling
!
failover polltime unit msec 200 holdtime msec 800
failover polltime interface msec 500 holdtime 5
!
failover interface-policy 1
ASA2:
interface Ethernet0/2
no shut
!
failover lan unit secondary
failover lan interface failover Ethernet0/2
failover link failover Ethernet0/2
failover interface ip failover 100.100.100.12 255.255.255.0 standby 100.100.100.13
failover
Active/Standby Failover
• Configure ASA1 and ASA2 into standby failover pair, with ASA1 as the
active unit. Use the hostname “ASA” for the pair.
• Configure the IP addressing in the primary unit per the diagram, and
enable RIP as the routing protocol on the inside interface.
• Make the configurations necessary to allow the inside hosts to ping the
outside destinations.
• Configure stateful failover using E0/2 as the failover link with the name
“Failover” and the IP subnet 100.0.0.0/24.
• Assign the IP addresses for the standby unit per the diagram.
• Use the last octet of .254 as for the virtual IP address on both “Inside” and
“Outside” segments.
• The units should monitor each other across both interfaces using the
minimum poll times.
ASA1:
hostname Rack1ASA
!
! Configure basic interface settings
!
interface Ethernet0/1
nameif inside
ip address 136.1.110.12 255.255.255.0 standby 136.1.110.13
no shutdown
!
interface Ethernet0/0
nameif outside
ip address 136.1.120.12 255.255.255.0 standby 136.1.120.13
no shutdown
!
router rip
version 2
no auto-summary
network 136.1.0.0
!
nat-control
nat (inside) 1 0 0
global (outside) 1 interface
!
! Access-control
!
access-list OUTSIDE_IN permit icmp any any echo-reply
access-group OUTSIDE_IN in interface outside
!
! Enable the failover interface
!
interface Ethernet0/2
no shut
!
! Configure failover settings
!
failover lan unit primary
failover lan interface failover Ethernet0/2
failover link failover Ethernet0/2
failover interface ip failover 100.100.100.12 255.255.255.0 standby
100.100.100.13
failover
!
! Configure interface monitoring and failover policy
!
monitor-interface outside
monitor-interface inside
!
! Unit & interface polling
!
failover polltime unit msec 200 holdtime msec 800
failover polltime interface msec 500 holdtime 5
!
failover interface-policy 1
ASA2:
interface Ethernet0/2
no shut
!
failover lan unit secondary
failover lan interface failover Ethernet0/2
failover link failover Ethernet0/2
failover interface ip failover 100.100.100.12 255.255.255.0 standby 100.100.100.13
failover
Active/Active Failover
Failover provides redundancy between the appliances, so if one appliance fails, you can have a redundant appliance take over the failed one. So most of the companies will implement the failover for network security and redundancy.
Failover is a Cisco-proprietary feature unique to the security appliance. Failover provides redundancy between paired appliances: one appliance backs up another appliance. This section will introduce failover concepts.
Failover implementations
There are two implementations that cisco supports for failover.
Active/Standby
Active/Active
Here we are going to learn about Active/Active failover in the ASA
In the active/active
implementation of failover, both appliances will process the traffic. To
implement active/active failover, two contexts are needed. Failover can occur
if a context is fails or if the entire appliance fails.
Configuration of Active/Active
failover is some simple steps. But when you are doing it in GNS3, you
must be careful about the switch configurations.
Here in the picture you can see
both switches are connected with ASA. The connected ports must be in the
same vlan (example: vlan 1) and must be in trunk (example: dot1q).
Now the following steps are the configuration of Active/Active Failover
ASA1
Ciscoasa(config)#hostname asa1
Asa1(config)#int e0/0
Asa1(config-if)#no shut
Asa1(config-if)#int e0/1
Asa1(config-if)#no shut
Asa1(config-if)#int e0/2
Asa1(config-if)#no shut
Asa1(config-if)#int e0/3
Asa1(config-if)#no shut
Creating virtual interfaces for contexts
Asa1(config)#int e0/0.1
Asa1(config-if)#vlan 3
Asa1(config-if)#no shut
Asa1(config-if)#int e0/0.2
Asa1(config-if)#vlan 5
Asa1(config-if)#no shut
Asa1(config-if)#int e0/1.1
Asa1(config-if)#vlan 2
Asa1(config-if)#no shut
Asa1(config-if)#int e0/1.2
Asa1(config-if)#vlan 4
Asa1(config-if)#no shut
Asa1(config-if)#exit
Create two failover groups for adding the contexts
Asa1(config)#failover group
1
Asa1(config-fover-group)#exit
Asa1(config)#failover group
2
Asa1(config-fover-group)#exit
Creating contexts and allocating interfaces to contexts
Asa1(config)#admin-context admin
Asa1(config)#context admin
Asa1(config-ctx)#config-url disk0:/.private/admin.cfg
Creating context c1
Asa1(config-ctx)#context c1
Asa1(config-ctx)#allocate-interface e0/0.1
Asa1(config-ctx)#allocate-interface e0/1.1
Asa1(config-ctx)#join-failover-group 1
Asa1(config-ctx)#config-url disk0:/.private/c1.cfg
Creating context c2
Asa1(config-ctx)#context c2
Asa1(config-ctx)#allocate-interface e0/0.2
Asa1(config-ctx)#allocate-interface e0/1.2
Asa1(config-ctx)#join-failover-group 2
Asa1(config-ctx)#config-url disk0:/.private/c2.cfg
Setting IP for the virtual interfaces in contexts
Asa1(config-ctx)#changeto context
c1
Asa1/c1(config)#int e0/0.1
Asa1/c1(config-if)#nameif inside
Asa1/c1(config-if)#ip add
172.16.1.1 255.255.255.0 standby
172.16.1.2
Asa1/c1(config-if)#no shut
Asa1/c1(config-if)#int e0/1.1
Asa1/c1(config-if)#nameif outside
Asa1/c1(config-if)#ip add
172.16.2.1 255.255.255.0 standby
172.16.2.2
Asa1/c1(config-if)#no shut
Asa1/c1(config-if)#changeto context
c2
Asa1/c2(config)#interface e0/0.2
Asa1/c2(config-if)#nameif inside
Asa1/c2(config-if)#ip add
192.168.1.1 255.255.255.0 standby
192.168.1.2
Asa1/c2(config-if)#no shut
Asa1/c2(config-if)#int e0/1.2
Asa1/c2(config-if)#nameif outside
Asa1/c2(config-if)#ip add
192.168.2.1 255.255.255.0 standby
192.168.2.2
Asa1/c2(config-if)#no shut
Asa1/c2(config-if)#exit
Asa1/c2(config)#exit
Asa1(config)#failover lan
interface LANFO e0/2
Asa1(config)#failover link
LANFO
Asa1(config)#failover interface ip
LANFO 192.168.20.1 255.255.255.0 standby
192.168.20.2
Asa1(config)#failover lan
unit primary
Asa1(config)#failover polltime
msec 500
ASA2
Asa2(config)#int e0/0
Asa2(config-if)#no
shut
Asa2(config-if)#int
e0/1
Asa2(config-if)#no
shut
Asa2(config-if)#int
e0/2
Asa2(config-if)#no
shut
Asa2(config-if)#int
e0/3
Asa2(config-if)#no
shut
Asa2(config)#failover lan
unit secondary
Asa2(config)#failover lan
interface LANFO e0/2
Asa2(config)#failover interface
ip LANFO 192.168.20.1 255.255.255.0 standby
192.168.20.2
Create an Admin Context
Asa2(config)#admin-context admin
Asa2(config)#context admin
Asa2(config-ctx)#config-url disk0:/.private/admin.cfg
After the configuration, to make the failover working,
you have to use the command failover in both appliances.
For the correct working of Active/active failover, you have to
enter some more commands in the primary ASA
Asa1(config)#
failover group 1
Asa2(config-fover-group)#primary
Asa2(config-fover-group)#preempt
Asa2(config-fover-group)#exit
Asa2(config)#failover
group 2
Asa2(config-fover-group)#secondary
Asa2(config-fover-group)#preempt
Asa2(config-fover-group)#exit
Interview Related Question:
Please follow the link below:
http://networkerinterview.net/entries/asa-firewall/asa-firewall-interview-questions-and-answers
No comments:
Post a Comment