next »

[iFloris]

Hello,

As of yesterday I have been having some trouble with forwarding sip.
This setup has worked for a couple of weeks without problems and suddenly it stopped working.
My forwarding setup is as follows:
For sip:
WAN   TCP/UDP   *   *   WAN address   5060 (SIP)   192.168.1.30   5060 (SIP)
For rtp:
WAN   TCP/UDP   *   *   WAN address   5004 - 5020   192.168.1.30   5004 - 5020
These NAT rules have linked firewall rules.

I also have Advanced Outbound NAT setup as follows:
Interface   Source   Source Port   Destination   Destination Port   NAT Address   NAT Port   Static Port
WAN      192.168.1.0/24    *    *    *    *    *   
YES

The problem is twofold. I cannot receive calls anymore and when calling out I only get one way audio.
I have been trying to see if the problem lies in the sip device which is a very simple Hybrid DECT IP base station but all seems well there.

To find out what the problem exactly is, I have tried scanning my ports from outside the lan and the forwarded ports look closed from the outside. Some other forwards I have in place can be seen as open.

Is there something that I have configured incorrectly or does someone have an idea what I can try to get phone calls working again?

Thanks in advance for any and all suggestions.

[craigduff]

What version of Pfsense are you using? Can the phones phone each other internally without problems?

[iFloris]

Hey Craigduff, thanks for your reply!

The pfsense version that I have been using is from the 2.1 dev branch
(specifically 2.1-DEVELOPMENT (i386) built on Sun Sep 11 21:36:53 EDT 2011
FreeBSD firebox1.virtualflo.com 8.1-RELEASE-p4 FreeBSD 8.1-RELEASE-p4 #1: Sun Sep 11 21:36:18 EDT 2011 root@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386)

This is the same version that I have been using since mid-september and the same version under which this configuration worked just fine.
The phones can call each other internally without issue.

For some reason, the forwarded sip port appears closed from outside.
In the firewall logs I can see that the device is talking with servers outside the lan.
There is quite a lot of chatter going from lan -> wan, but no traffic going from wan -> lan at all.

Example, making a call to my mobile phone:
Mar 27 11:58:47   LAN      192.168.1.30:5004      212.45.35.125:21162   UDP
Mar 27 11:58:21   LAN      192.168.1.30:60279      217.67.103.239:80   TCP:S
Mar 27 11:58:18   LAN      192.168.1.30:60278      217.67.103.239:80   TCP:S
Mar 27 11:58:15   LAN      192.168.1.30:32978      208.67.222.222:53   UDP
Mar 27 11:58:11   LAN      192.168.1.30:60277      176.9.12.26:80   TCP:S
 
This results in one-way audio. I can hear sound on the mobile phone, but on the handset there is no sound.
Hanging up on the mobile phone causes the handset to think that the connection is still live.
Calling from mobile to the sip line results in a 'this number is not available' message.

[chpalmer]

You will find that different voip providers are all very different...   Some are similar to others but that can change.  That being said- your provider could have made a config change that has caused issues.

In my case, my provider provides the sip server.  RTP comes from the carrier and a different server.  Think about how that looks to a firewall.


Are your devices registering to a service or do you have sip forwarded to you from the provider?

[dhatz]

If you have tried the obvious (ie cleared pf states, or even rebooted pfsense and the phone) I'd also think the most probable cause would be some change at the VoIP provider's end.

pf has the most restrictive type of NAT (typically found in enterprise routers), although recent developments in NAT traversal technologies (ie ICE) should make things easier.

[iFloris]

@chpalmer My provider also uses different servers for sip and rtp traffic. Things like STUN are not supported by my provider, so I am left with punching holes in the NAT.
My device is being forwarded sip traffic from the provider's server, but it also registers itself if that makes sense.

@dhatz At some point this weekend I tried rebooting every networked device just in case something was interfering. Unfortunately that did not help. Today I talked to a technical support agent who was assigned to my case by the provider.
We reviewed all the setting and all seemed well. So now I am left with the possibility that either the device is broken or there was a change on my provider's end that the tech support does not know about.

In any case, to me it no longer seems that pfsense is at fault.

[chpalmer]

Have you tried Siproxd?

[dhatz]

I think the first step should be to check pfsense's firewall log for any blocked connections from your VoIP provider (based on your description you'll find them).

I'd also check to see if there's any new firmware for your phone (newer firmware might implement the latest NAT traversal technologies), but I find it odd that STUN isn't supported by your provider.

[iFloris]

@chpalmer Not in this instance. I tried siproxd when first configuring the device but could not get siproxd and my provider to talk to each other.
As it is now it sure will not hurt to try again.

@dhatz Looking for blocked connections is the first thing that I tried but the strange thing is that there are no connections coming in from the wan side on port 5060, or so it seems.
Stun is not supported because officially my provider only supports their own router and sip client combination and in their particular configuration it seems that the sip device is in front of the nat. I am not sure how they do that.

Firmware updates on the phone.. That is something that I did not think of yet. This device (n300a by siemens) auto updates sip profiles and firmware. I will check to make sure everything is up to date even though I did not change anything manually.

[iFloris]

Just to finish this thread, I managed to solve this problem with help from my phone device manufacturer.
It turns out there was a mismatch between the firmware version on my device and the sip platform that my provider uses.
It appeared to be something very small that caused the provider to think there was no response from my end.

So, in the end, it wasn't related to pfsense at all.

Solved.