Does pfSense 2 have a SIP ALG?

wallabybob

My sip experience with pfSense has been for outgoing calls only. Some time ago it seemed to be necessary to use siproxd because some Linux based sip software was including routing information with host names in sip packets. (It was a while ago and I can't be sure I remember the details.)

siproxd can be installed from the System -> Packages menu.

Is the trouble with incoming calls? outgoing calls? both?

@neik:

Previously we just relied on the SIP Registration from our PBX to pass out through the firewall and open up the required port as is normal with NAT. The random nature of the source port didn't seem to matter. We are using port 65002 as it is a SIP trunk.

The "port opening" you describe will open only the source port on the registration attempt. That is, it will not tell the firewall to allow traffic from your provider addressed to a destination port that is different from the source port used in the registration.

AndrewZ

Fortunately, there is no SIP support and everything works like a charm. Port forwarding or "opening" is required only if you're serving SIP registrations from outside.
If pfSense has dynamic WAN IP, we (users) still need to take care about NAT table flush on IP change, as it's not considered as a bug by developers.

dhatz

@AndrewZ:

If pfSense has dynamic WAN IP, we (users) still need to take care about NAT table flush on IP change, as it's not considered as a bug by developers.

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

Check http://redmine.pfsense.org/issues/1629

jimp

The only thing not considered a bug by developers are vague problem reports with no concrete/substance. I personally have put a lot of work into state clearing on 2.1 to make sure it happens in more scenarios than ever when a WAN goes down/back up, and I know Ermal has done even more work than that.

There may be some issues out there still but without more solid evidence/troubleshooting than a few "it's still broken!" messages, it'll never get solved.

chpalmer

Sip was never designed to be behind NAT and many changes have had to come about to make it work for the consumer. I can tell you that a single Vonage ATA with two numbers works flawlessly behind pfSense.

My present company uses their own servers for SIP and passes you directly to their carrier servers for RTP. Firewalls don't really get along very well seeing what they see as unsolicited traffic from the RTP servers so they tend to block the traffic. Imagine that.

Ive had very good luck using siproxd with all the numbers I have here with my one carrier and the two separate SIP servers Im connected to. (not Vonage in this case)

In my opinion its the SIP providers and client devices that have not figured out how to correctly negotiate the firewall. Since some work so well and others need to be massaged so much.

If your trying to do double NAT with SIP you probably should just call Ma-Bell now and beg for your copper back.

AndrewZ

@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.

AndrewZ

@jimp:

The only thing not considered a bug by developers are vague problem reports with no concrete/substance. I personally have put a lot of work into state clearing on 2.1 to make sure it happens in more scenarios than ever when a WAN goes down/back up, and I know Ermal has done even more work than that.

There may be some issues out there still but without more solid evidence/troubleshooting than a few "it's still broken!" messages, it'll never get solved.

jimp, fully agree with you, users should be always more specific.
Are you saying that it's not necessary to manually clear sates in 2.1? If yes - that's great. I'm still on 2.0 (2.0.2), so I will probably wait for 2.1 release.
Thank you.

jimp

@AndrewZ:

jimp, fully agree with you, users should be always more specific.
Are you saying that it's not necessary to manually clear sates in 2.1? If yes - that's great. I'm still on 2.0 (2.0.2), so I will probably wait for 2.1 release.
Thank you.

2.1 tries a bit harder to clear states, but there are some people who still say it's broken (check the ticket linked earlier in this thread) but they haven't given any details to support their claim that I've seen.

dhatz

@AndrewZ:

@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.