ASA: Security Levels

Overview

Every configured ASA (Adaptive Security Appliance) data interface that forwards traffic carries a name and a security level from 0 to 100. Before any access rule exists, the levels are the access-control policy: comparing the source and destination interfaces’ levels decides which of your networks can open connections toward which. Misread them and the failure is quiet: a new interface that silently drops traffic nothing ever denied, or a segment trusted far more than anyone intended. This lesson covers how the ASA turns two numbers into policy and where that policy stops applying; ASA: DMZ Interface & Verification brings the module firewall’s DMZ (demilitarized zone) interface online to prove it.

Terminology: What Brings an Interface Up

A basic physical routed-mode ASA data interface forwards nothing until it carries, at minimum, four pieces of state:

• Enabled interface — administratively up (no shutdown)
• Interface name — set with nameif
• Security level — 0 to 100; nameif assigns it for you (inside → 100, any other name → 0), so it exists even when you never type security-level
• IP address — a Layer 3 address in routed mode, or a bridge group and BVI (Bridge Virtual Interface) in transparent mode, as covered in ASA: Deployment Types

You type three of them; the level can come from the name.

Enlarge figure: Minimum configuration to bring an ASA interface up: a routed-mode firewall with three interfaces, each carrying a nameif, a security level, and an IP address

Capture note: the addressing in this lesson’s concept graphics is illustrative — read 192.168.1.0/24 as “the inside network,” 192.168.2.0/24 as “the DMZ,” and the third subnet as “the outside.” The module lab uses its own addressing, shown in See It in the Lab below.

The name is more than a label: ACL bindings, NAT rules, and routes all reference interfaces by nameif, which is why the name is mandatory — and why removing one is destructive.

Going deeper: other interface forms carry this state differently. A subinterface also needs its VLAN, EtherChannel members carry it on the logical port-channel interface, and transparent mode splits it between the bridge-group members and the BVI.

The security level states how trusted the network behind the interface is, relative to the firewall’s other interfaces. Higher means more trusted: the employee LAN outranks a DMZ, and a DMZ outranks the internet. Only the comparison matters — 51 beats 50 exactly the way 100 beats 0. Changing a level on a live interface does not re-judge connections already open: the interfaces chapter has you clear them with clear conn if you do not want to wait for them to time out.

Engine Behavior: The High-to-Low Default

With names and levels in place, the ASA enforces a default through-traffic policy with no ACL configured anywhere. Three rules cover it:

1. Higher to lower is permitted. Unicast IPv4 and IPv6 traffic from a higher security interface to a lower one is allowed through by default (9.23 access rules chapter).
2. Lower to higher is denied — unless an access rule explicitly permits it inbound (the next section shows where one can sit).
3. Return traffic for tracked connections ignores both rules. Replies ride the connection entry the outbound packet created, as covered in Stateful Firewalls — the policy is evaluated once, at connection setup.

One caveat on rule 3: it covers connections the ASA tracks. ICMP echo replies, for instance, only ride state once ICMP inspection is enabled, or an access rule admits them.

The classic three-tier design follows directly, and it’s the shape of most ASA deployments you’ll inherit:

• inside (100) — the trusted user LAN
• dmz (50) — public-facing servers, semi-trusted
• outside (0) — the internet, trusted not at all

Enlarge figure: Security level traffic flows on a three-interface ASA: the three flows toward lower levels are permitted by default, the three flows toward higher levels are denied

Read the six rows of the graphic against rule 1 and rule 2: every flow toward a lower level is permitted, every flow toward a higher level is denied. That’s the whole model — users reach the DMZ and the internet, DMZ servers reach the internet, and nothing on a less-trusted segment initiates inward.

Rule Order: What an ACL Does to the Default

The high-to-low default has a short life in production: it ends at the interface where you apply an inbound access rule. From then on a NEW connection entering that interface is judged in this order (access rules chapter); established connections ride their state entry and skip it:

1. Interface access rule
2. Global access rule (if configured)
3. Implicit deny

