Start an order
Technical guide • Cisco Secure Firewall

From the handoff
to your network.

Configure and troubleshoot a Cisco Secure Firewall Threat Defense connection to dedicated Internet.

Prepared by Stealth CommunicationsNovember 1, 2026Approx. 9 min read

The short version

How does the circuit reach the business?

In a common routed design, the provider handoff connects to the firewall’s outside data interface. The firewall needs the correct addressing and route; access-control policy and, where appropriate, network address translation determine how traffic from the inside network can reach the Internet.

Scope of this example

This guide illustrates a single routed firewall with static IPv4. Your service may use a switch, HA pair, tagged VLAN, BGP, IPv6, or a different topology. Use your actual service order and change process.

Conceptual connection from Internet to provider handoff, firewall and business LAN.
Conceptual path. Cisco configurations may call the external and internal zones “outside” and “inside”; the labels in your own design can differ.

This guide is for Cisco Secure Firewall Threat Defense. It does not describe an ASA software configuration. Management Center and Device Manager have different interfaces, and menus vary by software version and device. Follow the documentation for the system that manages your device.

01 / Plan the connection

Gather the service details.

Confirm the handoff location, port, speed, optics and cabling, VLAN tagging, MTU, and any required negotiation or FEC with the provider and equipment team. Obtain the actual outside address and prefix, gateway, and any separately routed public block from the service order. Verify the internal addressing and routing design with your network team.

Identify whether Firewall Management Center, cloud-delivered management, or Firewall Device Manager owns the configuration. Plan a change window, backup, out-of-band management, and rollback. For HA or clustered firewalls, coordinate cabling, address ownership, deployment, and failover with the team responsible for the pair.

Management and data are separate paths. Know which interface carries the Internet service and which path manages the firewall. Keep administrative access restricted; do not open management from the Internet merely to complete setup.

02 / Interfaces

Connect and identify the outside interface.

Check that the intended data port is physically up at the agreed speed and matches the connected handoff. A lit link does not by itself establish correct VLAN, addressing, route, or policy. Where switches sit between provider and firewall, check each link and its settings.

In Firewall Management Center, select the device under Devices → Device Management and edit its interfaces. For a routed design, identify the outside data interface, assign it to the intended security zone, and enter the address and prefix supplied for that interface. Configure the inside interface and zone to match the business network. The equivalent steps in Firewall Device Manager are performed locally through its interface configuration; deployment and screens differ.

  1. In the device editor, open Interfaces and edit the port selected for the outside connection.
  2. Enable the interface, give it an interface name, and assign it to the intended security zone. The interface name and zone are separate settings.
  3. Under IPv4, select static addressing when the circuit uses a static address. Enter the address and prefix supplied for the firewall, then save the changes.
  4. Review the pending changes and deploy them using your organization’s change process. Coordinate first if the change could interrupt remote management or existing traffic.
Example / Outside interface

Fields to review.

Illustration
This is a teaching aid, not a Cisco screenshot. Interface names and the documentation address are examples.
Routed outside interface
Interface
Ethernet1/1, if assigned in your design
Interface name
outside
Security zone
outside
IPv4
198.51.100.2/30

Replace these fields with your actual interface, zone, and provider-assigned settings.

Cisco’s interface walkthrough shows the vendor interface. Its example uses DHCP outside; follow the addressing method specified for your own circuit.

03 / Routing

Choose the path to the provider.

For a static routed service, configure the IPv4 default route in the appropriate routing context toward the provider gateway. In Management Center’s documented workflow, edit the device and select Routing → Static Route; use the outside interface, the IPv4 default destination, and the provider’s actual next-hop address.

Example only: If the outside address were 198.51.100.2/30 and the provider specified 198.51.100.1 as gateway, that gateway would be the example next hop for 0.0.0.0/0. These are documentation addresses, not a service assignment.

Use the appropriate configuration for multiple routing tables, BGP, backup links, or a separate router. IPv6 requires its own addressing, route, and policy review where used. A route alone does not permit traffic.

04 / Policy and translation

Permit the intended traffic.

Review the access-control policy assigned to the device. Match the correct source and destination zones, network objects, applications or services, and security inspection required by your organization. Do not use a broad allow rule as a substitute for identifying the intended flow.

Private IPv4 clients commonly need source NAT or interface PAT to reach the public Internet. Configure translation only when appropriate to the routed design and assigned addresses. A routed public block, IPv6, inbound services, and VPNs can require different handling. NAT and the access-control policy are separate; both must match the intended traffic, and the return path must work.

