NAT Port Forwarding to Internal host UDP port 5060 not working as expected
-
Just to confirm that I was seeing a similar issue with 2.0.1 not forwarding UDP packets on port 5060 to my pbx, but I was only having problem with outbound calls whereby far end can never hangup the call properly (call still connected on my pbx leg until it times out). My provider correctly sends 200 OK for the call to the randomised port, but sends the BYE to port 5060, and pfsense just seems to ignore the latter, so pbx never saw the BYE.
If I were to go to diagnostic>states, and manually delete the firewall state entry (UDP) for an ongoing call, I found that disconnecting the call from far-end then worked fine, so this seems like port forwarding doesn't work if the firewall already have an existing state/connection for the same internal host ip/port.
As pointed out by the OP, creating a static manual outbound rule to 5060 for just my PBX seems to workaround this problem.
.
-
I'm having the same issue, with 2.01 and 2.03. Would be great if this bug could be fixed in the next release.
-
I don't think that the way SIP port is handled in pfsense is considered a bug by the developers. I think they consider it a security feature.
I could be wrong on that but I think they consider "static" port "Bad". Perhaps a button click on the outbound NAT menu to enable "static" on any outbound port 5060, 5061 and 500 without actually having to set up Manual Outbound NAT would be a nice happy middle ground? -
I don't think that the way SIP port is handled in pfsense is considered a bug by the developers.
It isn't.
I think they consider it a security feature.
Not really. More of a "breaks more than it helps" setup. Most phones these days do not need static 5060 on the way out to a remote PBX, only PBXs need that to trunks, and those can break in a lot more ways than just 5060, you really need manual outbound NAT to do static port for all UDP from the local PBX, or 1:1 NAT if you can.
I could be wrong on that but I think they consider "static" port "Bad".
It isn't bad, it just breaks more setups than it helps now. On 1.2.3 it was the other way because the majority needed it back then.
Perhaps a button click on the outbound NAT menu to enable "static" on any outbound port 5060, 5061 and 500 without actually having to set up Manual Outbound NAT would be a nice happy middle ground?
A better compromise is on my todo list for 2.2: http://redmine.pfsense.org/issues/2416
-
That is really nice, and it sounds like it was exactly what he was wanting.
-
Most weird. I'm using pfSense 2.03 since I'm in a production environment and 2.1 is a RC0 version. For me, the port forwarding for SIP & RTP inbound through my VoIP interface has always worked perfectly. The VoIP interface is configured with my public IP & Gateway to my SIP provider. My issue is the exact opposite: no one can make outbound calls. Launch3's posts may hold the key to what's wrong here. Using his two scenarios, my setup would be the one he refers to as "B".
-
Hmmmm…
For me, This is the way I see it.
For all devices inside the LAN that the Asterisk server is on, they don't need to know anything at all about the state of the connection further than the Asterisk server they are connected to. So, they get DNS inside the LAN and they get the LAN (private) IP of the Asterisk server and nothing more.
The Asterisk server needs to know its Behind NAT and it needs to know its private IP as well as its public IP.
Totally different than what the SIP phones need to know.So, on my Asterisk server here at home, it gets:
NAT - YES (This one is behind NAT with a dynamic IP)
Dynamic Host - mydynamicdns.domain.com (If you have purchased a static IP put it here)
Local Networks:
192.168.32.0 / 255.255.255.0 (network the asterisk server is on)
10.159.29.0 / 255.255.255.0
10.159.30.0 / 255.255.255.0
10.159.31.0 / 255.255.255.0 Long list of other local subnets behind my pfsense
10.159.32.0 / 255.255.255.0 Including any VPN subnets I want phones to work from
10.159.33.0 / 255.255.255.0
10.159.34.0 / 255.255.255.0No re-invite
No Jitter BuffersThe only thing I tell the SIP devices is the private IP address of the LAN side of the SIP server, username and password and that includes clients connecting in through VPNs.
Works for incoming and outgoing calls. Has for years.
P.S. Since RTP will always get broken when two layers of NAT are involved anyway, the only port I forward is 5060. Thats all.
I don't bother forwarding 10000 RTP ports hoping that a sip device outside my network will somehow magically work through NAT.
The Reason this works at all is because my SIP server is REGISTERED to a NON-NATed Trunk.
That doesn't work in reverse. If a SIP phone outside my network registers to my server without using VPN audio will be broken.
(I can't wait for IPV6! Can't get here soon enough for me so we can stop worrying all this NAT crap.)I wonder how many "network professionals" internet that just works will un-employ?
-
kejianshi: Please explain how you accomplished this:
I don't bother forwarding 10000 RTP ports hoping that a sip device outside my network will somehow magically work through NAT.
The Reason this works at all is because my SIP server is REGISTERED to a NON-NATed Trunk. -
At the trunks I register with, where the numbers are configured, I have all the incoming calls directed at port 5060, which is the only sip related port I have open, along with the extension/DID of the inbound call. Those hit asterisk which either sends the incoming call to IVR, the phone being called if the inbound DID matches an extension (Could be either SIP or IAX2 extension), or drops the call if its no match on my network. This works well for me because at least my trunk providers are either non-NATed or has a better NAT solution than me. Audio is good for me.
Actually, I'd love to have separate public IPs for every whim I get. It would make things easier, but being poor makes one creative.
-
I just got a PM from somebody having this same problem.
I've not been here in forever! but I am back.
I still believe it's a serious bug.
Like a number of people have stated, it's a braindead portforward and it's not working as expected and as other portforward rules are working.It should not EVER matter what in the doggone SIP headers, I don't know why that was even being discussed.
At the end of the day I think it's this "outbound port randomizer thing" that's causing the headaches and for whatever reason it's only seems to be happening
with UDP5060 SIP.It's not working like most people would expect it to work.
I did get around it as stated earlier by following the early suggestions.-Steve
-
Like a number of people have stated, it's a braindead portforward and it's not working as expected and as other portforward rules are working.
This ^^
At the end of the day I think it's this "outbound port randomizer thing" that's causing the headaches and for whatever reason it's only seems to be happening with UDP5060 SIP.
And this ^^
Are completely unrelated.
The port forward may work fine, but that's inbound NAT. Outbound port randomization/changing is outbound NAT. A port forward does nothing for outbound NAT, and outbound NAT does not control port forwarding.
If you want both in one rule, you use 1:1 NAT, otherwise you use manual outbound NAT and setup static port for the outbound SIP traffic in combination with a port forward.
It should not EVER matter what in the doggone SIP headers, I don't know why that was even being discussed.
Should not, yes, but it does in common setups. Some SIP trunks will send traffic to where the VIA headers say, not trusting the actual source IP/port of the packet. With those setups is where you need static port outbound NAT for your PBX for sure (or 1:1 NAT)
I talked to two people this week that had to have the same thing setup because if you watched a packet capture, the far side SIP trunk was sending the traffic back where it believed it should go, not where it actually came from.
-
Still didn't see a clear answer.
Is this the way the outbound nat rule should look like?WAN 10.0.10.0/24 * * 5060 WAN address * YES SIP - LAN to WAN
My voip server is on the 10.0.10.0 network.
Eric
-
no one ??
-
I must share the frustration expressed by others with this issue.
NAT rule to forward all UDP traffic from the VOIP provider to the Trixbox(Asterisk). Outbound calls from the Trixbox work fine. Inbound trunk calls all fail.
Wireshark monitoring shows SIP INVITEs coming into the WAN interface and NOTHING going out the LAN interface. The packets are being eaten by pfsense. No port rewrites. No nothing.
Tried the suggestions in this thread to no effect. If I had hair…
-
If it doesn't work, then something must have been misconfigured/overcomplicated/enabled without knowing it would conflict.
Go over every point in https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting and make sure you have it all correct.
Seeing the SIP invites hit WAN in a capture tells you very little - your NAT rule could still be wrong/not matching, or firewall rules, or some other part of the puzzle.
-
Thanks for the reply. Went through the list. Still puzzled.
The Trixbox continues to register correctly with the VOIP carrier through that port.
NAT and Firewall rules attached, but they don't seem terribly complicated. Similar rules work flawlessly for other services.
The incoming packets definitely have the correct IP source and destination, UDP and port 5060. There are some differences between the registration packets that traverse pfsense and the invitations that do not.
The envelope has [DF] set (but does not appear fragmented and I selected the strip [DF] on fragmented packets option). It also has tos=0x010 for what that's worth.
-
Is the traffic actually being sourced from an IP in the Junction alias?
If you check the state table, is a state created when a call tries to come in?
-
Yes, the source IP is in the Junction alias.
Good idea checking the states table. :) None is created. -
No state confirms that the rule is not being matched. If it were matched, you'd have a state.
Look in the firewall logs - if you see a block to the public IP - then the NAT didn't match
If you see a block to the private IP - the NAT matched but somehow the firewall rule did not. -
I just ran into this issue on the latest firmware. Some packets forward and some don't in sip. Identical ssh forward rule to the same host work perfectly.
