Cisco ASAConfig1,289 downloads

Cisco ASA Firewall Policy Rule

Configure a firewall policy rule on Cisco ASA: define source/destination zones, IPs, service port, and action. Includes NAT reminder when source is RFC1918.

↓ example.txt

What is it?

A Cisco ASA Firewall Policy Rule controls which traffic is allowed or denied between two security zones (interfaces). In ASA, rules are Access Control Lists (ACLs) applied inbound on the source interface. The ASA is stateful — you only permit traffic in one direction and return traffic is automatically allowed. Rules are processed top-to-bottom; the first match wins. An implicit deny-all exists at the end of every ACL.

When to use

·Allowing a specific host in the inside zone to reach a server in the DMZ
·Blocking inbound traffic from the internet to specific internal services
·Permitting traffic between two internal zones (inside ↔ dmz, inside ↔ server-farm)
·Denying specific source IPs or ports while allowing everything else

When NOT to use

·Application-layer control (block Facebook, allow YouTube) — use NGFW/FTD with App-ID or URL filtering
·User-based policies — ASA ACLs are IP-based; for user identity integrate Cisco ISE + TrustSec
·SSL/TLS inspection of encrypted traffic — requires FTD or a dedicated decryption appliance

How it compares

vs Cisco IOS ACLIOS ACLs are stateless — you must permit both directions. ASA is stateful — permit inbound only, return traffic is automatic. ASA ACLs also use regular subnet masks (255.255.255.0), not wildcard masks (0.0.0.255) like IOS.

vs Palo Alto Security PolicyPalo Alto identifies traffic by application (App-ID), not just port/protocol. To allow HTTPS: ASA uses 'permit tcp any any eq 443'; Palo Alto uses 'application: ssl'. Palo Alto is zone-based with explicit source/destination zones in the rule itself.

vs Fortinet Firewall PolicyFortiOS policies are also zone-based and have srcintf/dstintf directly in the rule — similar concept to this form. FortiOS uses services objects rather than inline port syntax.

Prerequisites

→Interfaces must have nameif, security-level, and IP address configured
→Security levels: inside=100 (trusted), dmz=50, outside=0 (untrusted)
→If source is RFC1918 (private IP), a NAT rule must exist before this ACL takes effect
→ACL is applied inbound on the source interface — not outbound on the destination
→Always use REAL IP addresses in ACLs, not NATted IPs — ASA matches the original packet before translation (Cisco ASA Access Rules guide)

Config Generator

From Zone (source interface nameif) *

The nameif of the interface where traffic originates

To Zone (destination interface nameif) *

The nameif of the interface where traffic is going

Action *

Protocol *

Source IP / Network *

host 10.10.10.10 | 192.168.1.0 255.255.255.0 | any

Destination IP / Network *

host 153.26.5.3 | 172.16.0.0 255.255.0.0 | any

Destination Port

eq 443 | eq 80 | range 8080 8090 | (leave empty for ICMP or IP)

Rule Description

ACL Name *

Convention: {FROM_ZONE}_IN — e.g. INSIDE_IN, OUTSIDE_IN, DMZ_IN

Source uses a private IP (RFC1918)?

RFC1918 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Verification commands

show access-list {{acl_name}}

Show the ACL with hit counts per rule

ExpectedHit count increments each time a packet matches the rule. Zero hits means traffic is not reaching this ACL.

show access-group

Verify which ACL is applied to which interface and direction

ExpectedShould show: 'access-group {{acl_name}} in interface {{from_zone}}'

show conn

Show active connections through the firewall

ExpectedA matching connection confirms traffic is passing. No entry means it is being dropped.

Debug commands

packet-tracer input {{from_zone}} tcp {{source}} 12345 {{destination}} 443 detailed

Simulate the packet through all ASA checks (ACL, NAT, routing) and show exactly where it is allowed or dropped

WarningSimulation only — does not send real traffic. The most useful troubleshooting command on ASA.

show xlate | include {{source}}

Verify NAT translation exists for the source IP

WarningIf empty and source is RFC1918, traffic will be dropped — no NAT rule is matching.

Common mistakes & fixes

SymptomTraffic dropped even though ACL rule permits it

CauseNAT rule is missing — source is RFC1918 and there is no matching NAT entry

FixRun 'show xlate' to check for NAT translations. Add a NAT rule for the source IP. Use packet-tracer to confirm.

Symptompacket-tracer shows ALLOW but traffic still fails

CauseAsymmetric routing — return traffic takes a different path and bypasses the ASA

FixCheck routing on both source and destination. Return traffic must also pass through the ASA for stateful inspection to work.

SymptomACL hit count is zero

CauseACL not applied to the correct interface, or traffic is not reaching the interface

FixRun 'show access-group' to confirm binding. Run 'capture' on the interface to verify traffic is arriving.

SymptomExisting rule stops matching after adding new rule

CauseNew rule above the existing one is matching first (ACLs process top-to-bottom, first match wins)

FixCheck rule order with 'show access-list'. Use sequence numbers to insert rules at the correct position.

Further learning

Recommended books to go deeper on this topic.

IPv6 Security

Scott Hogg, Eric Vyncke · Cisco Press · Filtering IPv6 with ACLs on IOS and ASA, ICMPv6 and Neighbour Discovery, first-hop security

Paperback ↗

Network Security Architectures

Sean Convery · Cisco Press · ACL design patterns, PACL, VACL, defense-in-depth strategies

Hardcover ↗