ASA Transparent Mode

  • Post author:
  • Post category:ASA / Cisco

The Cisco ASA software supports two firewall modes, routed and transparent. A transparent firewall is a layer 2 firewall that acts like a stealth firewall and is not seen as a router hop between connected devices. Unlike a traditional deployment of a firewall in routed mode, where the firewall is a routed hop between networks. The transparent firewall controls traffic between interfaces using access-lists, the same as a firewall in routed mode.

Bridge groups are used to achieve layer 2 connectivity, where interfaces are grouped together, and the ASA uses bridging techniques to pass traffic between the interfaces. Each bridge group includes a Bridge Virtual Interface (BVI) to which an IP address must be assigned for the ASA to pass traffic.

The following are key points regarding transparent on ASA as of version 9.14.

  • Each directly connected network must be on the same subnet
  • A default route is required only to provide return path for management traffic.
  • Bidirectional Forwarding Detection (BFD) echo packets are not allowed through the ASA when using bridge group members, because they have the same source and destination IP address and considered a LAND attack.
  • You can create up to 250 bridge groups, with 64 interfaces per bridge group.
  • Bridge group traffic is isolated from other bridge groups, traffic is not routed to another bridge group.
  • The BVI IP address should NOT act as the default gateway for connected device, the default gateway should be a device on the other side of the ASA.
  • ARP is permitted in both directions by default.

Reference: –https://www.cisco.com/c/en/us/td/docs/security/asa/asa914/configuration/general/asa-914-general-config/interface-routed-tfw.html

Ethertype

The following are key points regarding ethertypes when the ASA is configured in transparent mode: –

  • The only ethertype permitted by default through a “transparent” firewall is an IP packet (0x800).
  • Any other ethertype must be explicitly permitted using a Ethertype ACL, in both directions.
  • BPDUs are passed by default
  • BPDUs may want to be blocked in Active/Standby failover, to block BPDUs and prevent the switchport going into a block state when the topology changes.

Example ethertype ACL configuration:

access-list ETHERTYPE-ACL ethertype permit dap|bpdu|ipx|mpls-unicast|mpls-multicast|isis|any
access-group ETHERTYPE-ACL in interface INSIDE
access-group ETHERTYPE-ACL in interface OUTSIDE

More information on Ethertype ACLs can be found here https://www.cisco.com/c/en/us/td/docs/security/asa/asa92/configuration/general/asa-general-cli/acl-ethertype.pdf

Multicast traffic

High to Low security level implicit rules applies to unicast traffic only, it does not apply to multicast traffic. So therefore, when establishing an adjacency using dynamic routing protocols, inside to outside multicast traffic must be permitted inbound on the inside interface using an access-list. You would also need to permit from Low security level (OUTSIDE) to High security level (INSIDE), which by default is denied, inbound on the outside interface.

access-list INSIDE_OUT permit eigrp any any
access-list INSIDE_OUT permit tcp any any
access-list INSIDE_OUT permit udp any any
access-list INSIDE_OUT permit icmp any any
access-group INSIDE_OUT in interface OUTSIDE

or permit ip any any – would also permit the multicast traffic.

ARP Inspection

ARP inspection is configurable in transparent mode and useful to stop spoofing attacks of the Layer 2 address of another host, for traffic that flows through the ASA. ARP Inspection could be used to protect the default gateway or other important systems’ L2 address.

  • ARP packets are allowed through the ASA in both directions, by default.
  • Is disabled as default
  • Can be enabled on one or both interfaces
  • Static ARP entries must be configured for ARP Inspection is start working, without ARP packets are still allowed.
  • Any ARP packets flowing through the ASA is checked against the static ARP entry regarding the MAC address, IP address and interface. If there is a mismatch, then the ARP packet is dropped.
  • If traffic exactly matches the static ARP entry, the ARP traffic is forwarded.
  • If the traffic neither conflicts or does not match the static ARP entry, the ARP traffic is forwarded if the “FLOOD” option is selected or if the “NO-FLOOD” option is selected the traffic is dropped.

To protect the default gateway, we enable the ARP Inspection on the interface and configure a static ARP entry.

arp-inspection <INTERFACE> enable no-flood|flood
arp <INTERFACE> <IP ADDRESS> <MAC ADDRESS>

Network Address Translation

