@dotdash: I remember having to check some box to bypass the firewall for the true statics. This was on the Comcast modem. I forget the exact details. This was it. There is a box that says something like "Disable NAT for True Static IPs". Once that was checked, the rules took effect as required. As Jim mentioned, it is probably a good idea to have an alternate port used and maybe we will standardize on one later but either way this option needs to be enabled on the Comcast modem for this to work. Thanks everyone!

ok, thanks a lot!

thanks everyone for your help.  turning the filter back on so it puts the firewall back into firewall mode and setting the outbound NAT rules, where a rule has the checkbox that says not to do NAT on the outbound packets fixed it. i was still having issues, but upon further inspection of linuix log files i found the clients ip address is being passed through the route based firewall and pam is closing all of the sessions.  so now this may have been the easy part, pam in linuis does not look so easy. no addtional route was needed.  duh - the firewall is the router between interfaces. thanks again!

Thx GruensFroeschli, We made several tests and it works correctly. On your point 1.2, you were right, it was an error in rules, we had a badly placed rule which opened inter-vlans connections. Thank you for your answers. Yro.

OK so that was user error I mean my ….  :-\ I have been trying to experiment with static routes and after I added 192.168.5.1 to 192.168.1.1 and 192.168.5.1 to 192.168.5.119 my whole network went down and DHCP on WiFi router has been changed from 192.168.1.100-192.168.1.120 to 192.168.2.100-192.168.2.120 I am trying to figure it out why that happend. Thank You for Your help. Every message make me closer to what I messed up. MST

@pdxer: If your seeing 'Blocked Log Spam'(high frequency of blocked addresses or ports) an easy way I found to keep it from filling the logs is to write a rule on the destination port in WAN. And since LAN is Default 'All Pass' I will put 'Reject' rules on Ports I know I wont use on the LAN interface, one rule for the source and one for destination. At the bottom of the rule:edit page is a tab for writing logs on that rule, make sure logging for that rule is disabled. This will keep you from getting frequent block logs on your 'System Logs'. To keep your rule page from becoming very long, make an alias for ports(Labeled:BlockPorts) and one for addresses(BlockAddress) that you are wanting to block. So later on when you want to add another port or address, all you have to do is edit the alias attached to the specific block rule. What it looks like is DHT traffic. I'd really rather not ignore it, but somehow get it to actually reach my BitTorrent client.

What kind of devices do you have in front of the different WANs? If they are pfSenses you can enable source NAT and it should work.

I have the same problem here and found the reason in the code /etc/inc/filter.inc line 907 shows $natrules .= "rdr on $tmp_interface proto tcp from any to any port 21 -> 127.0.0.1 port {$tmp_port}\n"; So all traffic to port 21 is redirected to the FTP helper. No chance to configure FTP for different networks. Not that amazing for a firewall. :( Any expert with a workaround here?

Did you create the according firewall rule?

Click the + on the right side.

Find a list of all IPs of antivir-servers. Create an alias, containing all these IPs. Allow this alias.

Hello focalguy, Thanks for the info. I was hoping to get an idea what amount of compensation the developer had in mind to implement something like this, but I guess this is more like post an amount and see if someone bites. I'm now getting a quote from a commercial firewall manufacturer to implement this solution, which is actually what I prefer in terms of what is expected on the pricing front, as opposed to trying to guess what to post in a bounty that may or may not be picked up. If there is an alternate way to get this implemented with PFSense I'm interested. Thanks.

@Perry: Gateway: * (default) fixed my issue, THANKS!!! i will post screenshots when i have everything working properly in case anyone is interested

Rules are applied inbound on an interface. So a rule with as source "Wan Net" on the DMZ interface will do absolutely nothing. Also Destination: "Wan Net" means exactly that: The destination has to be in the subnet of the WAN. –> This is not the internet. pfSense per default blocks everything. So instead of blocking everything before the allow rule, you can do it reverse. Also you can make everything a lot easier with aliases: http://forum.pfsense.org/index.php/topic,14989.0.html

Ok Thank you very much

Create a rule on your LAN interface set to block with a source IP address of the computer you want to deny access to. Make sure you move this rule above the default allow rule or the traffic will be passed before the block rule is processed.