Possible bug, port forwarded ranges
I have encountered what seems to be a bug in pfsense. I'm running the current stable 2.1 build.
Ran into this problem while getting internal freepbx host to run.
I have pfsense configured as a border firewall. It does not have any other services enabled (no asterisk, vpn, etc. Just fw). It has a static WAN IP from Frontier. Everything else on this box is working ok. I have multiple services on internal hosts running via port forwards (single ports), and they run perfectly (email, web, etc). No issues with fw, logging, stability, packet loss, etc, etc. Aside from this port range issue, seems to be running perfectly on pfsense.
In a nutshell, I've observed that port forwarded ranges don't seem to work as expected. I spent a couple days testing this, and discovered what seems like a bug.
I configured pfsense to port forward UDP ports 10000-20000, to my internal asterisk box, on 10000-20000. Used the gui, it created the nat port forward and associated rule. But traffic never arrived at my asterisk box. I ran tcpdump on pfsense, on the wan side, and the lan side. The qualifying traffic very clearly came into the wan, and then sorta disappeared. It never comes out the lan side.
I configured logging on my port forward, and created my own "block" rule. Test revealed that the packets for the port forward were successful. Pfsense says they're ok to pass. But still nothing on the lan side.
Soooo… after testing everything I could think of (and learning quite a bit more about bsd and pfsense -- I'm from a linux/iptables world), I realized that my other working port forwards didn't use ranges. So I killed those range rules, and created a new one. I ran my asterisk test, and as soon as I captured the port from the wan side tcpdump, I quickly created a new port forward for that one port while the call was going. Amazingly it worked. The rdp udp traffic was port forwarded over that one single port.
Sooo... then I decided something was screwy w/ the range. So, I tried this -- I offset the ports. I configured the destination port range to be "off by one." Instead of 10000-20000, I used 9999-10102 (I changed the rtp to 10000-10100). But I left the redirect target port at 10000.
Ran my asterisk test again, and now, the traffic is being forwarded!!! yay... except, it's off by one port number... uggggggggggh.
So, if I set the range to 10000-20000, and set the redirect target port to 10000 (and it does seem to map 10000-20000 -> 10000-20000 in pfsense and in /tmp/rules.debug), it will not forward anything. Packets come in the wan, then get lost in pfsense and never leave the lan side.
If, however, I set the range to be 9999-20001, and leave the redirect target port to 10000, it does forward everything perfectly, except, now it's off by one port number (ex, source port is 10123, forwarded port is now 10124). So, asterisk still doesn't work, but at least I know where the port forward issue is.
I assume there is a bug in one of the /etc/inc/* files. But don't really know.
I suppose I could be doing something wrong here, but I have no idea what else would cause that condition. There are no other rules mapped to those port ranges, aside from LAN rules setup for basic internet access over 1024 - 65535. In other words, I don't see anything else intercepting that traffic and processing it differently.
It just occurred to me, that when I was first setting up pfsense, I did enable the sip proxy. I later uninstalled it, thinking I can work around it.
I wonder if that left something behind. I'm going to reinstall clean pfsense, then reload my config.
Maybe the siproxd uninstall left something behind…. seems I did enter the port range 10000-20000 into the proxy config at one point....
Reinstalled, still broken.
I noticed that in the xml backup file, all the configuration content for siproxd is still there. I manually deleted it, reloaded again, still no go.
Does anyone have udp port forwarding for ranges working?
I checked the actual kernel configuration with pfctl -a and it appears to have built the port forward nat/rules for my range.
Why in the world would it work for wonky offset port ranges but be broken for normal 1:1 ranges?
So, at this point my problem has completely disappeared, for unknown reasons.
All my udp ports are coming in, and everything is working great. I did enable "sloppy" for the state for rule regarding some vpn traffic, but the sip traffic isn't running over the ipsec tunnel, so not sure why that would matter here.
I did also reinstall once, but I did restore the previously saved config and immediately following the reinstall, was still seeing the problem.
Now, everything is working perfectly. fw, vpn, port forward, and have ntop running. I can finally decommission my old linux fw server.
Thanks to all for a very nice product.