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.

Okey… don't get it. I disabled "Block private networks" and it solved the problem. Now I re-enabled it and it still works. Any ideas ? Best,

It was not pfSense, it was defective media converter and/or SFP connector. After replace FTP works as usual.

Your capture isn't really a good test since they were not done on both interfaces simultaneously, and telnet will use a dynamic source port. Check the state table - Diagnostics > States . Filter on your IP. Check the entries that look like: LAN.IP:YYYY -> WAN.IP:YYYY -> Server:ZZZZ As long as the port on the LAN and WAN IPs match, static port is working correctly.

IGMP and Avahi forward multicast, not broadcast. You don't want to forward broadcast between subnets. A UDP proxy potentially could if you want to do a lot of hacking yourself. It's likely the UPS software supports defining UPS by IP and not relying on broadcast for discovery. Any business-grade software will give you an alternative since multi-subnet networks are the norm and forwarding broadcast on such networks is nearly unheard of.