Check rule ordering and logging. Confirm security and NAT behavior for a representative flow using the tools available for your management system. A simulated match is useful evidence, but it does not prove an application session succeeded.

05 / Deployment

Apply and test the change.

  1. 01

    Review the candidate

    Confirm the interface, zone, address, route, NAT and access-control changes are intended for the right device and management domain.

  2. 02

    Deploy deliberately

    In Management Center, save and deploy the approved changes to the device; Device Manager uses its own deployment workflow. Watch for deployment errors and preserve access to the rollback path.

  3. 03

    Validate from a client

    With permission, check the link and gateway, then test DNS and an application from a wired client through the firewall. Confirm the return path and record the time and results.

  4. 04

    Record a baseline

    Record link state, interface counters, test method, and upload and download results. If IPv6 is in service, validate it separately.

06 / Troubleshooting

Follow one flow.

Start with a known affected client, destination, and time. Compare the provider handoff and firewall link state, VLAN, address, and route. Then check NAT, access-control and connection logs, and the return path. A working management connection does not establish that the data path works.

With access to the appropriate Threat Defense CLI, these are read-only starting points. Output and available commands vary with release, role, and CLI context; use the correct device and interface.

Threat Defense / Interface
show interface

Inspect data-interface status and statistics; identify the actual outside interface and compare counters over time.

Threat Defense / Routing
show route

Review the IPv4 data-interface routing table and intended default route. Management routing is distinct.

Simulated / Troubleshooting example

Reading an interface check.

Illustration
This is a simulated, abbreviated example for learning; it was not captured from a firewall. Output varies by model, release and CLI context.
THREAT DEFENSE / INTERFACE
> show interface
Interface Ethernet1/1 "outside", is up, line protocol is up
  IP address 198.51.100.2, subnet mask 255.255.255.252
  Traffic Statistics for "outside":
    125420 packets input, 19684000 bytes
    118200 packets output, 17320000 bytes
    12 packets dropped
  ... other output omitted ...
01

Up / up shows the interface and line protocol are up in this example; it does not establish that the route or applications work.

02

Address should match the address assigned to the firewall, not the provider gateway.

03

Packets dropped is a counter. Record its value and time, then check again to see whether it increases.

The address and counters are invented for this illustration. Counter names and meanings vary; check the documentation for your platform. Cisco documents routed interfaces and verification.

Compare physical interface errors and discards with the connected device and the same interval. Counters can have different meanings; an increment alone does not establish the fault location. Cisco’s Threat Defense diagnostic CLI guidance explains how selected commands can also be run through Management Center. If the CLI context or a command is unavailable, use the documented management view rather than switching modes blindly.

If only domain names fail, consult the business DNS guide. If tests from a client fail but management access succeeds, examine the client’s path and the firewall policy rather than assuming the two tests take the same route.

07 / Performance

Measure the whole path.

Port speed does not establish firewall throughput with inspection, VPNs, logging, and the actual packet mix enabled. Compare the model’s specifications to the intended workload and check device and interface resource utilization during the issue. Record deltas rather than clearing counters before support can inspect them.

For a coordinated high-speed test, use capable client and server machines on opposite sides of the path. An authorized iperf3 test with parallel streams can help; verify all equipment and the test endpoints can sustain the intended rate. Such a test can consume production capacity. See the performance guide for test directions and limitations.

08 / Escalation

Bring the useful evidence.

  • Circuit identifier, service address, handoff port, firewall model, software release, and management system.
  • Affected users or application, start and end times with time zone, and a known test flow.
  • Link state, speed, interface error and discard changes on both sides where available.
  • Routing, NAT and access-control findings; test source, destination, address family, and method.
  • Recent changes, relevant HA state, and what was observed from a wired client.

Diagnostics can contain sensitive addresses and configuration details. Use an approved channel. For Stealth service, contact support@stealth.net or +1 212 232 2020; involve your firewall administrator or Cisco support for device-specific behavior.

About this brief

Sources and further reading.

Cisco’s documentation is organized by device, software release, and management platform. Select the version that matches yours.

Configuration

Interfaces and routing

Security

Translation and access control

Troubleshooting

Commands and tools

Prepared by Stealth Communications, a provider of business connectivity. Cisco and Secure Firewall are names of their respective owner. This independent guide does not replace your service order or the vendor’s instructions.