A clear path
through Palo Alto Networks.

01 / Before configuration

Collect the service details.

Start with the service order and installation information, not an example from another circuit. Confirm the physical handoff, the expected speed, connector and optic requirements, whether the service is tagged with a VLAN, and the agreed MTU. Verify any required negotiation, FEC, or link aggregation with both equipment vendors.

Obtain the actual interface address and prefix, gateway or routing instructions, and any separately routed public address block. Confirm which side owns each device and whether Stealth or another provider supplies the handoff equipment. Keep provider-assigned addressing separate from your internal network addressing.

If Panorama, an HA pair, or another team manages the firewall, coordinate the change there. A standalone example is not a substitute for that configuration or the operator’s failover plan.

02 / Physical connection

Check the link first.

Connect the intended firewall data interface to the agreed handoff using supported optics and cabling. A lit port is a useful start, but confirm operational speed and state on both sides. If the link is down or negotiates differently than expected, review the port, optic, cabling, and settings with the responsible teams.

A service may be delivered through an existing switch or router rather than directly to the firewall. Check every interface along that path. A VLAN tag or MTU mismatch can prevent traffic from working even when the physical link is up.

03 / Interface and zone

Configure the external data interface.

For the illustrated routed design, an administrator selects the external Ethernet interface under Network → Interfaces, chooses Layer3, and assigns it to the appropriate external security zone and routing instance. On a legacy routing-engine configuration, that instance is a virtual router. Advanced Routing uses a logical router and a different workflow.

Enter the IPv4 address and prefix assigned to the firewall’s side of the handoff. Configure the internal interface, zone, and routing according to the existing LAN design. A zone called “untrust” or “trust” is a common example; the actual names in your configuration may differ.

set network interface ethernet ethernet1/1 layer3 ip 198.51.100.2/30

See Palo Alto Networks’ Layer 3 interface instructions for your release. Its interface and zone walkthrough includes vendor screenshots.

04 / Routing

Tell the firewall where Internet traffic goes.

In a static routed design, the firewall generally needs a default route toward the provider’s next hop. In the legacy routing engine, Palo Alto’s workflow is under Network → Virtual Routers → Static Routes. An IPv4 default route has destination 0.0.0.0/0; enter the actual gateway supplied for your service and verify the routing instance and outgoing interface.

Advanced Routing uses logical routers rather than the legacy virtual-router workflow. Follow the documentation for the engine already in use; do not change routing engines just to follow this example. If your design uses BGP, a separate router, multiple providers, or policy-based forwarding, confirm the actual route and return path with your network team.

05 / Security policy and NAT

Allow the intended traffic.

A route tells the firewall where traffic can go. A security rule determines whether that traffic is permitted. Review the relevant source and destination zones, users or addresses, applications, and security profiles under the organization’s policy. Test the specific intended traffic rather than adding a broad allow rule to make the connection appear to work.

When internal clients use private IPv4 addresses, outbound source NAT is commonly needed. If so, configure an appropriate source NAT rule for the actual design and public address. NAT requirements differ for routed public address blocks, inbound services, and IPv6. NAT alone does not permit a session; the matching security policy must also allow it.

Use Palo Alto’s policy-match and NAT-match tools with a representative flow. A match is a useful configuration check, but it does not prove a real session succeeded. Confirm the return route, translation, policy logs, and the application itself. Do not disable security inspection or expose administrative services as a routine troubleshooting step.

06 / Verify the result

Work outward from the handoff.

1. 01

   Review and commit

   Confirm the intended interface, routing instance, address, route, policy, and NAT. Review the candidate changes and commit through the appropriate firewall or Panorama workflow. Keep the rollback plan available.

2. 02

   Check the link and gateway

   Verify the interface is operational at the expected speed. Where the provider permits, test the gateway from the appropriate data-plane source; a device that does not answer ping is not necessarily unreachable for all traffic.

3. 03

   Check a client

   From an authorized wired client, test a public destination and a business application. Confirm DNS, the intended route, and the return path. For a new installation, compare upload and download performance with the agreed acceptance plan.

4. 04

   Record the baseline

   Save the time, interface state, counter values, and test conditions. Review both IPv4 and IPv6 when the service and network use them.

07 / Troubleshooting

Follow the evidence, one layer at a time.

Use the appropriate read-only commands for your device and PAN-OS release. The prompts below are illustrative; replace interface names and addresses with your own. Output differs by platform and permissions.

show interface ethernet1/1

show routing route

> show interface ethernet1/1
Name: ethernet1/1
Link status:
  Runtime link speed/duplex/state: 1000/full/up

Logical interface counters read from CPU:
  packets received                         916417
  packets transmitted                      816119
  receive errors                                4
  packets dropped                               0

ping host 8.8.8.8

ping source 198.51.100.2 host 8.8.8.8

Compare physical and logical error or discard counters at two recorded times, and compare them with the connected switch or provider handoff. Increasing counters are a reason to investigate; a counter alone does not establish which device or link caused the user’s problem. Avoid clearing counters before recording them.

show arp all

show advanced-routing route

For a live session issue, examine the applicable security and traffic logs, route and NAT behavior, and session information for an authorized test flow. With Advanced Routing, use the corresponding show advanced-routing route or FIB commands documented for your release. In an HA deployment, check which peer is active and how the handoff and sessions behave during failover.

08 / Capacity and performance

Can the whole path carry the traffic?

Interface speed is not the same as firewall throughput with the business’s security features enabled. Check the model’s current specifications and expected workload, including inspection, VPNs, session counts, packet sizes, and logging. Measure CPU or dataplane resources and interface utilization during the issue; a five-minute average can miss short bursts.

show running resource-monitor

For high-speed throughput testing, use separate capable client and server systems across the path being tested. An authorized iperf3 test with parallel streams can be useful; verify the firewall and test hosts can handle the intended rate. Coordinate the test because it may consume production capacity. Our performance guide explains the test and its limits.

Latency, loss, and jitter can affect application experience even when a throughput test looks good. Compare like-for-like measurements and test the specific path and application involved.

09 / Escalation

What to have ready.

• Service address and circuit identifier; the affected interface and handoff location.
• Start and end times with time zone, affected services, and whether the issue is ongoing.
• Operational link state, speed, and relevant physical and logical counter changes from each accessible side.
• Source and destination, address family, test method, results, and whether a wired client or VPN was used.
• Recent configuration changes and the results of route, policy, NAT, and application checks.

Share diagnostics through an approved support channel; configuration exports and traces can contain sensitive network information. For Stealth service, contact support@stealth.net or +1 212 232 2020. Your firewall administrator or Palo Alto Networks support can help with firewall-specific policy and device behavior.