thanks for the info, i'll give it a shot.

The problem is not in the firewall, either one of them. It's that your web server doesn't know how to properly send the traffic back where it came from. It may not have any way to distinguish that. I'm not sure Windows has any method to pull that off properly.

@cmb: Though I agree with CryHavok, I don't think that's going to accomplish anything, the chances of that slowing down a bot infested PC to the point that a user would notice are pretty slim. THX a lot. At least it will be a new quest for my "friends"… If i cant stop them i need to feed them with some new surprises. :) Btw: Is there a working IDMS module for pfSense?

For a port forward, you want the source to be "any" (unless you want to restrict who can connect to the port) and the destination is the internal IP (192.168.1.219 in your case). The WAN IP doesn't belong anywhere in the firewall rule for a port forward.

To kill active connections you have to go to the States table and use the "X" button to remove all states involving that IP address.  Your firewall rules will only block future connections, not active ones.

No! Don't send him over there! I don't want to have to decipher his forum posts. :)

Under Interfaces > Wireless (whichever it is named opt1 normally), make sure that the "block private networks" isn't checked. But if I understand what you're saying, when you remove the allow rules for port 80/443 on the wifi interface, then they are able to access the LAN? What if you modify the rule on the wifi interface from Destination: Lan Net, to the actual IP range like 192.168.200.1/24? I understand by choosing Lan NET, this should do this, but it can't hurt to try? @jhboricua: Hi CMB, Here's what the typical deny entry looks like from yesterday. Act Time If Source Destination Proto X Feb 10 13:45:09 Wireless 192.168.201.122:3645 192.168.200.10:53 UDP Because of the above, users were unable to browse the internet or internal resources that depended on DNS resolution. I had to take out the rules on the wireless interface last night because I couldn't keep this issue affecting the wireless users at my client's site any longer. They were replace by the standard allow all rule until I can hash out what is the issue.  I still need to lock down the internet traffic originating from the wireless users to only http and https while allowing any traffic to the internal LAN, just like the rules on my opening post. I'm not sure if the rules are wrong because to me they look ok.

What do you mean you've bridged your opt1 with your lan? Wouldn't you wan't to keep them separate? Otherwise you could just plug the netgear into the switch that's connected to your lan interface, save yourself the trouble of dealing with the firewall rules. I'm not sure they'd even be effective if the two devices are bridged. Anywho, you'll still need to open the said ports on your WAN interface, and create a NAT for the ports to forward to the VOIP adapter. I believe there is a package available for VOIP protocols as well. (TFTP) I wouldn't understand opening the ports up to the other network unless your calls are internal to other phones on the network? (I'm assuming you mean your external calls are delayed.) Summary: Open ports on WAN | NAT: Port Forward to VOIP adapater IP. No additional rules needed (still assuming it's external calls with the delay) If you haven't already, make the VOIP Adapter LAN IP static via your DHCP in case of a power loss.

If you want to block both in and out you need one rule on the wan specifying the source as the alias and also a block rule on the Lan tab with the destination set to the alias. there are plenty of online CIDR calculators to work out the correct notation for your network range.

It appears that this issue is already being discussed. http://forum.pfsense.org/index.php/topic,31324.0.html

As an update after some more searching it seems like a similar, if not the same, issue was raised in February 2009 with the following discussion but does not seem resolved? http://forum.pfsense.org/index.php?topic=14382.0 I will keep on searching…

@beaven67: I knew the 1k=1 state baseline but Has anyone got pfsense running around 500,000 session in a production environment? Yes, many. I've personally gotten a 2.0 amd64 install up to around 15-16 million states.

It does matter its sorted.

We use it extensively. That's a generic Windows error, unlikely to be related to your firewall.

Dump your rules and start over.  Assuming your FTP server's IP is 172.16.10.100, change the default port to something non standard like 7431, create the following NAT Port Forward: Interface - WAN External address - any Protocol - TCP External Port Range (from) - 7431 External Port Range (to) - leave blank NAT IP - 172.16.10.100 Local Port - 7431 Description - FTP Server Check the box for "Auto-add a firewall rule to permit traffic through this NAT rule" You now need to enable PASV mode on your FTP server, enter the External (Public) IP for your network and configure a PASV port range… e.g. 30000-30200 (need at least 1 port for every connected FTP user). Create another NAT port forward for that PASV port range to your FTP server: Interface - WAN External address - any Protocol - TCP External Port Range (from) - 30000 External Port Range (to) - 30200 NAT IP - 172.16.10.100 Local Port - 30000 Description - FTP Passive Ports Check the box for "Auto-add a firewall rule to permit traffic through this NAT rule" Save, Apply, Done.

Not without manually hacking the filter.inc file to do what you want.