SIP ALG and VoIP NAT setup on pfSense

Understand what pfSense does by default

pfSense does not normally rewrite SIP payloads with a built-in consumer-router-style ALG. Therefore there may be nothing labelled SIP ALG to disable. The fault may instead be NAT source-port translation, state timeout, double NAT, PBX SDP or an optional proxy package.

• Record the pfSense Plus or CE version, WAN type, NAT mode and affected endpoint addresses.
• Check System > Package Manager for siproxd or any other deliberately installed SIP proxy and document why it exists before disabling/removing it.
• Check for an upstream ISP router performing another layer of NAT or ALG.
• Back up Diagnostics > Backup & Restore before modifying outbound NAT or state behaviour.

Diagnose NAT before creating a static-port rule

1. 1
   Check the SIP client first

   Confirm registrar, transport, registration interval, advertised/public address handling and keepalive behaviour. A 401/403 credential error is not a NAT problem.

2. 2
   Inspect states and packet paths

   Use Diagnostics > States and Packet Capture with narrow host/port filters to see whether the source port changes or return traffic is denied. Redact SIP authentication before sharing.

3. 3
   Test without optional proxying

   If siproxd or another installed helper intercepts the flow and is not required by the supported design, disable it in a change window and create fresh states.

4. 4
   Change NAT only with evidence

   Netgate notes static port can help some VoIP devices, but static UDP/5060 rules can break multi-phone scenarios. Keep the rule scoped to the exact PBX/phone and required destination/ports.

Create a narrow Hybrid Outbound NAT rule if required

1. 1
   Open Outbound NAT

   Go to Firewall > NAT > Outbound and change from Automatic to Hybrid Outbound NAT so automatic rules remain and a precise manual rule can be added.

2. 2
   Add the smallest possible rule

   Choose the WAN interface, exact PBX/phone source address or alias and only the protocol/destination scope proven necessary. Select Static Port so pfSense preserves the source port.

3. 3
   Avoid a broad UDP/5060 rule

   A network-wide static-port rule can cause collisions when several phones use the same source port. Scope per device/provider or follow the PBX vendor’s supported NAT design.

4. 4
   Apply and create fresh states

   Apply changes and reset only the affected endpoint states or registration during the window so the new NAT rule is used.

Use state tuning sparingly

For unexplained registration loss, Netgate’s VoIP recipe discusses Conservative state handling as a possible aid. Apply it only to an understood case, measure the larger state-table impact and prefer endpoint keepalive/registration settings that match the service.

• Do not increase timeouts globally without checking state capacity and security impact.
• Do not forward the full RTP range from any source for registered phones.
• For direct IP, build explicit provider-source rules using only the issued signalling and media ranges.
• Keep webConfigurator and SSH management restricted to trusted networks and use current patches.

Test pfSense changes with fresh states

1. 1
   Confirm registration stability

   Observe more than one registration interval and check that the mapped address/port stays compatible with the endpoint design.

2. 2
   Make calls both ways

   Verify inbound routing, outbound caller ID and the SIP response path.

3. 3
   Check media

   Verify two-way audio, keypad tones, transfer and a call longer than five minutes while watching state and packet counters.

4. 4
   Remove unjustified exceptions

   If the narrow static-port or state change did not alter the symptom, roll it back rather than leaving unnecessary complexity.