Does pfSense 2 have a SIP ALG?

dhatz

@dhatz:

What version are you using? In recent versions, pfSense tries quite a bit to flush NAT states upon WAN IP change.

I'm on 2.0.2 now and [historically] using the flushing script based on the one from 1.2.3 package.

Please clarify: Does the "flushing script" solve the stale SIP NAT state issue, whereas stock 2.0.2/2.1-BETA don't ? And in that case, could you compare the actions taken by the script with 2.0.2's /usr/local/sbin/ppp-linkup / ppp-linkdown?

/usr/local/sbin/ppp-linkdown: /sbin/pfctl -k 0.0.0.0/0 -k $3/32
/usr/local/sbin/ppp-linkdown: /sbin/pfctl -k $3/32
/usr/local/sbin/ppp-linkdown: pfctl -K $3/32
/usr/local/sbin/ppp-linkdown: /sbin/pfctl -b 0.0.0.0/32 -b ${OLD_ROUTER}/32
/usr/local/sbin/ppp-linkup: /sbin/pfctl -b 0.0.0.0/32 -b ${OLD_ROUTER}/32

koukobin

Try to use "Manual mode" for outbound NAT and enable "Static Port" option.

I running 3 years now a SIP PBX behind pfsense without a single problem. My PBX also accept SIP registrations from outside perfectly.

dhatz

koukobin the "static port" NAT option may sometimes help, but there are so many other parameters that can play a role in a SIP setup, that makes it very hard to offer "generic" advice.

AndrewZ

@dhatz:

Please clarify: Does the "flushing script" solve the stale SIP NAT state issue, whereas stock 2.0.2/2.1-BETA don't ? And in that case, could you compare the actions taken by the script with 2.0.2's /usr/local/sbin/ppp-linkup / ppp-linkdown?

/usr/local/sbin/ppp-linkdown: /sbin/pfctl -k 0.0.0.0/0 -k $3/32
/usr/local/sbin/ppp-linkdown: /sbin/pfctl -k $3/32
/usr/local/sbin/ppp-linkdown: pfctl -K $3/32
/usr/local/sbin/ppp-linkdown: /sbin/pfctl -b 0.0.0.0/32 -b ${OLD_ROUTER}/32
/usr/local/sbin/ppp-linkup: /sbin/pfctl -b 0.0.0.0/32 -b ${OLD_ROUTER}/32

"Flushing script" does help with the stale UDP (SIP) NAT state issue. I'm using DHCP, not PPP, so I'm not sure that the scripts mentioned are relevant to me. Anyway, I temporary removed my script and will check the states in a few hours. I cannot obtain the new WAN IP manually.
In my script I'm using:
/sbin/pfctl -F state

EDIT: after removing my flushing script I faced the stale entries issue again (2.0.2, DHCP)

dhatz

@AndrewZ:

"Flushing script" does help with the stale UDP (SIP) NAT state issue. I'm using DHCP, not PPP, so I'm not sure that the scripts mentioned are relevant to me.

In your case, the/etc/rc.newwanip script may be relevant, but I'll leave it for jimp/ermal to comment …

needclues

@dhatz:

koukobin the "static port" NAT option may sometimes help, but there are so many other parameters that can play a role in a SIP setup, that makes it very hard to offer "generic" advice.

laying out various use cases in the pfsense wiki would help so many [soho] users. It would help people become informed enough to generate useful bug reports

jimp

All of the most common SIP troubleshooting items are already on the wiki.

http://doc.pfsense.org/index.php/VoIP_Configuration

needclues

@jimp:

All of the most common SIP troubleshooting items are already on the wiki.

http://doc.pfsense.org/index.php/VoIP_Configuration

yeah I've already searched the wiki, and read the topics found. I was hoping for rules examples and voip usage not-using a [lan] pbx

this not voip wiki entry lays out rules examples http://doc.pfsense.org/index.php/Blocking_DNS_queries_to_external_resolvers

The rules examples will help home users of voip providers of lan ata, lan ip phones and whatnot.

Respectfully, I have some questions raised by the voip wiki.

When to use siproxd and when not? I use half a dozen voip providers. siproxd requires ONE outbound proxy. that doesn't seem like it will play well with different providers.

Disable source port rewriting - by default, pfSense rewrites the source port on all outbound traffic. This is necessary for proper NAT in some circumstances such as having multiple SIP phones behind a single public IP registering to a single external PBX.

such as having multiple SIP phones behind a single public IP

yes

registering to a single external PBX.

no

Could the latter be made true by using SIPsorcery? RentPBX and similar is crazy needless costly overkill for me I've discovered.

[default] rewriting the source port of RTP can cause one way audio.

it's not doing that thankfully

In that case, you want to use manual outbound NAT and Static Port on all UDP traffic potentially with the exclusion of UDP 5060.

when outbound NAT rules are not auto-created what responsibility have I assumed? is there a wiki on manually creating rules now that auto is disabled?

potentially with the exclusion of UDP 5060

why? Whatever is fiddling with 5060 can I add my voip providers alternate ports (5080 42872)?

In very rare circumstances, scrubbing needs to be disabled under System > Advanced.

there are only two mentions of scrubbing on the wiki neither provide helpful context.

siproxd package enables multiple phones to connect to a single outside server.

What's the suggested solution for multiple phones (and ATA) connecting to multiple outside servers?

The problems I'm having are (1) understanding how to wield pfsense better (2) ip phones unable to fetch confirm via tftp making them costly paperweights – which I'm sure comes back to pfsense ignorance.

![hoping for rules examples.png](/public/imported_attachments/1/hoping for rules examples.png)
![hoping for rules examples.png_thumb](/public/imported_attachments/1/hoping for rules examples.png_thumb)

chpalmer

When to use siproxd and when not? I use half a dozen voip providers. siproxd requires ONE outbound proxy. that doesn't seem like it will play well with different providers.

Quote
Disable source port rewriting - by default, pfSense rewrites the source port on all outbound traffic. This is necessary for proper NAT in some circumstances such as having multiple SIP phones behind a single public IP registering to a single external PBX.

such as having multiple SIP phones behind a single public IP

My multiple ATA's connect to multiple external SIP servers.

jimp

You only need siproxd if ALL of these are true:

You have multiple phones connecting to a remote PBX, or multiple PBXs
More than one of the phones connects to the same remote PBX
The PBX requires that the source port be 5060 for the phone's SIP traffic (this is not very common these days)

In most cases multiple phones work fine now with zero adjustments so long as the PBX doesn't assume/enforce a 5060 client source port.