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.

I think I figured it out… The problem was with Norton ... (don't ask... installed as a test a couple years ago, never uninstalled) It was seeing the ARP requests from pfsense when I would change access points and marking them as ARP poisoning. So then I think it would block all access to 192.168.1.1 which would obviously block my access to the internet... but not to other computers on my network... So, if you have a mac and norton, you have to turn off Vulnerability Protection, and really just uninstall norton all together.

It appear to be a firefox problem (the browser I use) it doesn't close the connections right. I downloaded from ie and the bandwidth graph drops after I cancel the download directly. So, does any one see this problem before ??

Probably Connections per Second. If you create an allow rule for a specific port and go to "Advanced Options" you can specify a connections per second limit. Just make sure that this allow rule is above your default allow rule.

The UDP is used for uTP transport protocol.  It can greatly increase your torrent speeds (mostly for public trackers without seedboxes like private trackers).  i.e.  each torrent uses the TCP port to initiate connections and communicate with the peers.  Data is transported over uTP which is connectionless and multiple streams can be made without being limited by the single port limitation. However, they can be a PITA when it comes to traffic shaping since there is no real way to hard set the UDP port range used. You can, however, set the bandwidth hard limits to apply to uTP as well (by default, uTP is not subjected to the same limits as the regular TCP connections).

It would have to be explicitly setup in DNS to respond to "wpad.<your domain="" name="">" (or some variations, check the wikipedia doc). It's not something that can be done accidentally.</your>

@subfire91: Basically what i want to do is to have any access to internet but service specific access to other LANs I had the same thought. I have yet to actually make my pfsense setup live (i'm pre-configuring so the transition is as quick as possible), but I had a similar issue coming from Sonicwall Logic to pfSense logic. ~~What i'm going to try, as I have multiple internal interfaces, is to do a 'default deny' where the rule is: Deny: Protocol - Any; Source: (interface); Source Port: Any; Destination: !WAN If my logic is right, that should deny any traffic not meant for the WAN, and then as said, add individual rules above that one for the specific stuff. As said I don't have the system implemented yet, but I may need to add an 'all access' rule below that one, so the processing goes: 1. Allow specifics 2. Deny non-WAN 3. Allow All Rule 3 is important as I believe pfSense simply does nothing without a rule present, and since the Deny rule precedes the Allow, only WAN traffic should be allowed via rule 3.~~ Bah, scratch all that. Gruens I think has it right, as I forgot the 'WAN' in the dropdowns is for the actual WAN IP, not as a 'zone' kind of deal like on Sonicwalls.

Update. I just realized that all webpages loads fine within the DMZ and WAN. The only place where the web pages dont load completely are on the LAN.  I am going to re examine all machines on the local network to see if there are any machines that might be causing  this problem However do you have any other suggestions ?

@TomBodet: Ok, I think I finally pulled my head out. The rule isn't allow DMZ server access to the WAN address, it's allow the server access to any interfaces that is NOT a LAN address. Right? WTF is "WAN address" for then? It is meant to allow access to the pfsense box itself from the WAN.  Lets say you want to access the pfsense box via SSH from the internet, then you will set an allow rule for: Source IP: Any Source Port: Any Dest. IP: WAN Address Dest. Port: 22 Without this, the firewall will drop the SSH connection inbound to the pfsense box from the WAN connection. Alternatively, if you need to block clients on the LAN from connecting to the pfsense box via SSH except say, a known IP (say: 192.168.1.250) for your administrative machine, then you will set a Block rule as such: Source IP: NOT 192.168.1.250 Source Port: Any Dest. IP: LAN Address Dest. Port: 22

There is some info in the doc wiki, but really what ports are "good" or what traffic is "bad" depends on the network and the type of traffic you're using. It's far too subjective to generalize with much accuracy. You can lookup what ports those are, but if those are part of a legitimate connection, it's probably just a variation of this: http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F

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

http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F