@charliem: Your ISP should be out of the picture, right?  Your cable modem is the one issuing the address, if I understand correctly.  So, cm notices link to ISP is down, cm hands out a dhcp address for 192.168.100.x. I think that is correct– stupid cm trying to be a NAT router or something. @charliem: Or do you have two issues: one being a local address from the cm when the link goes down, and two being an incorrect IP coming from the ISP when the link comes up? I think only one issue– the DHCP being picked up and used by the pfsense when the interface is set to static-- possible sometime in the period of flapping around when the connection resets. Therefore-- exacerbated by the internet connection's current instability.

You have some other access except via VPN? If not, pretty much tough cookies.

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/