VMware ESXi and vSphere Cluster Management

Cisco ASA Security Levels Explained

Learn how Cisco ASA security levels from 0 to 100 define relative trust, influence default traffic flow, and interact with stateful inspection, ACLs, NAT, and routing.

What Cisco ASA security levels mean

A Cisco ASA (Adaptive Security Appliance) is a firewall platform. Each ASA interface is assigned a security level, a number from 0 through 100 that represents the relative trust assigned to the connected network.

A higher number represents a more trusted network. A lower number represents a less trusted network. ASA security levels provide a default traffic-policy baseline, but they are not a complete firewall policy by themselves. Access control lists (ACLs), NAT or PAT, routing, stateful inspection, and service inspection can all affect the final result.

Typical inside, DMZ, and outside design

A common three-zone design uses the following assignments:

Interface role	Typical security level	Trust classification	Typical systems
Inside	100	Highly trusted	Employee workstations, internal applications, and databases
DMZ	50	Intermediate trust	Public-facing web, mail, VPN, or application servers
Outside	0	Untrusted	Internet or another externally controlled network

These values are conventional rather than mandatory. An organization can use other intermediate values when the intended trust ordering is clear. For example, a partner network might use level 30 and a server zone might use level 60. The important relationship is whether one interface is higher, lower, or equal to another interface.

Example interface configuration

The following example assigns names, addresses, and security levels to three interfaces:

interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.252
!
interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 192.168.10.1 255.255.255.0
!
interface GigabitEthernet0/2
 nameif dmz
 security-level 50
 ip address 192.168.50.1 255.255.255.0

The addresses above are documentation examples. Interface naming requirements and address configuration can vary by ASA software release and deployment mode.

Default traffic behavior between unequal security levels

For a new connection, ASA traditionally allows traffic initiated from a higher-security interface toward a lower-security interface. It denies new traffic initiated from a lower-security interface toward a higher-security interface unless an explicit policy permits it.

Higher-to-lower traffic is traffic started by a host on a more trusted interface. Lower-to-higher traffic is traffic started by a host on a less trusted interface. The direction is based on the interface where the packet enters the ASA and the interface through which it would leave.

Source zone	Source level	Destination zone	Destination level	New connection allowed by default?	Reason
Inside	100	DMZ	50	Yes	Higher-to-lower
Inside	100	Outside	0	Yes	Higher-to-lower
DMZ	50	Outside	0	Yes	Higher-to-lower
DMZ	50	Inside	100	No	Lower-to-higher
Outside	0	DMZ	50	No	Lower-to-higher
Outside	0	Inside	100	No	Lower-to-higher
Equal-level interface	Same	Equal-level interface	Same	No	Same-security traffic is denied by default
Any permitted source	Any	Any permitted destination	Any	Yes, when established state matches	Return traffic belongs to an existing allowed session

Three-zone example

With inside at level 100, DMZ at level 50, and outside at level 0:

An inside client can initiate a session to a DMZ server by default.
An inside client can initiate a session to an Internet host by default.
A DMZ host can initiate a session to an Internet host by default.
A DMZ host cannot initiate a new session to the inside LAN by default.
An Internet host cannot initiate a new session to either the DMZ or inside network by default.
Replies to permitted inside-to-DMZ, inside-to-outside, and DMZ-to-outside sessions can return when they match established connection state.

“By default” does not mean that every packet will pass. The route must exist, NAT requirements must be satisfied, ACL processing must allow the packet, and any relevant inspection or platform policy must also permit it.

Stateful inspection and return traffic

ASA is a stateful firewall. When it permits a session, it records connection information in its connection table. This state can include addresses, ports, protocol information, and the direction in which the session was created.

For example, an inside client might initiate a TCP connection to an Internet web server. The ASA records the permitted flow. When the web server sends response packets back toward the client, those packets travel from the lower-security outside interface toward the higher-security inside interface. They are allowed because they match the established session, not because outside-to-inside new connections are normally allowed.

Return traffic is response traffic associated with an already permitted and tracked session. Unsolicited traffic is a new inbound connection attempt that does not match an existing firewall session. An unsolicited Internet connection to an inside host remains denied by the default lower-to-higher behavior unless an explicit policy exception is configured.

