A clear route
through the SRX.

01 / Plan the connection

Confirm the handoff and responsibilities.

Obtain the service address, port speed and media, optic and cable requirements, VLAN tagging, MTU, and any required negotiation, FEC, or aggregation. Record the actual interface address and prefix, provider gateway or routing details, and any separately routed public address block. Confirm which team owns each device along the handoff.

Identify the SRX model, Junos release, routing instance, zones, and whether J-Web, the Junos CLI, or centralized management owns the configuration. Check HA or chassis-cluster requirements before changing an active pair. Document a maintenance window, current configuration, recovery access, and rollback plan.

02 / Handoff and addressing

Connect the external interface.

Connect the provider handoff to the intended SRX data port using supported media. Confirm the physical link is up at the expected rate and compare settings with the connected equipment. If a switch or router sits in between, inspect that path too; a working physical link does not by itself confirm the VLAN, address, route, or policy.

For this routed IPv4 example, configure the correct logical interface with the assigned address and prefix and place it in the intended external security zone. Junos typically represents logical interface units with a suffix such as .0. Configure the internal interface and zone according to the existing business network.

Some SRX models ship with default zones, addressing, and policies, but those settings differ by model and may have been changed. Inspect the existing configuration rather than assuming factory defaults apply.

03 / Routing

Point the default route toward the provider.

In a static routed IPv4 design, the appropriate routing table needs a default route for destinations without a more specific match. Use the actual provider next hop and the routing instance that carries the client traffic. A route in the wrong routing instance may not serve the affected flow.

For BGP, multiple providers, virtual routers, or policy-based routing, verify the actual design and return path. IPv6 requires its own address, route, security policy, and tests when used.

In Junos configuration mode, these illustrative statements show where the three example settings belong in the default routing instance. They are only part of a configuration:

set interfaces ge-0/0/0 unit 0 family inet address 198.51.100.2/30
set security zones security-zone untrust interfaces ge-0/0/0.0
set routing-options static route 0.0.0.0/0 next-hop 198.51.100.1

These statements do not remove existing DHCP settings or conflicting addresses and routes, create the inside network, or configure security policy and NAT. Before using the equivalent settings on an actual firewall, review the existing candidate and active configuration, access and HA requirements, change window, commit method, and rollback plan with the responsible administrator.

04 / Security and translation

Review the zones and the intended flow.

SRX security policies apply to traffic between zones. Confirm that the correct logical interfaces are assigned to the external and internal zones, then review the policies, address objects, applications, and logging for the traffic your organization intends to allow. A route does not itself authorize a session.

Private IPv4 clients commonly need source NAT to access public destinations. Choose the translation appropriate to your approved address and routing design. A routed public block, inbound service, or IPv6 deployment may require a different approach. NAT and the security policy are separate checks; do not add a broad permit policy merely to test connectivity.

For a real flow, verify policy and translation alongside the return route and session information. The names “trust” and “untrust” are examples; your zones may have different names or a more detailed segmentation plan.

05 / Apply and verify

Test in a controlled order.

1. 01

   Review the candidate

   Confirm the interface and unit, address, zone, route, policy, and NAT changes. Review differences and follow the team’s change and rollback procedure before commit.

2. 02

   Commit and check the device

   Use the approved Junos or management workflow, verify the commit result, and confirm that the expected interface and route are operational. Do not change an HA pair without its tested procedure.

3. 03

   Validate the client path

   Where authorized, test the gateway and a public destination, then DNS and a business application from a wired client through the firewall. A ping that receives no response is not conclusive on its own.

4. 04

   Record the baseline

   Save the test time, address family, interface counters, and results. Test upload and download with suitable endpoints and verify IPv6 separately if in use.

06 / Troubleshooting

Follow the traffic from the client.

Start with the affected client and destination, then check link state, VLAN, addressing, route, zone policy, NAT, and return path. A reachable management interface does not prove the client data path is working.

These are read-only Junos operational commands. Replace the example interface with your actual handoff port and select the correct routing instance where applicable. Output and permissions vary.

show interfaces ge-0/0/0 extensive

show route 0.0.0.0/0 exact

show security zones
show security policies

show security flow session

user@srx> show interfaces ge-0/0/0 extensive
Physical interface: ge-0/0/0, Enabled, Physical link is Up
  Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps
  ... other output omitted ...
  Input errors:
    Errors: 0, Drops: 12, Framing errors: 0
  Output errors:
    Errors: 0, Drops: 0
  ... other output omitted ...

Errors or missing responses are leads, not a complete diagnosis. Confirm whether counters are increasing, what each counter means for the platform, and whether the same symptoms occur at the handoff. Avoid clearing counters before recording them. If only names fail, check DNS separately.

07 / Performance

Test the path, not just the port.

Port speed is not a guarantee of firewall throughput with the enabled security features, VPNs, logging, packet sizes, and session volume. Check the model and workload, inspect device resources and interface utilization during the problem, and consider short bursts that may not appear in a five-minute average.

For a coordinated throughput test, use separate capable client and server machines across the path. An authorized iperf3 test with parallel streams can help, but both endpoints and every device in the path must be capable of the target rate. It can consume production capacity. See our performance guide for directions and limitations.

08 / Escalation

Record the evidence.

• Circuit identifier, service address, physical and logical interface, SRX model, and Junos release.
• Start and end times with time zone, affected applications and users, and any recent changes.
• Link state and speed, and physical-interface counter changes on each accessible side.
• Relevant routing instance, route, zone policy, NAT, and session findings for an authorized test flow.
• Test source, destination, address family, method, wired or VPN path, and HA state when relevant.

Share sensitive network details only through an approved channel. For Stealth service, contact support@stealth.net or +1 212 232 2020; involve your Juniper administrator or support for device-specific questions.