@avalox: our pfsense only filters incoming traffic. For testing i disabled / enabled the "userland FTP-Proxy application" on all Interfaces in several Interface combinatios but nothing worked. For active FTP, the server make a return connection, back to the client.  pfSense is possibly blocking that reply, which will be coming in on a port higher than 1024.  Although that doesn't seem to happen on my system, and I will say, I'm not at all sure why.  Do the firewall logs show anything being blocked. My setup has the WAN Proxy enabled, and the LAN disabled.  This sticky does mention about problems with changing the rules a lot of times.  Maybe try a "clean start". @avalox: woukd like to add a tcpdump, but dont get it run?! tcpdump -vv -i em1 for example show nothing, but there is traffic. Am i doing something wrong? Is this a nano setup.  If so, then look here. Cheers.

Yep Eugene at last got it to work.. thnx for all the help. After adding DNS servers in the rule, it all started to work. Thanks, Venkat

Yes, we did and we have IMSpector installed as a backup solution now. But since the people who are going to menage the system are not too much the tech-inclined types, MSN-Proxy would give them a more user-friendly experience. That's why we're looking into it instead of using IMSpector. As for the problem, all logic applied looks correct. We'll keep on testing. Thanks for your reply.

You can setup port forwards just the same with public on both sides, I've done that a few times where someone wanted to send port 26 to port 25 on a public IP inside the network. The external and internal IPs are the same, just set the ports appropriately. That won't impact anything other than the specified external port.

Thanks all, I found it might be a MTU problem while I tuning the MTU down on mail server….

Enable disable nat reflection and check windows firewall and antivirus firewall.

You know what? Thanks for making me do the TCPDUMP. Seriously. Because now I looked at its output, and I can see the problem:  The Userland FTP helper is working fine - but the connection on the client isn't being accepted.  Its the local client firewall blocking the active FTP incoming connection. I HATE ACTIVE FTP. But at least this problem is sorted. Thanks again!

Sounds like these: http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F As Briantist proposed, those are very likely to be unrelated to the port forward not working. If it was, they'd be TCP:S, and no others. The OP may need to try to track down what is going on as described here: http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting Or it's also covered in the book.

So you're saying that you can successfully browse the web, etc, from 192.168.1.3 now? If so, then it sounds like all you need to do now is set up your firewall rules. On the interface where your public IPs lie (WAN?) you need to set up rules to allow the incoming traffic. The destination will be the LAN address and port(s). To see an example, add a regular port forward and let it generate the firewall rules automatically, then look at the rule it generates and use it as a guide.

My problem is similar, I need to do DNAT on port 80 to a squid proxy (thereby making it transparent to the end users). But only for a specific IP. Both the squid server and the 'end users' are on the LAN subnet. Is this possible? In Linux iptables you would just to DNAT…..

hi xxsinxx, If you set the WAN interface on pfsense to one of your extra external IP's, say x.x.133.60/24 (because .59 is your vmware management IP) and you have the gateway set to x.x.133.254, then from within pfsense can you ping the gateway address? (diagnostics > ping > interface WAN > x.x.133.254) if you can ping then run a traceroute from the WAN interface to say Google DNS 8.8.8.8, if the hops don't get past your gateway you may have the wrong address as a gateway (or it's not properly routing your subnet/ip) if both of those respond properly then the problem is likely with the NAT/rules Hope this helps!

Didn't say you had to post it, just look and see if there is anything there at all that might shed light.

Setting the MTU on my WAN interface to 1496 fixed the problem. http://forum.pfsense.org/index.php/topic,13014.0.html

Is there a reason you won't just let the admin network access the access points directly?  I assume ADMIN is OPT1?  If so, it won't have any access to anywhere unless you add rules.  So, something like this: Firewall => NAT => Outbound: Enable Advanced Outbound NAT.  Add a rule that has a source subnet of the ADMIN subnet, and check the "No NAT" box.  In the rules section, add a rule applying to the ADMIN interface that only allows access to port 80 on the set of AP IP addresses (you can define those in an alias list elsewhere.)

Thanks for your help GruensFroeschli, I've fixed it. The problem was a firewall. Disabled it and it's all working now so now all I need to do is configure rules. I thought wireshark captured before the firewall but it seems not.

Will do, thanks :)