More RTP Issues
-
Hello. I have two VoIP servers running with a SIP trunk between them. One of the VoIP servers is behind a pfSense NAT, and the other is on the public Internet. I have a problem with RTP traffic not flowing through through the NAT from WAN->LAN.
RTP traffic going from the LAN->WAN works fine, and we have audio from the LAN VoIP server out to the WAN VoIP server. The problem is that RTP packets are arriving at the pfSense firewall WAN port but are not being forwarded to the LAN, and I can't figure out why!
Here is the forward rule:
@20 rdr on rl0 inet proto udp from any to 187.64.8.145 port 10000:20000 -> 192.168.2.2 port 10000:20000
And here is the firewall rule:
@67 pass in quick on rl0 reply-to (rl0 187.64.8.1) inet proto udp from any to 192.168.2.2 port 9999 >< 20001 no state label "USER_RULE: NAT RTP for VoIP"
I can put a tcpdump on the WAN port, and I see the packets arriving from the external VoIP server, but I put a tcpdump on the LAN port and they are never forwarded to the internal VoIP server.
However, I can use netcat from the VoIP server and generate a UDP packet within the port range above. That gets sent along just fine!
I have been pulling my brains out over this. I just cannot figure out why it's being blocked. It should forward on fine. I have tried with state and with no state. I guess there should be no state, but regardless it just isn't passing on RTP packets.
The only thing I can think of is the flood of UDP packets might be seen as some sort of DDOS attack. Although I'm not aware of any anti-DOS system in pfSense, and we haven't installed anything that would do this.
Any ideas?
-Chris
-
I had a similar issue, an asterisk server behind a pfsense which was connected directly to the internet, SIP clients from the internet had trouble with the audio, the call is established but there is no audio on both ends, I fixed this issue by setting Outbound NAT port to static.
Number 1 in this link:
http://doc.pfsense.org/index.php/VoIP_Configuration -
Tried all of this, still not working.
Calls originating from outside ring the extension just fine. The caller can hear me, but I cannot hear them. (one-way audio)
Calls originating from inside work fine both ways. (two-way audio)
When it's one-way audio, I have a packet sniffer and I see RTP packets going BOTH ways, but it's not being forwarded by the firewall.
-Chris
-
Rules and NAT look ok at a glance. Check the firewall logs for blocks, and the state table if nothing is there.
-
are you sure the addresses and port numbers in the sniffer trace are correct?
-
are you sure the addresses and port numbers in the sniffer trace are correct?
Yes, I am absolutely sure.
-Chris
-
@cmb:
Rules and NAT look ok at a glance. Check the firewall logs for blocks, and the state table if nothing is there.
I don't see anything in state table for incoming UDP when the call is originating from outside. I do when it's originated from inside. When it originates from inside, I have two-way audio; when it originates from outside, I have one-way audio.
Why is it not going into the state table? I have tried the rules with state enabled and disabled.
Really, it's just a very simple UDP port forward. For calls that originate outside (currently one-way audio), the RTP traffic isn't forwarded to the internal server. What's so weird is I can netcat a UDP packet on the same port, and it forwards just fine. This is something specific to RTP traffic.
When the RTP traffic comes in, there are MANY packets that stream in. I've had problems with other firewalls thinking this is a DDOS attack and blocking it. I don't know what is going on here though, it's VERY strange.
-Chris
-
silly question: you aren't running snort, are you?
-
No Snort, no.
-Chris
-
Using siproxd package? If not, this is baffling, as pfsense should not know or care wrt RTP versus any other datagrams on those UDP ports.
-
Using siproxd package? If not, this is baffling, as pfsense should not know or care wrt RTP versus any other datagrams on those UDP ports.
Nope, not using sipproxd.
Having this same problem with another VoIP service now. We have another SIP trunk, and it's not passing the SIP traffic even though we have rules that specifically allow it. Even when we allow ALL traffic, it arrives at the LAN interface of the pfSense box, but isn't passed.
-Chris
-
Anything in the logs? If you check the log this packet box for the rule allowing the rtp packets in, does anything show in the log?
-
I have a problem with RTP traffic not flowing through through the NAT from WAN->LAN.
RTP traffic going from the LAN->WAN works fine, and we have audio from the LAN VoIP server out to the WAN VoIP server. The problem is that RTP packets are arriving at the pfSense firewall WAN port but are not being forwarded to the LAN, and I can't figure out why!
I've had the exact same issue over here. The port forwards and rules that had been working on my old router (wrt54 + DD-WRT) showed the above behaviour on my new Alix board running pfsense 1.2.3 and I could not figure why despite looking at logs and states. Inbound calls broke down after 20s while outbound was fine.
My solution was to install the siproxd package. Even though I don't need it to get multiple phones registered using the same SIP-account, the package also solved my RTP NAT issues.
Actually I could delete all VOIP related NAT and Firewall Rules. Siproxd handles that directly - just configure that. No need for separate NAT / Rules. -
@ghm:
I've had the exact same issue over here. The port forwards and rules that had been working on my old router (wrt54 + DD-WRT) showed the above behaviour on my new Alix board running pfsense 1.2.3 and I could not figure why despite looking at logs and states. Inbound calls broke down after 20s while outbound was fine.
My solution was to install the siproxd package. Even though I don't need it to get multiple phones registered using the same SIP-account, the package also solved my RTP NAT issues.
Actually I could delete all VOIP related NAT and Firewall Rules. Siproxd handles that directly - just configure that. No need for separate NAT / Rules.I'll install siproxd this week and we'll see if that works.
-Chris
-
Have you got a Manual outbound NAT static rule for UDP 10000:20000?
-
-
When you did a TCPdump on the WAN, did the packets arrive on the same WAN IP as with your NAT rule? (Since it does look like you have more than 1 IP on the WAN).
-
When you did a TCPdump on the WAN, did the packets arrive on the same WAN IP as with your NAT rule? (Since it does look like you have more than 1 IP on the WAN).
Yes, they did.
-
Ok, then I reckon Sip proxy would be your best bet.
-
I'll install siproxd this week and we'll see if that works.
If you do, make sure that you configure siproxd in-line with this thread: http://forum.pfsense.org/index.php/topic,10084.0.html
Specifically, I had to enter all information stated by Sammy2000 here:
There is a little pitfall about configuring siproxd. You need to enter the following information, at least this is working for me…
Inbound interface
Outbound interface
Listening port
Enable RTP proxy
RTP port range (lower)
RTP port range (upper)
RTP stream timeoutIf you dont have any special needs, just go with the defaulst and you will be fine...
Actually that was all I needed - but I entered that information even if it was the default. The only thing different from the standard was my RTP range - due to a relayed AVM Fritzbox that handles the ISDN phones here and converts them to SIP. Used defaults for the others.
[Edit] Or so I thought. Certain Voip phones could not get through though (initially tested wit mobile and funny enough that always worked). Solved by adding firewall rules to allow what's needed (SIP and RTP range for my box) - and now I'm fine for all calls.