Equal security levels and same-security traffic

Interfaces assigned the same security level do not pass traffic between one another by default. For example, two partner interfaces both assigned level 50 cannot exchange traffic merely because their levels are equal.

To enable the possibility of inter-interface forwarding between equal-level interfaces, configure the following global command:

same-security-traffic permit inter-interface

This command changes the default behavior for same-level interfaces. It does not automatically create a complete policy. Routing, ACLs, NAT, and endpoint firewalls still need to support the intended communication. After enabling the command, use narrowly scoped ACLs to limit which sources, destinations, and services can communicate.

Overriding defaults with ACLs

An ACL (access control list) explicitly permits or denies traffic. On ASA, an interface ACL is normally applied in the inbound direction on the interface where the packet enters the firewall. For example, traffic arriving from the Internet is evaluated against the ACL applied inbound on the outside interface.

An ACL can permit a selected lower-to-higher flow, such as HTTPS from the Internet to one DMZ web server. The correct approach is to permit only the required protocol, source, destination, and service port rather than broadly opening the trust boundary.

access-list OUTSIDE_IN extended permit tcp any host 192.168.50.10 eq https
access-group OUTSIDE_IN in interface outside

In this example, the rule identifies TCP, any source, one destination host, and HTTPS. It does not permit other ports to that server or traffic to the inside network. The exact address that should appear in an ACL can depend on the ASA software release and NAT configuration model, so verify the platform's address-matching behavior.

Always evaluate an ACL alongside security levels, NAT rules, routing, and service inspection. An ACL permit alone does not guarantee that the packet can be translated, routed, delivered, or accepted by the destination host.

Security levels, NAT, and published services

A security level alone is never sufficient to publish an internal service to the Internet. Internet users reaching a DMZ or inside server typically require both:

An explicit inbound ACL permitting the required service.
An appropriate static or object NAT policy that maps the public address to the server's private address.

Outbound client access and inbound service publication are different use cases:

Outbound client connection: An inside or DMZ client initiates a connection toward a lower-security network. Dynamic NAT or PAT commonly translates the private source address, and the ASA tracks the resulting session.
Inbound published service: An external client initiates a connection toward a server. A static mapping commonly provides a stable public address, while an ACL limits the permitted service.

Example: Internet access to a DMZ HTTPS server

Suppose a DMZ web server uses private address 192.168.50.10 and should be reachable from the Internet only on TCP port 443. Outside-to-DMZ is lower-to-higher, so the default security-level behavior denies the new connection. A narrowly scoped outside ACL and static NAT policy are required:

access-list OUTSIDE_IN extended permit tcp any host 192.168.50.10 eq https
access-group OUTSIDE_IN in interface outside
object network DMZ_WEB
 host 192.168.50.10
 nat (dmz,outside) static 203.0.113.10

The exact NAT syntax and ACL address matching behavior depend on the ASA release and NAT configuration model. Replace the documentation addresses with the actual public and private addresses, and verify the resulting policy with packet-tracer.

Example: DMZ application to inside database

If a DMZ application server needs to access an internal database, the flow is DMZ-to-inside, or level 50 to level 100. It is lower-to-higher and requires an explicit exception. Permit only the application server's source address, the database host's destination address, and the required database port.

This exception has security implications: if the DMZ application server is compromised, the permitted database path may provide access to an internal resource. Keep the rule narrow, monitor it, and avoid allowing broad access from the entire DMZ to the inside network.

Traffic-flow analysis method

Use this repeatable process whenever you need to predict or troubleshoot ASA traffic:

Identify the ingress interface. Determine where the packet enters the ASA.
Identify the egress interface. Use the destination and routing table to determine where the ASA should send the packet.
Compare security levels. Decide whether the flow is higher-to-lower, lower-to-higher, or equal-level.
Determine whether it is new or established. A new connection is evaluated differently from return traffic that matches the connection table.
Check the applicable inbound ACL. Confirm the rule, direction, interface, and hit count.
Check NAT or PAT. Confirm that the required translation exists and that addresses used for policy matching are correct.
Check route availability. Verify that the ASA has a route to the destination and that the return path is valid.
Check inspection and endpoint behavior. Confirm that protocol inspection, host firewalls, gateways, and listening services are not blocking the flow.