Notice what’s missing: once rules are bound, the source interface’s level is no longer consulted. Traffic entering an interface with an inbound ACL passes or drops on the ACL’s terms, even from the most trusted segment on the box. An outbound ACL (access-group … out) is different: it filters traffic leaving an interface and does not retire the level default on the interface the traffic entered.

Enlarge figure: Three columns compare who decides a new connection entering an interface. No access rules: the levels are the policy; higher to lower is permitted, lower to higher denied, equal levels denied. Interface ACL, bound with access-group in interface: the level default is retired there; the interface access rule, then a global access rule if any, then the implicit deny decide, so even level 100 is just a source. Global ACL, bound with access-group global: it applies to every interface; the interface rule where bound, then the global rule, then the implicit deny, so no interface is left bare. A bar underneath reads: same-security flows also need same-security-traffic permit, in every regime.

Going deeper: Levels have a second, quieter job the ACL never takes over. Some application inspection engines are security-level dependent (interfaces chapter). NetBIOS inspection, for example, is “applied only for outbound connections”, so which side is more trusted decides whether it runs at all; between same-security interfaces, those engines inspect both directions.

Design Choice: Same Security Levels

Two interfaces at the same level — say a pair of DMZs — get no default in either direction:

interface gigabitEthernet0/1
 nameif dmz_east
 security-level 50
!
interface gigabitEthernet0/2
 nameif dmz_west
 security-level 50

Traffic between dmz_east and dmz_west is dropped by default, and this is the one place an ACL won’t help: connections between same-level interfaces are subject to a separate check that access rules can’t bypass. Allowing them takes a global command — and its twin covers traffic that enters and exits the same interface:

! Global commands — both off by default
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

• inter-interface — permits traffic between any two interfaces that share a security level. Typical when you want several equal segments (multiple DMZs, multiple partner links) without ranking them.
• intra-interface — permits traffic to U-turn out the interface it arrived on. The two common cases are hub-and-spoke topologies where spoke-to-spoke traffic enters and exits the hub’s one interface, and VPN hairpinning for remote-access users.

Both are global switches. Once inter-interface is enabled, new connections are permitted in both directions between every pair of equal-level interfaces, and your ACLs can then restrict within that as usual.

Enlarge figure: Equal levels are off until you switch them on, in two scenes. Left, trace 1, inter-interface: a host on dmz_east at level 50 opens a connection through the ASA toward dmz_west, also at level 50, and the arrow ends on a cross before dmz_west, with a faint line on to it: denied until same-security-traffic permit inter-interface. Right, trace 2, intra-interface: spoke A sends traffic up into the hub ASA's one interface and it turns back down the same interface toward spoke B, ending on a cross: denied until same-security-traffic permit intra-interface.

Scope: Managing the ASA Itself

One rule the levels do not touch: you manage the ASA through the interface you arrive at. Per the 9.23 management access chapter, SSH, Telnet, and HTTPS access to an interface other than the one from which you entered the ASA is not supported.

So an inside host can reach the inside interface address, but not the DMZ interface address, no matter what the security levels say.

The one exception is management arriving through a VPN tunnel, where the management-access command designates an interface reachable from the far side. If a “can’t reach the firewall” ticket names an interface the client’s traffic does not enter, this rule is the answer, not the levels.

🔬 See It in the Lab

Your lab is where M4 · Lab 1: Power On the ASA Perimeter left it, because the lessons since, including ASA: Security Contexts, change nothing on it: ASA-EDGE-01 has three named interfaces and not one access rule. Run these on it now; show nameif reads the whole trust ladder in one command:

ASA-EDGE-01# show nameif
Interface                Name                     Security
GigabitEthernet0/0       outside                    0
GigabitEthernet0/1       inside                   100
Management0/0            management               100
ASA-EDGE-01# show running-config same-security-traffic
ASA-EDGE-01# show running-config access-group
ASA-EDGE-01# show running-config interface Management0/0
!
interface Management0/0
 no management-only
 nameif management
 security-level 100
 ip address 10.82.22.185 255.255.255.0

