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.

@gderf: Network Address Translation. http://en.wikipedia.org/wiki/NAT My mistake Gderf, for an hour or so I thought it was different. thanks for the help.

You have to flag "Disable webConfigurator redirect rule"

@phil.davis: For your web and mail servers, did you set the default gateway xx.xx.xx.25 (the cable modem)?  I am fairly sure the pfSense box is supposed to be invisible to the servers. IMHO the servers in the DMZ have to have the pfSense DMZ IP as their gateway. That is the only way out for them from their subnet to the rest of the world. In this kind of situation, the pfSense is being a "normal" internet router. The internet (ISP) is routing packets for the allocated DMZ public IP subnet to the pfSense, and expecting it to route them to the destination. The pfSense role here is to route the packets, and to front-end filter incoming stuff, so the servers in the DMZ only get necessary open ports accessed/attacked. There is no point letting everything through to the DMZ servers - they would appreciate a bit of protection from random scans/attacks on other ports. ok - but from this point of view (which is also my own one) an fully 1:1 bridging is not apreciated. The role pfSense does NOT have to perform is NAT/port-forwarding, as the DMZ already has real public IP addresses. yes, but exactly this is my problem – 1:1 bridging which i have tested as a hopefully working approach does not work and i do not know what to do to tell the WAN interface to accept public DMZ IP's

ok, i have now atleast this working… I had squid transparent proxy package running and adding deploy.akamaitechnologies.com to the bypass filter allows the client to function properly. I had noticed in the States logs something similar to: 127.0.0.1:3128 <- 96.17.202.194:80 <- 10.0.1.250:54094 which i recalled the loopback/port thing that squid does when I read about it. would be great to be able to cache these downloads, but for now I guess this will do... i'll head over to the squid package area and educate myself a bit more, perhaps a custom option will solve this for good.

Are you sure the firewall rule disabled itself automatically? When I disable a NAT rule, the associated rule does not disable itself on 2.0.3 or 2.1.

FIXED: solution posted for anyone else looking to fix this problem. I had to go into System -> Advanced -> Firewall/NAT and deselect the checkbox called 'Disable NAT reflection'.  I believe that is what gderf meant. Information came from: http://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

@Syntax42: My understanding of 1:1 NAT is that it is similar to putting a device or subnet in the DMZ.  It becomes completely exposed to incoming traffic on the IP address given to it.  I think what you are experiencing is the correct behavior for 1:1 NAT.  If you want the traffic to pass through the proxy, I think you need to set up port forwarding instead of 1:1 NAT. If the device on the 1:1 NAT requires a different external IP address than the WAN address of your firewall, I would not have an idea of how to do that and still have the traffic for it go through the proxy. http://doc.pfsense.org/index.php/1:1_NAT Thanks. I discover that it is not related to NAT1:1 but to squid module….

Reading all of those articles didn't help me much.  This article led me to believe the source port was being changed and that I needed it to stop changing.  I had trouble understanding all of the applicable configuration options after reading this.  This page and the page it links to are lacking. I think I figured it out, though.  I changed my NAT to manual and the settings on the configuration page are below.  I didn't need static NAT for port 5060. WAN  10.xxx.xxx.xxx/xx * * * WAN address * NO I think what really fixed it was changing the state table behavior to conservative in the advanced system options.

Try this: http://forum.pfsense.org/index.php/topic,63046.msg340663.html

Port 25 is still the server to server port. Its the ISP (client side) that blocks port 25. Idea 1- Make destination ip any. Idea 2- Try redirecting from port 587 (client) to port 26 (their server) if they really have it open.  You need to find out what its open to. The idea of an email server allowing connection to port 25 for anything else other than email coming from another server for delivery to its clients makes it sound like an open relay. Wouldn't it be the client device/software behind your server that is doing the authentication to the server? If Im not missing something try port 587 out the door or even IMAP (146). Unless your trying to get some program on the server (IDRAC6) to email out??…

I seem to get it to work - basically NAT Outbound I change to manual then edit rule (for DMZ subnet) I select static port. I'm able to see the person on the other end now. Ethan