First predict the result from security levels alone. Then add the other packet-processing inputs. This separates the default trust baseline from explicit exceptions and helps identify whether a failure is caused by ACL, NAT, routing, state, or the destination host.

Security-level defaults versus explicit policy requirements

Traffic objective	Security-level result	ACL needed?	NAT commonly needed?	Notes
Internal client browsing the Internet	Higher-to-lower; allowed by default	Depends on the configured policy	Dynamic NAT or PAT commonly required	Routing, translation, inspection, and return state must work
Internet access to a published DMZ web server	Lower-to-higher; denied by default	Yes, permit only the required service	Static or object NAT commonly required	Do not treat the security level as a publication mechanism
DMZ application access to an internal database	Lower-to-higher; denied by default	Yes, narrowly scope source, destination, and port	Depends on addressing and policy design	Consider the risk of exposing internal data to a compromised DMZ host
Traffic between equal-level interfaces	Denied by default	Use appropriate ACLs	Depends on addressing and policy design	Enable same-security inter-interface traffic before permitting the intended flows

Verification and troubleshooting

These commands help verify interface levels, policy, state, and simulated packet processing:

show interface ip brief
show running-config interface
show conn
show access-list
show nat
packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.10 443 detailed

show interface ip brief and show running-config interface help confirm interface status, names, addresses, and security levels. show conn displays active stateful connections. show access-list helps verify rules and hit counters. show nat displays configured NAT policy. packet-tracer can identify the processing stage that accepts or drops a simulated packet, such as ACL, NAT, route, or policy inspection.

Outside client cannot reach a DMZ web server

The default lower-to-higher behavior may still be blocking the new connection.
The outside ACL may not permit TCP 443.
Static or object NAT may be missing or may reference the wrong address.
The ACL may be applied to the wrong interface or direction.
The DMZ server may lack a correct default gateway or may not be listening on port 443.

Review the outside ACL and hit counters, inspect the NAT policy, run packet-tracer from the outside interface, and verify the DMZ host's routing and service status.

DMZ system cannot reach an inside database

The flow is lower-to-higher and is denied without an explicit policy.
The DMZ ACL may be absent, too broad, or incorrect.
The destination address or database port may be wrong.
A route, NAT rule, host firewall, or database configuration may be preventing the flow.

Confirm the ingress and egress interfaces and their levels. Inspect the inbound ACL on the DMZ interface, run packet-tracer with the exact protocol and port, and check for a connection-table entry after testing.

Equal-level interfaces cannot communicate

Same-level inter-interface traffic is denied by default.
same-security-traffic permit inter-interface is absent.
Routing or ACL policy is still missing after the global setting is enabled.

Check the global command, verify route selection in both directions, review applicable ACLs, and test with packet-tracer.

Reply traffic is unexpectedly blocked

The reply may not match the expected state because of asymmetric routing.
The NAT translation may be incorrect or may have changed the expected address and port tuple.
The original connection may not have been established through this ASA.
A protocol-specific issue may require inspection or additional policy.

Inspect connection and translation tables, confirm that both directions traverse the same ASA, and use packet-tracer and relevant logs to identify the drop reason.

Key points to remember

Security levels range from 0 to 100 and express relative network trust.
Inside is commonly level 100, DMZ level 50, and outside level 0.
New higher-to-lower connections are allowed by the default security-level baseline; new lower-to-higher connections are denied.
Return packets for permitted sessions are handled by stateful inspection and are different from unsolicited inbound connections.
Equal-level interfaces are isolated by default; same-security-traffic permit inter-interface enables their inter-interface forwarding possibility.
ACLs can create narrow exceptions, but they must be considered with NAT, routing, connection state, and inspection.
Publishing a service generally requires both an inbound ACL and appropriate static or object NAT.
Security levels are one input to ASA packet processing, not a replacement for a complete security policy.

For related configuration context, see Cisco ASA Security Levels Explained.