Cisco ASA Security Levels Explained: Inside, Outside, DMZ

Security levels are the single most distinctive feature of Cisco ASA configuration. Every ASA interface gets a numeric value from 0 (lowest trust, typically the internet) to 100 (highest trust, typically your inside LAN), and the default forwarding behavior between interfaces is determined entirely by that number. Get the security-level model right and the rest of the ASA configuration falls into place. Get it wrong and you spend hours debugging traffic that "should be allowed" but is not.

This article is part of the Cisco ASA Complete Guide on PingLabz. We cover the convention, the default behavior, the same-security-level cases, and the common mistakes engineers make on day one.

The Convention: 0, 50, 100

Security level is a number from 0 to 100 assigned to each ASA interface with the security-level command. The number itself is arbitrary - 100 is just "more trusted than 50, which is more trusted than 0." The convention almost every shop follows:

The numbers are spaced so you can insert new zones between existing ones (a partner network at 25, a guest network at 15) without renumbering everything. There is nothing magical about 100, 50, and 0 - those are just the well-known defaults from sample configurations dating back to the PIX era.

Default Behavior: High to Low Allowed, Low to High Denied

The implicit forwarding rules between interfaces are determined entirely by their security levels:

• Higher security to lower security: implicit allow. A packet from inside (100) to outside (0) is permitted by default, with NAT and a connection-table entry. No explicit ACL needed.
• Lower security to higher security: implicit deny. A packet from outside (0) to inside (100) is dropped by default. You must apply an explicit ACL to permit specific flows.
• Same security to same security: implicit deny. Two interfaces at the same level cannot pass traffic to each other unless you globally configure same-security-traffic permit inter-interface.
• Same interface ingress and egress (hairpinning): implicit deny. Traffic that comes in and goes out the same interface is dropped unless you globally configure same-security-traffic permit intra-interface. Used for inter-VPN routing through the ASA, hub-and-spoke through a single interface, and the ASA's internal VPN-to-VPN forwarding.

Confirm any flow with packet-tracer - the first phase reports whether the implicit rule allowed or dropped, and which security-level relationship caused it. We cover that workflow in Cisco ASA packet-tracer Command: Complete Troubleshooting Guide.

Three-Interface Example

The classic ASA with inside (100), dmz (50), outside (0):

interface GigabitEthernet0/0
 nameif inside
 security-level 100
 ip address 10.10.0.254 255.255.255.0

interface GigabitEthernet0/1
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.252

interface GigabitEthernet0/2
 nameif dmz
 security-level 50
 ip address 192.168.50.1 255.255.255.0

Verify with show nameif:

ASA-PERIM# show nameif
Interface                Name                     Security
GigabitEthernet0/0       inside                   100
GigabitEthernet0/1       outside                    0
GigabitEthernet0/2       dmz                       50
Management0/0            management                 0

Default forwarding between these three interfaces:

The dmz-to-inside denied default is exactly the point of having a DMZ. If a public web server is compromised, the attacker can reach the internet but cannot pivot to the inside network.

Same Security: Two Cases

Two interfaces with the same security level (say, two DMZs both at 50, or two partner networks both at 25) cannot pass traffic to each other unless you explicitly enable it:

same-security-traffic permit inter-interface

This is one global command, not per-interface. Once enabled, all same-security-level pairs can talk, subject to ACLs. Use this when you have multiple zones at the same trust tier that need to communicate (multiple DMZs, multiple branch offices).

The same-interface (intra-interface) case is rarer. Traffic that comes in an interface and needs to leave the same interface is denied by default. You enable it with:

same-security-traffic permit intra-interface

Use cases: hub-and-spoke VPN where multiple spokes terminate on the same interface and need to reach each other through the ASA, or WCCP redirects.

The dmz-to-inside Pattern: Restrictive by Default

The most common ACL pattern engineers configure is for traffic going dmz-to-inside (50 to 100). The default is deny, so you write a small, very specific permit list and apply it inbound on the dmz interface.

object-group network DMZ-WEB-SERVERS
 network-object host 192.168.50.10
 network-object host 192.168.50.11

object-group network INSIDE-DB-SERVERS
 network-object host 10.10.0.20

access-list DMZ_IN extended permit tcp object-group DMZ-WEB-SERVERS object-group INSIDE-DB-SERVERS eq 3306
access-list DMZ_IN extended permit udp object-group DMZ-WEB-SERVERS host 10.10.0.10 eq 53
access-list DMZ_IN extended permit udp object-group DMZ-WEB-SERVERS host 10.10.0.10 eq 123
access-list DMZ_IN extended deny ip any any log
access-group DMZ_IN in interface dmz

Five lines: web servers can hit the database on MySQL, do DNS to a specific resolver, do NTP to a specific server, and everything else is denied with logging. That is what defense-in-depth looks like at the firewall layer.

Common Mistakes

• Two interfaces at level 100. Inside is 100. If you accidentally configure another interface at 100 (typing too fast and copying from a sample), traffic between them is denied by default until you enable same-security-traffic permit inter-interface. Engineers often spot this only by reading show nameif.
• "Inside is 0 because outside is 100." Inverted convention. Outside is the lowest (untrusted) and gets 0; inside is the highest and gets 100. Reversing this changes implicit forwarding direction and breaks everything.
• Forgetting the inbound ACL on outside. Default is implicit deny for low-to-high. If you have a static NAT publishing a DMZ server but no ACL allowing the traffic, the public will hit the static NAT (UN-NAT phase succeeds) and then get dropped by the implicit deny in the ACL phase. Run packet-tracer once to confirm.
• Allowing same-security inter-interface globally without thinking. If you have multiple zones at the same level and enable same-security-traffic permit inter-interface, those zones can suddenly all talk to each other. Verify each pair has an explicit ACL before flipping the global switch.
• Confusing security level with policy. Security level only sets the default. An explicit ACL always overrides the default. The level is a hint to your future self about the trust relationship, not a substitute for ACL design.

Related Articles

• Cisco ASA ACL Configuration: Inbound Rules and Object Groups - the explicit override mechanism.
• Cisco ASA Packet Flow - the data path that uses these defaults.
• Cisco ASA packet-tracer Guide - confirms which implicit or explicit rule applies to a given flow.
• Cisco ASA Routed Mode vs Transparent Mode - mode-level context.
• Cisco ASA Inside/Outside/DMZ Configuration Walkthrough - the worked example end-to-end.

Key Takeaways

Security level is a 0-to-100 number per interface that determines default forwarding behavior. Higher to lower is allowed by default; lower to higher and same-to-same are denied. The convention is inside 100, dmz 50, outside 0, with custom zones in between. Two interfaces at the same level cannot talk unless you enable same-security-traffic permit inter-interface. The dmz-to-inside boundary is the most security-critical: keep its inbound ACL strict, log denies, and verify with packet-tracer.