Makes sense.. checking this morning the number of errors on WAN has not changed at all.  So fingers are still crossed. thanks for sticking with me on this weird issue.

If you keep all of your tunnel networks in a close range you can add a manual accept filter for the entire larger subnet which includes the smaller tunnel networks. For example if you have 192.168.22.0/30, 192.168.22.4/30, 192.168.22.8/30 and so on for tunnel networks, then you can setup an accept filter for 192.168.22.0/24 and I believe that should work OK.

Yep, what Phil said.  :) The default LAN rule will block that because the source is outside the LAN subnet so if you haven't changed it or added more rules that traffic won't be allowed. Steve

How have you installed it? Are you running the Live CD? Steve

Thank you very much! It worked. I just needed to unassigned interface before I start LAGG configuration. Thanks again.

@stephenw10: The default firewall rule on LAN only allows traffic from within the LAN subnet. So if your traffic has been routed from some other subnet (VLAN 10) then it will be rejected. Alter or add rules to allow this. Steve Ugh, how could I have missed something so obvious. Thanks so much for your time – this was my issue!

Usually after saving new config, there will be Apply Changes button, if you did apply, it should work.

Great software! Thank you very much Steve

^ Exactly. The re-seller arrangement is currently being revised I believe so there's not much info on the website. Just contact ESF directly, I'm sure they can sort you out. Steve

Isolated the problem yesterday to a machine on my network with an IP address and matching MAC address that was the "spoofer" … Even though I know there is a machine on my network, I do not know where the machine is. Will be onsite going from machine to machine looking for the spoofing system. From what I have read over the last few days, there is really no way for pfsense to stop this type of attack. Many say that it must be done through a managed switch or to statically assign the network parameters on each workstation in the building. It would be nice if there was a way that pfsense could stop this from happening. Anyone ever run across this and what solution did you use? Thank you Kell

Of course! Heh… I have way too many images of pfSense floating around on my computer, and I'm too used to installing it onto embedded machines with very little memory. smacks self on head

How about this feature for squid? Would this work? https://code.google.com/p/squid-ecap-gzip/

HTTP blocking with different blocking groups is relatively simple to set up. HTTPS is a bit more difficult… I struggled with getting HTTPS filtering set up at our school for a couple of months toward the beginning of this school year. The way I ended up setting it up is by using the "SSL man in the middle Filtering" in the Squid3-Dev package. Unfortunately, this throws certificate errors unless you install a CA cert from pfSense. It's a pain to set up (need to install the CA cert on each individual computer), but once it's in place it works. As far as I know (unless you go the route of DNS-based filtering such as OpenDNS) there is no way to do completely transparent HTTPS filtering without needing to install a certificate on each computer. As for having different blocking groups, you can most certainly do this with Squid. (I use Squidguard here for blocking, by the way, so I'm not familiar with the blocking package used in the tutorial you linked). Under the "Groups ACL" tab you can create a new group, and set up which IP addresses it is applied to (you can do individual IPs, or whole subnets... I just do 192.168.4.0/24 to apply it to the whole .4 subnet). Hopefully that helped some... At what point are you in the setup? Have you gotten the proxy working yet for at least HTTP?

ARP reports all known MAC addresses on a given interface. Bridging is essentially like a switch, so the original MAC address of the device on a separate segment is still used. To me, this is a valid report.

Apparently I had a space at the beginning of the URL string, this was causing the error and is now working.

Thanks for the feedback. Torrenting from any machine tanks the server, I think I already mentioned that. I'll try using a different virtualization solution to see if anything changes. Thank you.