Not sure what's not working (great subject huh?)
I've been running pfSense 1.2-RELEASE in our office for almost a year now. It's been great. Occasionally we have issues with iChat, but most times is resolved when restarting the Airport Extreme (which is configured in bridge mode, no routing or DHCP, etc). I always just assumed that Bonjour would fail and need a hard reboot to get the service responding again.
However, the other day I moved one of our VoIP phones onto this network and it couldn't grab the firmware update over TFTP, which is UDP. The TFTP server (remote) was seeing a connection being established on port 69 but not sending data. According to the TFTP Server maintainer, he could see if would attempt to send over a high randomly generated port number (I'm assuming it's like http where the server receives requests on 80 but then sends on high random ports like 56091) but would never actually do anything. And since TFTP is so, well, trivial, there wasn't anything more to glean from the logs. In pfSense, I went as far as to completely open up every port on UDP but it still never worked.
I took the phone home and plugged it into my barely-configured Fios router and it grabbed the TFTP files just fine. Now I'm wondering if my firewall's incoming UDP rules aren't correct or something, since iChat is done over UDP. I shouldn't need explicit rules for high port-value incoming traffic, otherwise normal internet browsing wouldn't work. If there is a problem with incoming ports for active connections (not sure of the proper term), it's only UDP because TCP works fine.
When setting up pfSense, I followed the basic rules. The WAN firewall rules only 443 and 2022. When I was trying to get this to work, I opened UDP 69 to every destination, and then all UDP for every destination. Am I missing something critical here?
FWIW: I've attached my NAT and Filters from /cf/conf/config.xml
Try enabling the static port option.
Thanks for the help! I read that several times and I don't quite understand all of it, but I think I get the principle of it.
I'm not sure it worked because after applying the rules I tried to get a file with tftp again and it timed out as well. Any other possibilities of what it could be? Or maybe I'm looking in the wrong place… are there some logs I can be looking at to see why it's failing?
I definitely had to use AON and static ports with a client's VoIP system.
The system would send out a UDP packet on (say) port 1234 and EXPECT the reply to come back on port 1235 - ie. (outbound_port + 1)
Because pfSense would re-write the outbound packet to (say) 5678, the other party would reply on port 5679 - and it wouldn't go anywhere.
By disabling outbound NAT for specific internal machines, the "send my a reply on the port I used, plus one" protocol (if you can call it that) remains intact.