FreeSwitch and UPNP UDP forwarding
-
I've got FusionPBX/FreeSwitch running behind a 1.2.3-RELEASE pfsense box. Freeswitch uses UPNP to create port forwarding rules for TCP 5060, 5080 and whatever UDP RTP ports it needs. While things work well for outbound SIP calls, the inbound audio gets blocked on inbound calls. The RTP packets are arriving at the pfsense box and the forwarding rules appear to be in place, but the packets do not appear on the LAN network.
Here is some status during a call:
pfctl -a miniupnpd -s nat
rdr pass on ng0 inet proto udp from any to any port = 5080 label "FreeSWITCH" rtable 0 -> 192.168.1.2 port 5080
rdr pass on ng0 inet proto tcp from any to any port = 5080 label "FreeSWITCH" rtable 0 -> 192.168.1.2 port 5080
rdr pass on ng0 inet proto udp from any to any port = 5060 label "FreeSWITCH" rtable 0 -> 192.168.1.2 port 5060
rdr pass on ng0 inet proto tcp from any to any port = 5060 label "FreeSWITCH" rtable 0 -> 192.168.1.2 port 5060
rdr pass on ng0 inet proto tcp from any to any port = 5101 label "M y V i P 9 2 2 " rtable 0 -> 192.168.1.239 port 5101
rdr pass on ng0 inet proto udp from any to any port = 32038 label "FreeSWITCH" rtable 0 -> 192.168.1.2 port 32038
rdr pass on ng0 inet proto udp from any to any port = 32039 label "FreeSWITCH" rtable 0 -> 192.168.1.2 port 32039Here's a snippet of tcpdump on ng0 (PPPoE - WAN) - you can see the incoming audio arriving at port 32038:
15:37:51.568528 IP 63.224.89.73.22763 > 4.55.17.2.20180: UDP, length 172
15:37:51.568582 IP 4.55.17.2.20180 > 63.224.89.73.32038: UDP, length 172
15:37:51.588263 IP 63.224.89.73.22763 > 4.55.17.2.20180: UDP, length 172
15:37:51.588285 IP 4.55.17.2.20180 > 63.224.89.73.32038: UDP, length 172Here's a bit from the LAN side - only outgoing audio, the incoming got lost:
15:37:38.408607 IP 192.168.1.2.32038 > 4.55.17.2.20180: UDP, length 172
15:37:38.428596 IP 192.168.1.2.32038 > 4.55.17.2.20180: UDP, length 172
15:37:38.448587 IP 192.168.1.2.32038 > 4.55.17.2.20180: UDP, length 172
15:37:38.469575 IP 192.168.1.2.32038 > 4.55.17.2.20180: UDP, length 172Does anybody have any idea what might be happening.
mike
-
Some additional information:
I updated to the Feb 18 2.0 BETA and it did not fix the problem.The firewall rules aren't blocking anything (tcpdump -i pflog0 shows no packets).
If I check pfTop, I see states for both the incoming and outgoing RTP packets.
I verified the incoming RTP packets were not arriving on my internal FreeSwitch box.
Under 2.0 BETA, the UPnP rdr rules look slightly different:
pfctl -a miniupnpd -s nat
rdr pass quick on pppoe0 inet proto udp from any to any port = 5060 keep state label "NAT-PMP 31104980" rtable 0 -> 192.168.1.2 port 5060
rdr pass quick on pppoe0 inet proto tcp from any to any port = 5060 keep state label "NAT-PMP 31104980" rtable 0 -> 192.168.1.2 port 5060
rdr pass quick on pppoe0 inet proto udp from any to any port = 5080 keep state label "NAT-PMP 31104980" rtable 0 -> 192.168.1.2 port 5080
rdr pass quick on pppoe0 inet proto tcp from any to any port = 5080 keep state label "NAT-PMP 31104980" rtable 0 -> 192.168.1.2 port 5080
rdr pass quick on pppoe0 inet proto udp from any to any port = 28594 keep state label "NAT-PMP 31105331" rtable 0 -> 192.168.1.2 port 28594
rdr pass quick on pppoe0 inet proto udp from any to any port = 28595 keep state label "NAT-PMP 31105331" rtable 0 -> 192.168.1.2 port 28595Outgoing calls still work. However, a different PSTN gateway is used for outgoing calls: 216.115.69.132 for outgoing, 4.55.17.2 for incoming.
Could it be a timing issue? When an incoming call arrives, the RTP packets show up before the NAT rdr rules are fully in place, leading to some strange state where the packets get dropped once the rule is established?mike
-
Even more additional data:
When comparing the case of an outgoing call, which works, to an incoming call, which doesn't, I notice a couple differences:Outgoing:
The remote side starts sending RTP packets first. I don't see any ICMP port unreachable messages, so I assume the rdr rule is in place before the data arrives.The rdr rule forwards UDP port 32698 to 192.168.1.2:32698
On the LAN side, I see:
192.168.1.2:32698 -> 216.115.69.132:13992
192.168.1.2:32698 <- 216.115.69.132:13992And on the WAN side, I see:
63.224.89.73:32698 -> 216.115.69.132:13992
63.224.89.73:32698 <- 216.115.69.132:13992Note, the WAN-side source port for outgoing packets is 32698
In the incoming case, which doesn't work, my side starts sending RTP packets first. I don't have data on if this occurs before the rdr rule is in place or not.
The rdr rule forwards UDP port 28728 to 192.168.1.2:28728
On the LAN side, I see:
192.168.1.2:28728 -> 4.55.17.2:6348On the WAN side, I see:
63.224.89.73:1291 -> 4.55.17.2:6348
63.224.89.73:28728 <- 4.55.17.2:6348Note: the outgoing packets have had their source port remapped from 28728 to 1291.
I'm thinking that has to be related to the problem somehow. Perhaps the outgoing packets start before the rdr rule is in place and pf remaps the port and creates a state entry for based on the destination. Then the rdr rule gets created and the data from the far side gets sent to a different port which would work if the state entry with the remapped port didn't already exist. I have no idea if that is actually a valid scenario. Would something like that explain the problem and if so, how can it be fixed?
-
In case others search and find this thread, I did some up with a work-around. If I change the outbound NAT to use static-port for all traffic (http://doc.pfsense.org/index.php/Static_Port) things start working. I'm still not entirely clear why the outbound RTP packets need static-port since audio in that direction worked. It must have something to do with the state created based on the target ip:port (which becomes the source ip:port for incoming audio).
I would be nice if miniupnpd created a static-port outbound nat rule in tandem with the inbound rdr. That way static-port wouldn't need to be enabled globally. Since the RTP traffic can be on any UDP port in the 16384-32768 range, I can't create a special rule just for it.
mike