Cisco ASA CLI Basics: Modes, Interfaces, ACLs and NAT

The Cisco ASA (Secure Firewall ASA) command line looks like IOS but behaves differently in the areas that matter for firewalls: interfaces get names and security levels, traffic is filtered by access-groups attached to interface pairs, and NAT is built from objects. This guide covers the CLI modes and the minimal configuration needed to take a new ASA from console login to a working routed firewall with SSH management access.

It is worth understanding why the ASA diverged from IOS at all. A router forwards packets between subnets and filters almost as an afterthought. A firewall exists to enforce a policy, so the ASA's configuration model puts policy first: every interface belongs to a zone-like concept called a security level, and the default behaviour is derived from that level rather than being implicit.

Command Modes

The ASA has the same three-level mode structure as IOS, with prompts that reflect the hostname:

ciscoasa>            ! user EXEC
ciscoasa> enable
ciscoasa#            ! privileged EXEC
ciscoasa# configure terminal
ciscoasa(config)#    ! global configuration

From global configuration, interface, object and other commands open command-specific submodes. Commands can be abbreviated to the shortest unique form, and output can be filtered like IOS: show run | include nameif, show xlate | grep -c.

A useful habit when learning on a live box is the do prefix, which lets you run an EXEC command from inside a configuration submode without leaving it, and the ? key, which lists only the options legal in the current submode. The context prompt matters too: the ASA is a multi-context-capable platform, and a /admin or /ctx suffix in the prompt tells you which context you are editing.

ciscoasa(config-if)# do show interface ip brief
ciscoasa(config-if)# nameif ?
ciscoasa/admin(config)# show running-config | include : start

Basic Interface Configuration

Routed-mode interfaces need a name, a security level, an IP address and no shutdown. The name is what every later command references:

ciscoasa(config)# interface gigabitethernet0/0
ciscoasa(config-if)# nameif outside
ciscoasa(config-if)# security-level 0
ciscoasa(config-if)# ip address 203.0.113.1 255.255.255.0
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# exit
ciscoasa(config)# interface gigabitethernet0/1
ciscoasa(config-if)# nameif inside
ciscoasa(config-if)# security-level 100
ciscoasa(config-if)# ip address 192.168.1.1 255.255.255.0
ciscoasa(config-if)# no shutdown

Security levels default the policy: traffic from a higher level (inside, 100) to a lower level (outside, 0) is allowed unless an ACL denies it, while lower-to-higher traffic needs an explicit permit.

You can verify the result immediately. The two commands below are the ones you will type more than any others while commissioning a firewall:

ciscoasa# show interface ip brief
ciscoasa# show nameif
ciscoasa# show running-config interface gigabitethernet0/0

Two interface variants are worth knowing before you design anything. A redundant interface bundles two physical ports into one logical named interface so a failed link does not black-hole the subnet, and a subinterface lets one physical port carry several VLANs of 802.1Q-tagged traffic. Both are common on branch firewalls where you have more logical segments than physical ports.

! Redundant interface pair
ciscoasa(config)# interface redundant 1
ciscoasa(config-if)# member-interface gigabitethernet0/2
ciscoasa(config-if)# member-interface gigabitethernet0/3
ciscoasa(config-if)# nameif dmz
ciscoasa(config-if)# security-level 50
ciscoasa(config-if)# ip address 172.16.1.1 255.255.255.0

! 802.1Q subinterface on the inside trunk
ciscoasa(config)# interface gigabitethernet0/1.200
ciscoasa(config-subif)# vlan 200
ciscoasa(config-subif)# nameif guests
ciscoasa(config-subif)# security-level 60
ciscoasa(config-subif)# ip address 10.20.0.1 255.255.255.0

Routes, ACLs and NAT

ciscoasa(config)# route outside 0.0.0.0 0.0.0.0 203.0.113.254
ciscoasa(config)# object network INSIDE-NET
ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0
ciscoasa(config-network-object)# nat (inside,outside) dynamic interface
ciscoasa(config-network-object)# exit
ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any interface outside eq https
ciscoasa(config)# access-group OUTSIDE-IN in interface outside

