@KurianOfBorg: Why does 127.0.0.0/8 to WAN use the outbound port range 1024:65535 when LAN to WAN does not? IIRC that is the default for others it's just explicitly stated in the 127.0.0.1 rule. @KurianOfBorg: Why is a NAT rule for 127.0.0.0/8 even required? Won't the OS automatically use the WAN interface for all outbound traffic originating from itself? Not always, that's for services that explicitly bind to 127.0.0.1 rather than 'any'. It was one of a few things we added that helped squid+multi-WAN function in limited circumstances.

Thanks for the pro-tip. Enable NAT reflection on the WAN, or on the NAT/rule itself? I've tried the latter, with no effect, butI'll try it again. Unfortunately the crappy router does not support PPPoE - that would've been my own preference - let the "modem" only do the connection & have my pfSense to the routing & firewall work.

Sorry to answer that late! Thank you for your possible solution. As I had no time yet to get into the problem again (changed back to the old system), I'll do some research later (probably tomorrow as it's Friday). Regards, Bostjan

It's called "static port NAT". http://doc.pfsense.org/index.php/VoIP_Configuration http://doc.pfsense.org/index.php/Static_Port But, generally speaking, you shouldn't need it (at least I never had to enable it in the last couple of years). The port I'm seeing keeps changing on my hosted phones causing calls to behave strangely if the port for registration changes in the middle of a phone call. If port mapping changes in the middle of a phone call, it suggests that the NAT gateway may have expired that state. You should try tuning the qualifyfreq interval.

after having re re read the voip wiki I am no longer certain if voip nat outbond should be "static NO" or "static YES"… and which of those means "port rewritten".  'symmetric yes' is 'static yes', right? in that case would I replace the "Auto created rule for LAN to WAN" with three wan 192.168.40.0 src port: udp/my_sip dest: * dest port: udp/* nat addr: * nat port: * static: no wan 192.168.40.0 src port: udp/* dest: * dest port: udp/my_sip nat addr: * nat port: * static: no wan 192.168.40.0 src port: * dest: * dest port: * nat addr: * nat port: * static: YES

You could use 1:1 NAT or advanced outbound NAT to force traffic to use a single IP, ie the firewall IP.

Not entirely sure. Are you using UDP for teamspeak? I am not sure udp works on reflection. Etiher way though, if you use pfSense for DNS, you can setup a DNS entry for this server, for outside to resolve to, and then in pfSense setup an override DNS entry to point to the internal address. This way, external people resolve an external address and internal people resolve to an internal address and NAT reflection is not used. Also, this is better for bandwidth.

As long as there are no firewalls on the Raspberry Pi and it is using pfSense as its gateway, it should work. Could it be limiting port 80 traffic to local LAN?

Just had this issue. Found a post back in 2011 that said to try adding a "To" and "From" rule in the Captive Portal Menu under Allowed IP Adresses Tab. I did it, and now I can receive email. Why is it that my server's IP needs to be input here. Of course, in PFSense 2.03 you can't place a "To" and "From" rule, you have to select a "Both" rule. But this is very wierd to me. I did not select a captive portal interface during setup. When I do elect to install a captive portal interface, will I have to create different selections for the captive portal, and how will that affect my email server routing.

Check this: http://doc.pfsense.org/index.php/How_can_I_completely_disable_NAT%3F#Disable_NAT

Use a pfSense 2.1-RC snapshot. On phase 2, there is an extra box to specify the NAT subnet, and you can use your public IP or some other IP address there so they won't see your 10.x address. That does not/cannot work on any version before 2.1.

Seems the problem was of my own making and nothing to do with the pfSense firewall at all. The linux firewall on the host machine behind the pfSense router was the problem. The firewall entries that I had for mail and dns appeared to me to be identical in structure, but that was not the case.  The dns entry for port 53 was only permitting known associated Ip addresses, and blocking packets from the internet.  When I deleted the host firewall entry and recreated with source 'any' the responses to the dig query from outside were returned through the pfSense router. So I had jumped off in the wrong direction. All is good now. Graham

Hmn, small update: Seems to be working fine, however I can't seem to forward port 22.

#1 can be solved with NAT reflection or split DNS. #2 is outbound NAT or 1:1 - make sure the mail servers are set to use the same IPs outbound as they are inbound (or use 1:1 NAT instead of port forwards)

thanks it was reflection.

Left my test running over night. The issue has not reappeared so I am going to consider it resolved.