I don't exactly understand what you mean. But, with pfSense you can make VLANs and have different rules for each one. You can block the VLANs separately against other VLANs and of course against the WAN. What more security do you want?

A little more information was leaked to me from the previous admin (as I am new to here and he doesn't know the answer either). Here is the layout on our network. 1. We have a FTP server on our internal side and it also is FTPES.  That's why the ports are open.  Our outside clients (not on our network) can connect and send/receive data. 2. We also have a second IP address at a data centre.  I have no problems connecting to this as I disabled the userland FTP-Proxy application on the LAN side.  This is working great. When we try to connect to our internal FTP server, we have to use our external name of the server.  When we try to connect to our ftp server, it connects as indicated, but when the ftp server tries to send the certificate information back to the FTP client, it times out.  Normal FTP works but it takes a long time to connect.  The FTPES just doesn't work. I have turned on NAT reflection as we have other applications that we need to use using our external names (laptops need access both inside and outside of our office). All your patience and help has been great. Thanks

If you restrict your users outbound this will never work. Most current bittorrent client uses a random port in the 5 digit range. 6881:6999 was in fashion 2002

Please show screenshots of all your rules.

Thank you! Just added!

Fixed, it was a routing issue where unused interfaces for testing were confusing the firewall as to where it should send the ICMP packets. Interfaces disabled, problem solved. My bad.

Nanafriend, I believe what you are missing is a Virtual IP assigned to your WAN interface.  You then use that IP as the source for the port forwarding not "any"

Yes I have disabled the FTP Helper application on both the WAN and LAN interfaces.

Read http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

I can see the usefulness of something like this. Personally I would love the ability to block any chinese source IP's. Nothing against the Chinese, they just need to actually BUY their windows OS's and then they can update regularly. Until then, I and multitudes of others are left to be ssh scanned and whatever else from all of the hacked Chinese and Korean boxes. I would think if someone wanted this badly enough, making a package to do this would be the way to go. Alternatively a bounty could be offered for someone to make a package.

I don't know if this helps, but I was NEVER able to get more than 1 SIP device to ever register to a server outside my PFSENSE box, from a client behind PFSENSE box.  I had a Polycom phone and a SIPURA ATA, but could only ever get one or the other to work.  Logs never showed much of anything useful and I ended up finding another firewall solution for my house to solve the problem.

I think I solved my own problem. In order for my subnets, not directly connected to the pfsense box to go out on the internet. I had to turn off automatic outbound nat to access the internet, but this caused problems with local subnet routing. In order to solve this I just turned all my access point to bridges, and turn back on automatic outbound nat. Thanks for everyones help.

@GruensFroeschli: Ok you didnt write that you enabled static port (only that you enabled AoN) ;) In your portforward rule you have as source 65000. This will never happen because the source is always a random port. –> The rule will never be applied. Set the source to "any" and it should work. Thanks I did the modification but no result  ???  :'( (I did apply changes) But then i took the reboot option and restarted PFsense, and all ok !!! Strange I had this before with an other configuration Many thanks !!! I think we can say Topic closed !

This wont work from traffic off of the Internet because the MAC addresses aren't carried across. Only the IP is.

@jahonix: Maybe if you correct the destination in your WAN rule from  124.0.0.1  to  224.0.0.1  it triggers and blocks? Yea, i saw that misstake in the firewall rule and have corrected to 224.0.0.1, still same result.