SIP adapter behind pfSense - it works, but WHY??

fyap

Now, I have a rather unusual post. Not of something that does not work, but something that does when I don't expect it to. And it interests me greatly to know why. Here's my "problem":

I have 2 SIP ATAs behind pfSense, on the LAN interface. I used to have a Motorola modem/router until I replaced it with pfSense. On that older router, I had to setup port forwarding, open firewall ports, and even put one of the ATAs on the Mot's DMZ to get both to work. Considering all that's been said about SIPs behind a NAT, I expected to do the same on the new pfSense box when I switched to it - and initially I did have problems with it, such the SPA3102 not registering with the SIP provider, one-way audio (typical NAT problem symptom), etc. I tried siproxd but that didn't help.

Then, short of reflashing the CF, I did a Factory Default on the pfSense and setup everything (default settings only) from scratch. However, I DIDN'T set any port-forwarding or ANYTHING which I thought would help with the SIP/NAT issue. I turned the ATAs on and voila! I can make and receive calls on both ATAs. What puzzles me is that as far as I know I have not set anything in pfSense and even the ATAs to address the NAT traversal "issue" - for the ATA, no STUN enabled, no NAT Keep Alive, etc. If there's no port forwarding or STUN, how does pfSense know that an inbound SIP request is meant for one of the ATAs? Does anybody know of a tool I can use to see what's going on?

thanks

Environment:
pfSense 1.2.3 Embedded on an ALIX
Interfaces: LAN, WAN, WLAN, PPTP (all working)
Cisco/Linksys SPA-3102 ATA (unlocked)
Motorola VT1005S ATA (locked)
SIP provider for SPA3102: pennytel (although I could have used any SIP provider who gives free SIP accounts and access to their SIP proxy server)

Connections:
Internet <- (WAN) pfSense (LAN) -> Switch <- the 2 ATAs

My firewall rules:

LAN Rules
Type Proto Source Port Destination Port Gateway
Allow * LAN net * * * *

WAN Rules
Block * RFC 1918 * * * *
networks
Block * Reserved/not * * * *
assigned by
IANA

WLAN Rules
Allow * * * * * *

kpa

Look at Diagnostic->States and see what kind of connections are open related to your devices.

fyap

Here's a dump of my states table (with IP addresses changed to names), filtering by the ATA's ip address

Proto Source -> Router -> Destination State
udp sip_provider_ip:5060 <- ata1_ip:5060 MULTIPLE:MULTIPLE
udp ata1_ip:5060 -> wan_ip:5060 -> sip_provider_ip:5060 MULTIPLE:MULTIPLE
udp sip_provider_ip:5060 <- ata1_ip:5061 MULTIPLE:MULTIPLE
udp ata1_ip:5061 -> wan_ip:19272 -> sip_provider_ip:5060 MULTIPLE:MULTIPLE
udp ata2_ip:514 <- ata1_ip:60077 NO_TRAFFIC:SINGLE
udp ata1_ip:60077 -> wan_ip:8009 -> ata2_ip:514 SINGLE:NO_TRAFFIC

What comes as a surprise are the last 2 entries - why is my ATA1 talking to my ATA2? It turns out that I've previously set my ATA1 to send syslog entries to the syslog server on my PC, the old ip address of which is now that of ATA2.

If anybody can explain what the above means, it would be much appreciated, particular "MULTIPLE:MULTIPLE". From the above I still don't understand how an outside caller can find the ATA on my LAN without any port forwarding.

thanks again for your reply

danswartz

What I believe is happening: your ATA registers with provider(s) using UDP/5060 (SIP). When someone calls you, the call is set up via SIP invite, over the connection already established when you registered. The two hosts (ATA and remote media server) negotiate the UDP ports to be used for RTP. This doesn't always work (and I am not an expert on why), depending on how the calls are sent to you, so some people need to forward RTP ports, others not. In general, if your ATA or whatever registers with a remote SIP server, you won't need to forward UDP/5060. Note though: if you have multiple clients behind pfsense, you will probably need to enable AON and set static port.

CaseyBlackburn

Do you happen to have the Siproxd package installed?

fyap

Hi Casey,

Nope. At first I did, until I did a Factory Default as mentioned in my original post, which reset everything, including wiping out siproxd.