I have seen traffic last for a whole day before. Some Anti-P2P groups may even try to connect to your IP several times over the next month. The best thing you can do is to drop that traffic.

Also, this has been asked, and answered, many times before.  Please search the forum before posting.

If a connection is started from the LAN then the responses will automatically be allowed.

@Panix: Will pfSense do all the DNS records required for a AD domain to function?  I'm leaning towards no…. I have my network setup as client->pfsense->MS Server and I don't have any problems. It may relay the DNS requests for lookups properly, but perhaps not some of the other special things that AD seems to rely on happening via DNS for updates. (Someone more intimately familiar with AD would probably be more helpful for the details).

Yes.. that did the trick !! Thanx

http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

What are the netmasks for the 3 interfaces configured with 192.168.253.x. What are your firewall rules for the source interface in question?

The default deny rule already does that.

I just realized the firewall in subject is 1.2.3-RC1. I will upgrade that first. I tested the package on an vSphere server an hour ago - works exactly as it is designed to. This feature makes things so much easier for me :D Thank you for your work!

Update: I got this working with Wall Watcher running on my Windows 7 machine. Question, Wall Watcher support is set to expire in February 2011. I would like to build a Linux VM and use it for syslog server / dev box. My linux is weak and I'm using this as a project to learn the OS. I'd like some recommendations or a link to a HowTo on what is the easiest way to set this up. Wall Watcher has a great feature that summarizes the syslog data in a more easily readable output. I'd like to have the same capability in Linux. Is there a package out there that can do this? Or script recommendation?

For doing it only with the pfSense box, it is only possible if it is a wireless interface acting as an access point or if you only use one port on the box per client that connects to it.  The former can be done by disabling the "allow intra-BSS communication" option and the latter probably isn't practical to do on the pfSense box itself.

If the VPN connection is working properly, this can probably be safely ignored. It may be that the server side is sending a GRE packet before the GRE state is active, but if the connection works normally after that log entry, I wouldn't worry about it.

I would still try to figure out why grc.com reported your ports open, usually grc.com is the most trustworthy service for checking open ports on your firewall.

Thank you GruensFroeschli; now I understand ! Are there any other invisible rules? If there are any other invisible rules, is there a way to see them? Thanks.

quick means that the firewall will stop processing rules when it hits a match. If you don't use quick, it's last-match-wins instead of first-match-wins. All of the rules on normal interfaces (wan, lan, etc) have quick enabled internally by pfSense. Floating rules can be used to control how traffic is allowed to leave the firewall itself (though if it matches a rule on any other interface, it would be bypassed because it would already have an existing state). Pretty much "If you don't know what they do, you probably don't need them" :-) There is no reason you should need floating rules to do what you are talking about. A pass rule for ICMP on the normal interface rules should suffice. If you really want to allow it in on all interfaces, an Interface Group would be more appropriate, though a floating rule may get the job done.

I have no experiences with the pfSense squid configuration, but squid only can do URL and Domainname matching if i remember correctly and does no reverse lookups, so "gmail.com" and "mail.google.com" are different URL's and so you have to make 2 entries in your matchlist.

I was affraid for getting that answer, but ty anyway :P At least it stops me spending time in researching how to accomplish it ^^ Regards M

There doesn't have to be inbound NAT. As long as the firewall on the WAN allows traffic destined for the LAN-subnet it will work. NAT is just the reason why it works outbound. You don't need inbound NAT. You have to create on the ASA a static route pointing to the pfSense for the LAN subnet behind the pfSense.