An ASA is Transparent mode supports NAT, the following is a summary of limitations that applies:

  • If the translated address is not on the same network as the global IP address of the ASA, a static route must be added to the upstream router.
  • Interface Static or Dynamic PAT is not supported, as there is no physical IP address on the ASAs interface.
  • You must assign a static route on the ASA if the original IP address is one or more hops away. The ASA performs a route lookup rather than a MAC address lookup.

Unsupported Features

The following is a summary of unsupported features when running the ASA in transparent mode.

  • DHCP relay
  • Dynamic routing protocols to the ASA itself.
  • Multicast IP routing
  • QoS
  • VPN termination for through traffic – a VPN for management connections is supported.

Configuration

As soon as you configure transparent mode, the existing configuration is wiped without prompting. A good idea is to at least backup the configuration, either remote to a TFTP/SFTP server or locally.

copy running-config flash:/pre-convert-transparent.cfg

Confirm the current mode of the ASA, the default is “routed”.

show firewall

Change the firewall from “routed” mode to “transparent” mode. To change the firewall back to “routed” mode use the command no firewall transparent.

 firewall transparent

Configure the interfaces in each bridge-group.

interface gigabitEthernet0/0
 nameif OUTSIDE
 security-level 0
 bridge-group 123
!
interface gigabitEthernet0/0
 nameif INSIDE
 security-level 100
 bridge-group 123

Create a BVI interface and configure an IP address, to enable IP routing to forward traffic. You do not necessarily need to use it for management purposes.

interface bvi 123
 ip address 10.10.1.3 255.255.255.0

Configure management interface.

interface management 0/0
 ip address 192.168.10.51 255.255.255.0
 nameif MGMT

Once configured, traffic will follow general rules of ASA – High to Low, permitted and Low to High denied, until ACL is configured. In our example we shall permit inbound ICMP and EIGRP on the outside interface. From inside to outside we shall also permit ICMP and EIGRP, in addition we shall permit ssh, telnet and www services. Once an ACL is applied inbound on the INSIDE interface the implicit permit rule from High security level to Low security level no longer applies.

access-list OUTSIDE_IN extended permit icmp any any echo
access-list OUTSIDE_IN extended permit eigrp any any
access-list OUTSIDE_IN extended permit deny ip any any log
!
access-group INSIDE_OUT in interface INSIDE
!
access-list INSIDE_OUT extended permit icmp any any
access-list INSIDE_OUT extended permit eigrp any any
access-list INSIDE_OUT extended permit tcp any any eq ssh
access-list INSIDE_OUT extended permit tcp any any eq telnet
access-list INSIDE_OUT extended permit tcp any any eq www
!
access-group OUTSIDE_IN in interface OUTSIDE

With EIGRP enabled inbound in both directions an EIGRP adjacency should be established, and routes learnt by the switches/routers either side of the ASA.

A static ARP entry of the default gateway is defined, and ARP Inspection is enabled on the OUTSIDE interface.

arp OUTSIDE 10.10.1.2 5000.0002.80c9
arp-inspection OUTSIDE enable no-flood

Verification

Run the command show access-list OUTSIDE_IN, from the output below of the ACL inbound on the OUTSIDE interface, we can confirm by the hit counters that ICMP and EIGRP is permitted, everything else is explicitly denied.

 

Check the ACL hit count for the ACL inbound on the INSIDE interface, we can confirm matches for ICMP, EIGRP, telnet and www services. Any other traffic not matching this ACL will be denied by the implicit deny.

When testing ARP Inspection, enable debugs using debug arp-inspection and log to the console, disable debugs once finished!!

If you enable ARP Inspection and do not create a static ARP entry, then you will receive the following SYSLOG message – “%ASA-3-322003:ARP inspection check failed for arp {request|response} received from host MAC_address on interface interface. This host is advertising MAC Address MAC_address_1 for IP Address IP_address, which is not bound to any MAC Address.”

Change the MAC address of the interface to replicate spoofing a host system, so the MAC no longer matches the static ARP entry. You will receive the SYSLOG message – %ASA-3-322002: ARP inspection check failed for arp {request|response} received from host MAC_address on interface interface. This host is advertising MAC Address MAC_address_1 for IP Address IP_address, which is {statically|dynamically} bound to MAC Address MAC_address_2. From the output below, we can confirm the ASA received a different MAC address which is different to the MAC address that is statically defined.

Tags: , ,