Boy, that sure was alot of work for a simple answer!  Well, better that than the alternative…  Thank you!

Read the FAQ? (or search the forum)

Since it is a bridge now, it is generating STP packets (Spanning Tree Protocol).  These are harmless.

Ola GruensFroeschli, OK. Cool. Thank You. -V-

in my dealings blocking an entire subnet you have to make sure that you rules are in the correct place in the rules list (top before allow rules). secondly if you restart your pfsense by no mean asume that clients will get updated automatically unless directly connected. ipconfig /release, /flushdns, /renew or your Os' equivalent. Also blocking the route to the subnet seems to prevent connects better.(IMHO) so that would look like *  Blocked_sites  *  LAN net  *  * *  Blocked_sites  *  WAN net  *  * Try blocking the remote DNS address if possible

Actually I was just reminded by someone else that ftpsesame should work in a bridged scenario, so you may also want to try to enable the FTP helper on LAN if it has been disabled.

Oh, if you have a bad drive that is causing your config to be corrupted, that will be detected and the last good backup will be restored. I could definitely see that scenario occurring with a dying drive, or a disk controller problem, or bad cable, or any number of hardware problems. My comments were assuming the hardware is solid.

The other option is to move ssh to a different port, such as 222, on all your boxes. It won't get scanned by nearly as many (if any) such attempts, and you can keep it open. Personally I block off all ssh from outside and connect via VPN before I can reach anything internal.

"Yellow Address" refers to the IP address of the Yellow NIC.  I was thinking that it meant something similar to "Yellow Subnet". For OPT I/F, you must create a rule to allow a machine on the yellow subnet to reach the yellow subnet NIC (with the DNS server).  This one seems crazy to me, but this is the way it is.  It seems crazy since if the DNS server were out on a switched segment, anyone could reach it with the same address. I am using an external DNS service, and desire to block any attempts by local machines to use other DNS servers. I made an alias AllPrivateIP with the Private and Auto IP addresses so that I could refer to their inverse as meaning the internet in various cases.  I seem to have private addresses pounding on me from my WAN trying to bootp. I have an XBOX360 on ORANGE which I have working at the "OPEN" level (highest) without uPNP Don't let any sloppy names that slip through confuse you with respect to LAN, ORANGE, YELLOW, XBOX360.  If it looks like something, it is. I plan on moving to a "block all except those allowed" for LAN, YELLOW, and ORANGE. Reject UDP LAN-Net * !Lan-Addr 53(DNS) *  Comment: Reject DNS to other than LAN Gateway Pass   Any LAN-Net * * * * Comment: Allow LAN to access anything Reject * * * * * * *  Comment: Reject at bottom so LAN never gets blocked causing delay Pass UDP !AllPrivateIP * XBOX360 88 *  Comment: Allow XBOX port forward Pass TCP/IP !AllPrivateIP * XBOX360 3074 *Comment: Allow XBOX port forward Block * * * * * * *  Comment: Block at bottom so no response. YELLOW Pass   UDP  YEL-NET * YEL-Addr 53(DNS) *Comment: Allow access to local DNS Reject UDP  YEL-NET * !YEL-Addr 53(DNS) *Comment: Reject access to other (external) DNS Pass   * YEL-NET * !AllPrivateIP * *Comment: Allow unlimited access to WAN Reject * * * * * *  Comment: Reject at bottom so no delay ORANGE Pass   UDP  ORA-NET * ORA-Addr 53(DNS) *Comment: Allow access to local DNS Reject UDP  ORA-NET * !ORA-Addr 53(DNS) *Comment: Reject access to other (external) DNS Pass   * ORA-NET * !AllPrivateIP * *Comment: Allow unlimited access to WAN Reject * * * * * *  Comment: Reject at bottom so no delay Firewall / NAT / Port Forward WAN UDP 88 XBOX360 88 WAN TCP/UDP 3074 XBOX360 3074 Firewall / NAT / Outbound Manual WAN LAN-NET * * * * * No WAN YEL-NET * * * * * No WAN ORA-NET * * * * * Yes

ok, thank you that is all i want to know, it is suppose to work like that. thank you

The firewall doesn't care what URL you're going to, and doesn't even know, it can't see the HTTPS traffic. Has to be something on your web server or reverse proxy that's different with the firewall in place.

Ah i see. Well you can still map the complete range with normal port forwards. But why would you need that?

By default, pfSense blocks everything on WAN. Nobody should be able to scan anything unless you specifically allow it.

I suppose you are asking if you create a rule for NAT, automatically an access rule is added. The answer is yes, if tick to do so is seleceted (default yes)

Inbound email uses 25/TCP and assumes your ISP doesn't block that port.  You can use the diagnostics at MX Toolbox to check to see if your email server can be reached from the Internet. Also, try removing the gateway setting from your rules and re-testing.

Using OpenDNS is the easy way. http://doc.pfsense.org/index.php/Blocking_websites

but easier isn't better ! :-) In my case i cannot have an external syslog server. The logs stay on the firewall 1 year, and a backup is send by mail daily. It's regarding French law when we offer Wifi hotspot. And I have write a windows software for create users for freeradius/ captive portal too. Work great ! Best regards, MaRCoOf

Aha… i think that may be the cause... Might be onto something jimp! I will change the 'suspected' auto update source to update via another means and see how this goes. Thanks for the great advice!