The default route points at the ISP gateway; the network object hides the inside subnet behind the outside interface IP (PAT); and the access-group permits inbound HTTPS to the firewall itself. Modern ASA versions default to object NAT, which is why the object carries the nat statement.

The asymmetric NAT rule you will write next is almost always a static port forward, because object NAT is where the ASA is genuinely more readable than IOS:

ciscoasa(config)# object network WEB-SERVER
ciscoasa(config-network-object)# host 192.168.1.20
ciscoasa(config-network-object)# nat (inside,outside) static interface service tcp 443 443

ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any object WEB-SERVER eq 443
ciscoasa(config)# access-group OUTSIDE-IN in interface outside

Compare the object-NAT style here with the older IOS ip nat inside source model in our IOS NAT and PAT overload guide if you maintain both platforms.

Object groups keep the policy readable

A real firewall rule base references groups, not individual hosts. Object groups collapse the last hundred ACL lines into a handful that a human can audit, and the ASA evaluates them exactly as if you had written each entry out.

ciscoasa(config)# object-group network INTERNAL-SERVERS
ciscoasa(config-network-object-group)# network-object host 192.168.1.20
ciscoasa(config-network-object-group)# network-object 192.168.1.0 255.255.255.0

ciscoasa(config)# object-group service WEB-PORTS tcp
ciscoasa(config-service-object-group)# port-object eq https
ciscoasa(config-service-object-group)# port-object eq http

ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any object-group INTERNAL-SERVERS object-group WEB-PORTS

Rebuild the rule set in one line when you move a server: edit the object group, not fifty ACL entries. That is the difference between a firewall policy that stays auditable and one that becomes archaeology.

Management Access: SSH

ciscoasa(config)# crypto key generate rsa modulus 2048
ciscoasa(config)# ssh 192.168.1.0 255.255.255.0 inside
ciscoasa(config)# ssh timeout 5
ciscoasa(config)# ssh version 2
ciscoasa(config)# username admin password MyPass123 privilege 15
ciscoasa(config)# aaa authentication ssh console LOCAL
ciscoasa(config)# write memory

write memory saves the running config to the startup configuration; the ASA keeps its configuration as a text file, and show running-config is the authoritative view. For a different security platform with the same zone model, compare with our Juniper SRX internet configuration guide, and see the FortiGate CLI troubleshooting cheatsheet for yet another syntax family.

Never leave a firewall reachable by telnet, and never leave the ssh 0.0.0.0 0.0.0.0 outside form in place. Scope the management subnet tightly and, in production, replace LOCAL authentication with RADIUS or TACACS+ so leaving the company revokes access everywhere at once. Restricting SSH to a management interface and a named source subnet is the single highest-value hardening step on a new ASA.

Verifying traffic and troubleshooting

The ASA's debugging model is packet-centric, and it is genuinely better than a router's. packet-tracer walks a simulated packet through the entire path — routing, NAT, ACLs, inspection — and tells you which rule matched and where it was dropped, without touching live traffic.

ciscoasa# packet-tracer input inside tcp 192.168.1.10 12345 203.0.113.20 443 detailed

ciscoasa# show conn count
ciscoasa# show xlate detail | include 192.168.1.20
ciscoasa# show access-list OUTSIDE-IN
ciscoasa# show asp drop frame acl-drop

show asp drop is the counter you check when traffic vanishes with no log entry: it breaks the drops down by reason, so an acl-drop means your policy is working and a no-route means you forgot a route. Where packet-tracer answers "what would happen", show asp drop answers "what is happening".

Saving, backups and the file system

An ASA will happily run for years without a reload, which is exactly why configuration backups rot. Treat the running config as code: pull it nightly, diff it against the previous copy, and alert on the difference.

ciscoasa# copy running-config startup-config
ciscoasa# copy running-config disk0:/backup-core-fw.cfg
ciscoasa# show disk0:
ciscoasa# show version | include System image
ciscoasa# dir flash:
ciscoasa(config)# boot system disk0:/asa994-smp-k8.bin

Pin the image with an explicit boot system statement before you upgrade. If you merely copy a new image to flash and reload, the ASA may boot the wrong one, and recovering a firewall that failed to boot is far slower than reading one extra line of documentation. Compare the same operational discipline against your other platforms with our PAN-OS commit troubleshooting guide, which walks a similar save-and-verify loop on a different vendor.

