Juniper SRX firewall consulting

The SRX is the firewall I reach for first, and the one I’m called in to fix most often. I work on everything from branch SRX300-series boxes to data center edge clusters, usually alongside the routing and switching around them.

What I help with

IPsec VPNs that won’t come up. Site-to-site tunnels stuck in IKE phase 1 or phase 2 are the single most common SRX call I get. The cause is rarely the obvious one: a pre-shared key mismatch, a proposal that doesn’t line up with the peer, a proxy-ID problem on a route-based tunnel, an upstream filter blocking UDP 500 or 4500, or a host-inbound-traffic setting on the wrong zone. I work through it methodically from show security ike security-associations and traceoptions until the tunnel is up and stays up.

Third-party VPN peers. SRX to Meraki MX, Palo Alto, Cisco, Azure and AWS gateways, including the policy-based versus route-based mismatches that cause most interop problems.

Chassis clusters. Building new clusters, migrating standalone units into a cluster, fabric and control link design, redundancy groups and interface monitoring, and in-service upgrades without surprises.

Upgrades and recovery. Junos upgrades including USB-based installs, recovery snapshots, and getting a box back from a failed upgrade.

Policy and NAT cleanup. Reviewing a rulebase that has grown for years, removing shadowed and unused rules, and restructuring zones so the policy reads clearly.

Edge services. DHCP on the SRX, PPPoE, VLAN-tagged WAN handoffs, and dual-ISP failover.

Migrations to SRX. Moving from Palo Alto, Meraki, Cisco ASA or older Juniper ScreenOS and SSG platforms, including policy translation and a tested cutover plan.

How engagements usually work

Most SRX work starts as a fixed block of remote hours: you give me read access or a screen share, I find the problem, fix it, and write up what changed and why. Larger migrations are scoped as a project with a written cutover and rollback plan.