Read it against the lesson:

• Two tiers so far: inside and management at 100, outside at 0. The DMZ joins at 50 in ASA: DMZ Interface & Verification.
• Management0/0 carries through traffic. It reads no management-only, so it forwards like any data interface, and inside and management are a genuine same-security pair.
• same-security-traffic prints nothing, so both switches are off.
• access-group prints nothing. No access rule is bound anywhere, so the levels are the whole policy: the first regime in the figure above.

Now make the firewall prove both halves of the model. Trace a web connection from an inside host to WS-ADMIN-01, which sits behind the management interface:

ASA-EDGE-01# packet-tracer input inside tcp 10.10.1.100 40000 10.82.22.194 80

Phase: 1
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 24939 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop 10.82.22.194 using egress ifc  management

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: DROP
Elapsed time: 6357 ns
Config:
Implicit Rule
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: management
output-status: up
output-line-status: up
Action: drop
Time Taken: 31296 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA

The ACCESS-LIST phase ends at Implicit Rule. There is no access rule to consult, and between two level-100 interfaces the default is deny.

Now the same host and port toward the outside, to R-ISP-01’s loopback. Ping R-ISP-01 first so the ASA has its ARP entry; without one, the trace ends no-v4-adjacency, which is a routing answer, not a policy one:

ASA-EDGE-01# ping 198.51.100.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.51.100.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
ASA-EDGE-01# packet-tracer input inside tcp 10.10.1.100 40001 203.0.113.254 80

Phase: 1
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Elapsed time: 21027 ns
Config:
Additional Information:
Found next-hop 198.51.100.254 using egress ifc  outside

...

Phase: 8
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Elapsed time: 11736 ns
Config:
Additional Information:
New flow created with id 17, packet dispatched to next module

...

Phase: 10
Type: ADJACENCY-LOOKUP
Subtype: Resolve Nexthop IP address to MAC
Result: ALLOW
Elapsed time: 1956 ns
Config:
Additional Information:
Found adjacency entry for Next-hop 198.51.100.254 on interface  outside
Adjacency :Active
MAC address 5254.0030.fd81 hits 5 reference 1

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
Time Taken: 97311 ns

Same source host, same destination port, same empty rule set. The two traces reach different destinations out different interfaces, and the difference that decides the verdict is the egress interface’s level. Every phase the second trace ran reads ALLOW. The phases cut for length, 2 to 7 and 9, are NAT, IP-OPTIONS, QOS and a second route lookup, and none of them is an ACCESS-LIST phase. From 100 to 0 there is no access check to fail, so the flow is created and allowed.

Enlarge figure: Two verdicts with no access rules, drawn from the two traces above. ASA-EDGE-01 in the centre has no access rules. From an inside host at 10.10.1.100, level 100: trace 2 goes to R-ISP-01's loopback 203.0.113.254 on the outside interface, level 0, and is allowed, higher to lower. Trace 1 heads for WS-ADMIN-01 behind the management interface, level 100 like inside, and ends on a cross before it reaches WS-ADMIN-01: equal levels, dropped at the implicit rule, with a faint line showing where it was headed.

By the end of the module this box carries a DMZ at 50 and both access-group forms; ASA: Global ACLs traces what that changes.

🎥 [Video: The security-level trust ladder — show nameif read against the module baseline, whiteboarding the six flows on the traffic-flows graphic, the rule-order boundary an ACL creates, same-security-traffic and why no ACL fixes that stall, and the one management-access rule. Matches video.script_outline. Runtime: ~5 minutes]

Up next: with no access rules, the model predicts three verdicts for new connections among the three data tiers — inside reaches everything, outside reaches nothing, dmz sits in between — and predictions are cheap until you prove them on a real box. ASA: DMZ Interface & Verification builds the DMZ tier live and makes the firewall testify to all three with packet-tracer.