Failover: two firewalls that behave as one unit

Active/standby failover is the configuration most people get wrong, because the two units must agree on almost everything and disagree on exactly the right things. Both share the same configuration file; only the roles differ.

ciscoasa(config)# failover
ciscoasa(config)# failover lan unit primary
ciscoasa(config)# failover lan interface FAILOVER gigabitethernet0/4
ciscoasa(config)# failover interface ip FAILOVER 10.10.10.1 255.255.255.252 standby 10.10.10.2
ciscoasa(config)# failover link FAILOVER
ciscoasa(config)# failover key ThisIsTheClusterKey
ciscoasa(config)# monitor-interface outside
ciscoasa(config)# monitor-interface inside

The standby takes the primary's configuration but keeps its own failover IPs, which is why each unit needs a distinct address on the failover link and a matching failover lan unit role. monitor-interface is the list of interfaces whose failure triggers the switch — include everything in the data path, and nothing you do not want to cause a failover. Verify with show failover, which prints the state of both units and the reason for the last switch.

Site-to-site VPN in a few lines

An IKEv2 route-based tunnel between two ASAs follows a fixed recipe: define the protected networks as objects, build a tunnel group, then a crypto map that ties the peer, the policy and the ACL together.

ciscoasa(config)# object network REMOTE-LAN
ciscoasa(config-network-object)# subnet 10.50.0.0 255.255.255.0
ciscoasa(config-network-object)# exit

ciscoasa(config)# access-list VPN-TRAFFIC extended permit ip object INSIDE-NET object REMOTE-LAN

ciscoasa(config)# crypto ikev2 policy 10
ciscoasa(config-ikev2-policy)# encryption aes-256
ciscoasa(config-ikev2-policy)# integrity sha256
ciscoasa(config-ikev2-policy)# group 14
ciscoasa(config-ikev2-policy)# prf sha256

ciscoasa(config)# tunnel-group 198.51.100.5 type ipsec-l2l
ciscoasa(config)# tunnel-group 198.51.100.5 ipsec-attributes
ciscoasa(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key SUPERSECRETKEY
ciscoasa(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key SUPERSECRETKEY

The troubleshooting command to remember is show crypto ikev2 sa followed by show crypto ipsec sa. If the IKEv2 SA is up but no IPsec SAs exist, the mismatch is almost always in the traffic ACL or the peer's local network definition, not in the crypto policy. Bring the tunnel up with packet-tracer in the same way you would test an ACL: the tool reports a VPN action rather than a plain forward, which confirms the interesting traffic matched.

Licensing and feature tiers

An ASA with a base licence will route and filter, but several features you may be counting on live behind stronger licences. The three tiers most deployments touch are the base image, Security Plus (which unlocks active/active failover and additional contexts), and AnyConnect / Plus Apex for remote-access VPN with the full client profile. Check what you actually hold before you design failover:

ciscoasa# show version
ciscoasa# show activation-key
ciscoasa# show license features

The practical rule: if a feature is in your design, prove it with one of these commands on the exact hardware you will deploy. Discovering a licence gap during a failover cutover is a far more expensive lesson than reading the key once.

A commissioning checklist

Run this sequence on every new ASA before it touches production, in order:

1. Set the hostname, domain name and time zone so logs are correlatable.
2. Configure the outside interface and default route, then confirm ICMP echo reaches the ISP gateway.
3. Configure the inside interface and enable DHCP or a static pool, then confirm a client gets a lease.
4. Add object NAT and prove outbound browsing works with packet-tracer.
5. Add only the inbound ACL entries you have a ticket for, and attach the access-group.
6. Lock down management: RSA key, SSH v2, management subnet, AAA to RADIUS.
7. write memory, then copy the config off-box and commit the copy to Git.

Do it in that order because each step depends on the last, and a firewall that fails at step 2 makes every later symptom a guess. Once the base is stable, layer on the extras — failover, site-to-site VPN, and application inspection — one at a time, verifying after each.

原文链接：https://www.cisco.com/c/en/us/td/docs/security/asa/asa922/configuration/general/asa-922-general-config/intro-start.html