How to Configure a Cisco ASA Firewall: Step-by-Step CLI Guide
Quick answer: A working Cisco ASA baseline needs correctly addressed and enabled inside/outside interfaces, a default route, source PAT for the inside network, an access policy, and restricted management access. Configure and test those elements from a console or out-of-band session, use packet-tracer to verify the policy path, and save with write memory only after the expected traffic works and unwanted traffic remains blocked.
The steps below build a small routed firewall configuration from the CLI, for the engineer making the change and for the reviewer who has to approve it. The example uses ASA software in single-context routed mode, with one inside network and one static outside address. Use it as a lab template or a production planning reference; the addressing, permitted services, interface IDs, software branch, and rollback plan all have to match the actual appliance.
ASA and Firewall Threat Defense (FTD) are different software platforms. If the device runs FTD, do not paste ASA commands into its management CLI; first confirm the platform with show version and review the ASA vs FTD differences.
Before You Configure the Cisco ASA
Start with the model and software release, not with a generic command list. Interface behavior and the highest supported ASA branch vary by platform. Cisco’s ASA 9.24 release notes, updated March 2026, list ASA 9.20 as the final version for the Firepower 2100, ASA 9.16 for the ASA 5506-X, 5508-X, and 5516-X, and ASA 9.2 for the ASA 5505. A command that is valid in a current configuration guide does not prove that an older appliance can run the release that guide documents.
Run these read-only checks first:
show version
show interface ip brief
show running-config
show route
Confirm four things from the output:
- The appliance is running ASA software, not FTD.
- The firewall is in the intended routed or transparent mode and single or multiple context mode.
- The physical interfaces in the plan match the interfaces shown by the appliance.
- The running release is supported by the exact hardware model.
The example below uses routed physical ports named Ethernet1/1 and Ethernet1/2. That layout is common on current Secure Firewall appliances, but it is not universal. The Firepower 1010 and the Secure Firewall 200 series, 1210, and 1220 include switch-port behavior that can require VLAN and BVI configuration; on the Firepower 1010, switch ports cannot be configured as routed-mode interfaces. Firepower 4100 and 9300 chassis interfaces are a separate case again, provisioned through FXOS before an ASA logical device can use them.
Protect the Existing Configuration
Use console or verified out-of-band access for the first change. An incorrect interface, route, ACL, or SSH command can disconnect the session used to configure the firewall.
Back up the current running configuration to local flash before changing it:
copy /noconfirm running-config disk0:/prechange-asa.cfg
dir disk0:
The expected result is a new prechange-asa.cfg file in flash. Copy it to a protected external repository as part of normal change control.
Do not treat copy disk0:/prechange-asa.cfg running-config as a clean rollback. Copying a file into the running configuration merges it with the current configuration; conflicting commands can produce errors or unexpected results. For a production change, document the exact no commands needed to reverse each new line, keep console access available, and define the approved restore or reload procedure before the maintenance window.
Cisco ASA Example Topology and Address Plan
This guide uses documentation-only public addresses so that the example cannot collide with a real Internet assignment.
| Role | Interface or host | Address | Purpose |
|---|---|---|---|
| ISP next hop | Upstream router | 203.0.113.1/30 | Default gateway for the ASA |
| Outside | Ethernet1/1 | 203.0.113.2/30 | Public/WAN side, security level 0 |
| Inside | Ethernet1/2 | 192.168.10.1/24 | LAN gateway, security level 100 |
| Test client | Inside host | 192.168.10.10/24 | Source used for policy validation |
| Management source | Inside subnet | 192.168.10.0/24 | Network allowed to initiate SSH |
Replace every address with an approved value before implementation. Also confirm that the inside network does not overlap any VPN, branch, cloud, partner, or management subnet. Overlap can turn a simple Internet-access configuration into a routing and NAT design problem.
Configure the Cisco ASA Firewall Step by Step
The steps below deliberately separate interface, routing, translation, policy, and management. Test after each layer instead of pasting the entire article into a production firewall.
1. Enter Configuration Mode and Set the Device Identity
From the console:
enable
configure terminal
hostname ASA-BRANCH-01
domain-name example.com
The prompt should change to ASA-BRANCH-01(config)#. The domain name also supports key generation for SSH. Replace example.com with the organization’s actual management domain when appropriate.
These commands change the running configuration immediately. They are not persistent across a reload until the configuration is saved.
2. Configure the Outside and Inside Interfaces
Configure the outside interface first, but keep the console session open:
interface Ethernet1/1
nameif outside
security-level 0
ip address 203.0.113.2 255.255.255.252
no shutdown
exit
Then configure the inside interface:
interface Ethernet1/2
nameif inside
security-level 100
ip address 192.168.10.1 255.255.255.0
no shutdown
exit
nameif creates the logical interface names referenced by routes, NAT rules, ACL bindings, and management commands. The security level ranges from 0 to 100. In the baseline design, inside is the higher-trust side and outside is the lower-trust side.
Verify the result before continuing:
show interface ip brief
Both interfaces should show the intended IP address and an operational status. If an interface remains down, check cabling, the connected switch port, port speed/negotiation, and whether the interface also needs to be enabled at the FXOS layer on the applicable chassis.
Rollback for this step: If the addressing is wrong and console access is intact, return to the affected interface and replace only the incorrect lines. To change an interface name, re-enter nameif with the new value. Do not use the no form of the command, because that deletes every command referring to the old name — routes, NAT rules, access groups, and management lines included.
3. Add the Default Route
Send destinations that are not in a more specific route to the ISP gateway:
route outside 0.0.0.0 0.0.0.0 203.0.113.1 1
The final 1 is the administrative distance. Verify the route:
show route
The routing table should contain a candidate default route through 203.0.113.1 on outside. If the outside interface receives its address by DHCP, the alternative is ip address dhcp setroute under the interface; do not combine that learned default route with an unnecessary duplicate static route.
Rollback for this step:
no route outside 0.0.0.0 0.0.0.0 203.0.113.1 1
4. Configure Dynamic PAT for Inside Users
Private inside addresses are not routable on the public Internet. Create a network object and translate its connections to the outside interface address:
object network INSIDE-NET
subnet 192.168.10.0 255.255.255.0
nat (inside,outside) dynamic interface
exit
This is interface PAT: multiple inside hosts share the outside interface address while the ASA tracks their individual connections by transport ports. PAT does not by itself permit any unsolicited inbound connection, which needs a separate published-service design.
Verify that the rule exists:
show nat detail
After a client creates a connection, inspect active translations with:
show xlate
Rollback for this step: Enter the INSIDE-NET object and remove its nat (inside,outside) dynamic interface line. Do not delete the object until you confirm that no ACL, NAT, VPN, or monitoring policy also references it.
5. Decide Whether to Apply an Inside Access List
In the basic security-level model, ASA permits traffic from a higher-security interface to a lower-security interface unless an access rule changes that behavior. Return traffic for an allowed stateful connection is tracked automatically. Traffic initiated from outside toward inside is not permitted merely because PAT exists.
That default is useful for initial connectivity, but it is not a least-privilege egress policy. A production design should explicitly define which inside sources can reach which services. The following example permits DNS, HTTP, and HTTPS from the inside network and denies other new inside-initiated traffic through the ACL’s implicit deny:
access-list INSIDE-IN extended permit udp object INSIDE-NET any4 eq domain
access-list INSIDE-IN extended permit tcp object INSIDE-NET any4 eq domain
access-list INSIDE-IN extended permit tcp object INSIDE-NET any4 eq www
access-list INSIDE-IN extended permit tcp object INSIDE-NET any4 eq https
access-group INSIDE-IN in interface inside
Do not apply this sample unchanged if clients also need NTP, email, SaaS-specific ports, voice, site-to-site VPN traffic, internal data-center routes, or an enterprise DNS resolver. Inventory the real dependencies and replace broad destinations with approved objects where possible.
Check the installed entries and their hit counters:
show access-list INSIDE-IN
When testing a changed policy, open a new client connection. An already-established session runs on the policy that was in effect when it was created, so a browser tab left open across the change can mask the result. If an approved test requires removing stale state, identify the exact session with show conn and use a filtered clear conn command. Do not run an unqualified clear conn; it terminates all through-the-box connections.
One logging behavior matters here. With default logging, the ASA records syslog message 106023 for explicitly denied flows only, and traffic dropped by the implicit deny at the end of the list is not logged at all. A service you forgot to permit therefore fails silently in the log as well as on the wire, which is why packet-tracer rather than show logging is the reliable way to find it.
Rollback for this step: Remove the ACL binding first, which stops the ACL from filtering the interface without deleting the list:
no access-group INSIDE-IN in interface inside
Then review whether the ACL is referenced anywhere else before removing its entries.
6. Configure Restricted SSH Management
Use a dedicated management network whenever the design supports one. This compact example permits SSH only from the inside subnet. It uses a local password account to establish access; production environments should normally use enterprise AAA or public-key authentication with a tested local break-glass path.
crypto key generate rsa modulus 2048
username asaadmin password EXAMPLE-ONLY-CHANGE-THIS-9X privilege 15
aaa authentication ssh console LOCAL
ssh 192.168.10.0 255.255.255.0 inside
ssh timeout 10
Change the example credential before entering the command. On physical appliances, crypto key generate rsa modulus 2048 creates the host key; the ASA Virtual creates its key pairs automatically after deployment. Use the organization’s approved key type and size for a production build.
Current ASA software supports SSH version 2, so no SSH version command is needed. The ssh line restricts management access by source network and interface; an interface ACL is not additionally required to reach the ASA’s own SSH service.
Test the new SSH session from an allowed inside host while the console remains connected. Confirm that an address outside the approved management range cannot connect. Do not expose SSH broadly on the outside interface.
If the organization uses ASDM, enable HTTPS only for an approved management subnet:
http server enable
http 192.168.10.0 255.255.255.0 inside
ASDM access also needs an appropriate HTTPS certificate and authentication design for production. Avoid a blanket http 0.0.0.0 0.0.0.0 outside rule.
7. Optionally Provide DHCP to the Inside Network
Skip this step if another authorized DHCP server or relay already serves the inside subnet. Two DHCP servers on one LAN can give clients inconsistent gateways and DNS settings.
For a small directly connected LAN, the ASA can assign addresses and advertise DNS servers:
dhcpd address 192.168.10.100-192.168.10.199 inside
dhcpd dns 1.1.1.1 8.8.8.8
dhcpd enable inside
The address pool must be in the same subnet as the inside interface and must exclude the ASA address and all static reservations. Replace the public DNS example with the organization’s approved resolvers where required. In routed mode, the ASA sends its inside interface address as the default gateway unless DHCP option 3 is configured differently.
Disable the DHCP server with no dhcpd enable inside before removing or replacing its pool.
8. Validate Before Saving
Do not use a successful ping as the only acceptance test. ICMP handling differs from TCP/UDP state tracking and can require its own access rules or inspection behavior, so a failed ping next to working web access is usually an ICMP policy result rather than a routing or PAT fault. Test the traffic the design is actually intended to carry.
First, model a new HTTPS connection from the inside client to a documentation address:
packet-tracer input inside tcp 192.168.10.10 50000 198.51.100.10 443 detailed
packet-tracer evaluates the simulated packet against routing, NAT, access rules, and other policy stages. The final action should be allow, and the detailed phases should show the expected egress interface and translation. Then model a service that the inside ACL does not permit, such as TCP/25, and confirm that it is dropped:
packet-tracer input inside tcp 192.168.10.10 50001 198.51.100.10 25 detailed
Complete the checks with a real client connection and these show commands:
show interface ip brief
show route
show nat detail
show xlate
show access-list INSIDE-IN
show conn all detail
show logging
Verify both sides of the policy:
- The inside client can reach only the approved services.
- PAT creates the expected translation.
- The default route uses the intended gateway.
- Unsolicited outside-to-inside connections remain blocked.
- SSH works from an approved management address and fails from an unapproved source.
- No unexpected deny, interface, address-conflict, or licensing messages appear in the logs.
Only after the test passes should you save the running configuration:
write memory
copy running-config startup-config is the equivalent command. Save a new external backup after the approved change so that the recovery repository matches the production state.
Troubleshoot a Cisco ASA That Still Has No Internet Access
Follow the packet path in order. Changing NAT or ACLs at random often creates a second fault while leaving the first one in place.
| Symptom | First check | Likely cause or next action |
|---|---|---|
| Inside client cannot reach the ASA gateway | Client IP, mask, VLAN, and show interface ip brief | Wrong client addressing, wrong switch VLAN, or inside interface down |
| ASA cannot reach the ISP next hop | Outside link and ARP state | Wrong outside IP/mask, cable or upstream port issue, or incorrect gateway |
| No default route appears | show route | Wrong route syntax, DHCP route not received, or outside interface unavailable |
packet-tracer drops at ACCESS-LIST | show access-list INSIDE-IN | Required service missing, wrong object, or ACL bound to the wrong interface/direction |
packet-tracer reaches NAT but a real session fails | show xlate, show conn all detail, upstream routing | Return path, ISP filtering, destination service, or stale client session |
| Web access by IP works but names fail | Client DNS settings and DNS ACL entries | Wrong resolver, DNS server unreachable, or UDP/TCP 53 blocked |
| SSH fails from the LAN | show running-config ssh and show running-config aaa | Source subnet not allowed, key missing, local user/authentication missing, or wrong ingress interface |
Read the final packet-tracer drop reason before editing. If the tool shows a route lookup failure, changing an ACL will not repair the route. If it shows an ACL drop, adding another NAT rule will not repair the policy. Quiet log output does not rule out an access-policy drop, so use packet-tracer to verify the decision path.
Production Hardening After the Basic Configuration
The baseline establishes connectivity; it does not complete a production security design. Before placing the ASA in service, address the controls that match the site’s risk and operating model:
- Replace the sample egress rules with approved source, destination, service, and time requirements.
- Keep management on a dedicated network or tightly scoped source range; do not enable Telnet.
- Integrate TACACS+ or RADIUS where required, retain a controlled local recovery account, and review command authorization.
- Configure trusted NTP, centralized syslog, SNMPv3 or other monitoring, alerting, and scheduled configuration backups.
- Review Cisco security advisories, release notes, and the recommended release for the exact appliance. Confirm downgrade and rollback support for the exact platform before upgrading.
- Design failover, state synchronization, interface monitoring, and upgrade behavior if the site requires high availability.
- Add VPN NAT exemptions and VPN policy from the applicable ASA VPN guide; a generic Internet PAT rule is not a complete VPN design.
- Build inbound static NAT and outside ACLs only for approved published services. ASA access rules match the server’s real IP address even when NAT presents a different public address.
- Test negative cases, recovery access, and logging — not only the happy path.
If the appliance has already reached its final supported ASA branch, weigh another configuration cycle against replacement or migration before the work starts. That decision turns on the platform’s supported branch, open advisories, throughput, interfaces, licensing, and support coverage, and it belongs in its own change: the ASA-to-FTD migration guide covers the migration task, which should not share a maintenance window with a baseline build unless the project plan explicitly calls for both. The Cisco firewall comparison covers current-platform selection when the answer is new hardware.
Frequently Asked Questions
How Do I Allow an Internet User to Reach an Inside Server?
That requires a separate published-service design: static NAT or port translation, an outside access rule that references the server’s real address, a valid route, server-side listening service, and logging/monitoring. Do not add a broad outside permit rule. Limit the source networks and destination ports, test the rule with packet-tracer, and place public services in a properly designed DMZ where possible.
What If I Am Locked Out of the ASA?
Use the documented recovery procedure for the exact hardware and software mode. Do not erase the configuration as a first step. The Cisco ASA password recovery guide separates ASA appliance, Firepower platform, and newer Secure Firewall console behavior.
Official Cisco References
Primary Cisco references for this guide:
