Controlling Network Access
Access rules determine which traffic is allowed through the ASA. There are several different layers of rules that work together to implement your access control policy:
-
Extended access rules (Layer 3+ traffic) assigned to interfaces—You can apply separate rule sets (ACLs) in the inbound and outbound directions. An extended access rule permits or denies traffic based on the source and destination traffic criteria.
-
Extended access rules (Layer 3+ traffic) assigned to Bridge Virtual Interfaces (BVI; routed mode)—If you name a BVI, you can apply separate rule sets in the inbound and outbound direction, and you can also apply rule sets to the bridge group member interfaces. When both the BVI and member interface have access rules, the order of processing depends on direction. Inbound, the member access rules are evaluated first, then the BVI access rules. Outbound, the BVI rules are considered first, then the member interface rules.
-
Extended access rules assigned globally—You can create a single global rule set, which serves as your default access control. The global rules are applied after interface rules.
-
Management access rules (Layer 3+ traffic)—You can apply a single rule set to cover traffic directed at an interface, which would typically be management traffic. In the CLI, these are “control plane” access groups. For ICMP traffic directed at the device, you can alternatively configure ICMP rules.
-
EtherType rules (Layer 2 traffic) assigned to interfaces (bridge group member interfaces only)—You can apply separate rule sets in the inbound and outbound directions. EtherType rules control network access for non-IP traffic. An EtherType rule permits or denies traffic based on the EtherType. You can also apply extended access rules to bridge group member interfaces to control Layer 3+ traffic.
General Information About Rules
The following topics provide general information about access rules and EtherType rules.
Interface Access Rules and Global Access Rules
You can apply an access rule to a specific interface, or you can apply an access rule globally to all interfaces. You can configure global access rules in conjunction with interface access rules, in which case, the specific inbound interface access rules are always processed before the general global access rules. Global access rules apply only to inbound traffic.
Inbound and Outbound Rules
You can configure access rules based on the direction of traffic:
-
Inbound—Inbound access rules apply to traffic as it enters an interface. Global and management access rules are always inbound.
-
Outbound—Outbound rules apply to traffic as it exits an interface.
Note |
“Inbound” and “outbound” refer to the application of an ACL on an interface, either to traffic entering the ASA on an interface or traffic exiting the ASA on an interface. These terms do not refer to the movement of traffic from a lower security interface to a higher security interface, commonly known as inbound, or from a higher to lower interface, commonly known as outbound. |
An outbound ACL is useful, for example, if you want to allow only certain hosts on the inside networks to access a web server on the outside network. Rather than creating multiple inbound ACLs to restrict access, you can create a single outbound ACL that allows only the specified hosts. (See the following figure.) The outbound ACL prevents any other hosts from reaching the outside network.
See the following commands for this example:
hostname(config)# access-list OUTSIDE extended permit tcp host 10.1.1.14 host 209.165.200.225 eq www
hostname(config)# access-list OUTSIDE extended permit tcp host 10.1.2.67 host 209.165.200.225 eq www
hostname(config)# access-list OUTSIDE extended permit tcp host 10.1.3.34 host 209.165.200.225 eq www
hostname(config)# access-group OUTSIDE out interface outside
Rule Order
The order of rules is important. When the ASA decides whether to forward or drop a packet, the ASA tests the packet against each rule in the order in which the rules are listed in the applied ACL. After a match is found, no more rules are checked. For example, if you create an access rule at the beginning that explicitly permits all traffic for an interface, no further rules are ever checked.
Implicit Permits
Unicast IPv4 and IPv6 traffic from a higher security interface to a lower security interface is allowed through by default. This includes traffic between standard routed interfaces and Bridge Virtual Interfaces (BVI) in routed mode.
For bridge group member interfaces, this implicit permit from a higher to a lower security interface applies to interfaces within the same bridge group only. There are no implicit permits between a bridge group member interface and a routed interface or a member of a different bridge group.
Bridge group member interfaces (routed or transparent mode) also allow the following by default:
-
ARPs in both directions. (You can control ARP traffic using ARP inspection, but you cannot control it by access rule.)
-
BPDUs in both directions. (You can control these using Ethertype rules.)
For other traffic, you need to use either an extended access rule (IPv4 and IPv6) or an EtherType rule (non-IP).
Implicit Deny
ACLs have an implicit deny at the end of the list, so unless you explicitly permit it, traffic cannot pass. For example, if you want to allow all users to access a network through the ASA except for particular addresses, then you need to deny the particular addresses and then permit all others.
For management (control plane) ACLs, which control to-the-box traffic, there is no implicit deny at the end of a set of management rules for an interface. Instead, any connection that does not match a management access rule is then evaluated by regular access control rules.
For EtherType ACLs, the implicit deny at the end of the ACL does not affect IP traffic or ARPs; for example, if you allow EtherType 8037, the implicit deny at the end of the ACL does not now block any IP traffic that you previously allowed with an extended ACL (or implicitly allowed from a high security interface to a low security interface). However, if you explicitly deny all traffic with an EtherType rule, then IP and ARP traffic is denied; only physical protocol traffic, such as auto-negotiation, is still allowed.
If you configure a global access rule, then the implicit deny comes after the global rule is processed. See the following order of operations:
-
Interface access rule.
-
For bridge group member interfaces, the Bridge Virtual Interface (BVI) access rule.
-
Global access rule.
-
Implicit deny.
NAT and Access Rules
Access rules always use the real IP addresses when determining an access rule match, even if you configure NAT. For example, if you configure NAT for an inside server, 10.1.1.5, so that it has a publicly routable IP address on the outside, 209.165.201.5, then the access rule to allow the outside traffic to access the inside server needs to reference the server’s real IP address (10.1.1.5), and not the mapped address (209.165.201.5).
Same Security Level Interfaces and Access Rules
Each interface has a security level, and security level checking is performed before access rules are considered. Thus, even if you allow a connection in an access rule, it can be blocked due to same-security-level checking at the interface level. You might want to ensure that your configuration allows same-security-level connections so that your access rules are always considered for permit/deny decisions.
-
Connections between the same security level ingress and egress interfaces are subject to the same-security-traffic inter-interface check.
To allow these connections, enter the same-security-traffic permit inter-interface command.
To allow these connections, choose Enable traffic between two or more interfaces which are configured with the same security levels option.
, then select the -
Connections with the same ingress and egress interfaces are subject to the same-security-traffic intra-interface check.
To allow these connections, enter the same-security-traffic permit intra-interface command.
To allow these connections, choose Enable traffic between two or more hosts connected to the same interface option.
, then select the
Extended Access Rules
This section describes information about extended access rules.
Extended Access Rules for Returning Traffic
For TCP, UDP, and SCTP connections for both routed and transparent mode, you do not need an access rule to allow returning traffic because the ASA allows all returning traffic for established, bidirectional connections.
For connectionless protocols such as ICMP, however, the ASA establishes unidirectional sessions, so you either need access rules to allow ICMP in both directions (by applying ACLs to the source and destination interfaces), or you need to enable the ICMP inspection engine. The ICMP inspection engine treats ICMP sessions as bidirectional connections. For example, to control ping, specify echo-reply (0) (ASA to host) or echo (8) (host to ASA).
Allowing Broadcast and Multicast Traffic
In routed firewall mode, broadcast and multicast traffic is blocked even if you allow it in an access rule, including unsupported dynamic routing protocols and DHCP. You must configure the dynamic routing protocols or DHCP relay to allow this traffic.
For interfaces that are members of the same bridge group in transparent or routed firewall mode, you can allow any IP traffic through using access rules.
Note |
Because these special types of traffic are connectionless, you need to apply an access rule to both the inbound and outbound interfaces, so returning traffic is allowed through. |
The following table lists common traffic types that you can allow using access rules between interfaces that are members of the same bridge group.
Traffic Type |
Protocol or Port |
Notes |
---|---|---|
DHCP |
UDP ports 67 and 68 |
If you enable the DHCP server, then the ASA does not pass DHCP packets. |
EIGRP |
Protocol 88 |
— |
OSPF |
Protocol 89 |
— |
Multicast streams |
The UDP ports vary depending on the application. |
Multicast streams are always destined to a Class D address (224.0.0.0 to 239.x.x.x). |
RIP (v1 or v2) |
UDP port 520 |
— |
Management Access Rules
You can configure access rules that control management traffic destined to the ASA. Access control rules for to-the-box management traffic (defined by such commands as http , ssh , or telnet ) have higher precedence than a management access rule applied with the control-plane option. Therefore, such permitted management traffic will be allowed to come in even if explicitly denied by the to-the-box ACL.
Unlike regular access rules, there is no implicit deny at the end of a set of management rules for an interface. Instead, any connection that does not match a management access rule is then evaluated by regular access control rules.
Alternatively, you can use ICMP rules to control ICMP traffic to the device. Use regular extended access rules to control ICMP traffic through the device.
EtherType Rules
This section describes EtherType rules.
Supported EtherTypes and Other Traffic
An EtherType rule controls the following:
-
EtherType identified by a 16-bit hexadecimal number, including common types IPX and MPLS unicast or multicast.
-
Ethernet V2 frames.
-
BPDUs, which are permitted by default. BPDUs are SNAP-encapsulated, and the ASA is designed to specifically handle BPDUs.
-
Trunk port (Cisco proprietary) BPDUs. Trunk BPDUs have VLAN information inside the payload, so the ASA modifies the payload with the outgoing VLAN if you allow BPDUs.
-
Intermediate System to Intermediate System (IS-IS).
-
The IEEE 802.2 Logical Link Control packet. You can control access based on the Destination Service Access Point address.
The following types of traffic are not supported:
-
802.3-formatted frames—These frames are not handled by the rule because they use a length field as opposed to a type field.
EtherType Rules for Returning Traffic
Because EtherTypes are connectionless, you need to apply the rule to both interfaces if you want traffic to pass in both directions.
Allowing MPLS
If you allow MPLS, ensure that Label Distribution Protocol and Tag Distribution Protocol TCP connections are established through the ASA by configuring both MPLS routers connected to the ASA to use the IP address on the ASA interface as the router-id for LDP or TDP sessions. (LDP and TDP allow MPLS routers to negotiate the labels (addresses) used to forward packets.)
On Cisco IOS routers, enter the appropriate command for your protocol, LDP or TDP. The interface is the interface connected to the ASA.
mpls ldp router-id interface force
Or
tag-switching tdp router-id interface force