How to Configure a Juniper SRX300 Firewall for Emergency Phone System Deployment: A Step‑by‑Step Checklist

When You Need a Firewall Config – Fast

Last month at 4:00 PM on a Friday, a client called: their new Infinity Pro cordless phone system (NXP‑based base stations) was arriving Monday morning, and the network wasn’t ready. Normal lead time for a Juniper SRX300 deployment is three days. They needed it up in 48 hours – and I was the one who had to make it happen.

If you’ve ever had to rush a firewall configuration for a phone system you barely know, this checklist is for you. It’s not the full Juniper cookbook – it’s what I actually did, step by step, to get an SRX300 handling SIP traffic for a cordless phone fleet with zero downtime. I’ll also point out where I made mistakes (and how you can skip them).

There are 6 steps in this checklist. Follow them in order, and you’ll have a working firewall for your emergency phone deployment.

Step 1: Initial Access & Factory Reset (Don’t Skip the Clean Slate)

When you’re in a hurry, it’s tempting to just plug in the existing config from another site. Don’t. I learned that the hard way – the third time I reused an old config, I forgot to clear the previous security policies, and the phone system couldn’t register for two hours.

What to do:

• Connect to the console port (USB‑C or RJ45 – the SRX300 comes with both).
• Boot the device and press Space when prompted to enter the loader.
• Type recovery to perform a factory reset (or use request system zeroize once in the CLI).
• Set the root password immediately after reboot. (I use a standard temporary password like Temp_2025!RUSH and change it after deployment.)

Checkpoint: You should see the root@% prompt. Now you’re ready to configure.

Step 2: Set Up Interfaces & Zones – Map Your Network

The SRX300 has 8 built‑in Gigabit Ethernet ports. For a typical small‑office cordless phone deployment, I split them like this:

• ge‑0/0/0 – Untrust (WAN / Internet).
• ge‑0/0/1 – Trust (LAN for workstations and phones).
• ge‑0/0/2 (optional) – DMZ for the phone system’s management console (Infinity Pro recommends a separate subnet for the base stations).

I used to assume that “just put everything in Trust” was fine. Then the NXP‑based base stations started broadcasting mDNS across the entire LAN, causing chaos. Now I always isolate voice VLANs.

Commands snapshot:

set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.2/24
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/24
set security zones security-zone trust interfaces ge-0/0/1

Checkpoint: Test connectivity from the SRX to the Internet – ping 8.8.8.8 from the CLI. If that fails, check your ISP link or interface addressing.

Step 3: Create Security Policies – The Part That Will Bite You

This is where most rush jobs go wrong. You need to allow SIP and RTP traffic from the phone system (base stations) to the outside SIP trunk provider. But do not just open everything.

Here’s the rule set I use for an Infinity Pro system (NXP chipset – some older Broadcom‑based phones need different ALG handling, but we’ll keep it simple):

1. Trust → Untrust: Allow SIP (UDP 5060) and RTP (UDP 10000‑20000) from the phone subnet to the SIP provider’s IP.
2. Trust → Self: Allow ICMP and DNS (for the firewall itself) – otherwise the SRX won’t resolve domain names for NTP.
3. Untrust → Trust: For remote management via SSH (only from a specific admin IP), but not for the phone traffic – the SIP server should initiate the calls, not the other way around.

My biggest communication failure: I told the on‑site technician “just allow SIP.” He interpreted it as “allow any UDP from any source.” That oversight cost us half a day of debugging when the firewall started blocking legitimate registration requests from the phone system’s backup server. Be explicit.

Checkpoint: Use show security policies – you should see exactly 3‑4 rules, not a mess of “permit any.”

Step 4: Configure NAT (Don’t Forget the SIP ALG)

For the phones to reach the outside SIP provider, you need source NAT on the trust zone traffic going to untrust. The default SRX300 config does this if you use set security nat source rule-set trust-to-untrust.

But here’s the nuance: Juniper’s SIP ALG can break or help depending on the phone system. For Infinity Pro (NXP variant), I found it works best to disable the default ALG and let the phones handle NAT themselves via STUN. Otherwise, the SRX modifies SIP headers incorrectly, and calls drop after 30 seconds.

Command:

set security alg sip disable

I’m not 100% sure this applies to all cordless phone brands, but for NXP‑based base stations, it saved me. If you use Broadcom‑based phones, you might need the ALG – test both ways.

Checkpoint: After configuration, place a test call from a cordless handset. If you hear one‑way audio or no ringback, the ALG is probably the culprit.

Step 5: Time Sync & Logging – The Boring Stuff That Saves Your Bacon

In a rush, you skip NTP and logging. I did that once. Then the phone system’s call records showed timestamps off by 4 hours, and the client accused us of misconfiguring the firewall. Don’t be me.

Quick NTP setup:

set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org

Enable basic logging:

set security log source-address 192.168.1.1
set security log stream mylog host 192.168.1.100

Checkpoint: Run show ntp associations to confirm synchronization. Also send a syslog message manually (monitor start messages) to verify the log server receives it.

Step 6: Final Validation – The 15‑Minute Runbook

You think it’s working. But until you simulate a failure, you don’t know. Here’s my quick validation list (I created this after the third time a rush config broke at 2 AM):

1. Power cycle the base station – does it re‑register within 30 seconds?
2. Unplug the WAN cable for 10 seconds – does the SRX failover to your backup link (if you have one)?
3. Make a call and let it run for 5 minutes – check for jitter or dropouts.
4. Reboot the SRX itself – does the config come back clean? (I once lost the config because I forgot to commit after a late‑night change.)

If any step fails, go back to Step 3 and re‑examine your policies. Most issues come from overly broad (or overly restrictive) rules.

Honest Limitations – When This Checklist Doesn’t Fit

This checklist works for a single‑site deployment of up to 50 cordless phones with a basic SIP trunk. If you’re dealing with:

• A multi‑site VPN with QOS for voice,
• Phones that require complex TLS or SRTP encryption,
• Or a non‑NXP chipset that behaves differently (some Broadcom‑based units need the ALG on),

...then this list is a starting point, not a finish line. I’ve had to adjust for those cases and it usually adds 4‑6 hours of extra configuration.

But for the 80% scenario – an emergency deployment of an Infinity Pro system where time is measured in hours, not days – these six steps will get you a working firewall. I’ve done it three times in the last year, and the only regret is not having this checklist from the beginning.

One more reminder: After the rush is over, go back and harden the config. Remove the SSH admin access from untrust, set up proper logging, and document everything. Because the next emergency is never far away.