The only way to stop two clients from talking is for the switch to block them. By default, clients do not communicate outside of their subnet, but there's nothing stopping them. I see DHCP supports static ARP, but I don't see a UI options for general ARP. You could run the command manually. You'd need to make sure your script gets ran every reboot.

okay … i'm convinced that BRIDGING the spokes inside of openvpn tunnel is not the way to do it ... How it should work is that a Spoke 1 LAN ( 192.168.3.1 ) wants to talk to Spoke 2 LAN ( 192.168.5.1 ) there should be an entry that say ... if you want to talk to 192.168.5.1 you have to go thru the HUB LAN ( 192.168.7.1 ) and there should be another entry that says if you want to reach the HUB LAN, you have to go thru this OVPN interface ( 192.168.101.1 ). If it can't work like that because of a limitation of networking or OSPF or whatever ... i rather not try at all ... I don't need a mesh in my network thats sooner than later going to break things. This is the main problem I think ... O>* 192.168.5.0/24 [110/20] via 192.168.101.3, ovpnc2, 00:27:16 O>* 192.168.7.0/24 [110/20] via 192.168.101.1, ovpnc2, 00:27:24 it should say via 192.168.101.1  not  192.168.101.3

Rebooted. Processor utilization back to normal. My Death Star phone company PPPoE DSL connection may have been a contributing factor.  I have disabled it for now.

@doktornotor: I think you can try to nuke /var/db/pkg and run pkg update - then you'll run into issues with files from packages that already exist but the pkg does not know about them, that is if you actually managed to install something before I just tried and it works well !! Thank you !!

thank you for your helps

No, it has not been fixed in 2.2.2. Either use a 2.2.3 snapshot or apply the patch manually. https://redmine.pfsense.org/projects/pfsense/repository/revisions/98615a3156d86aed1a560f109087d7e1ad4bf990

Glad to hear its working better, I've been liaising with Exetel to work through these fixes since late last week. I still see a heartbeat problem which means the connection drops more frequently than it should but at least it reconnects automatically. Would you mind checking your logs and seeing if you can identify how frequently your connection drops and reconnects?

Hello, I'm having this same error occur so when I look at the backup log one is firing off every hour which seems to much.  I believe it has something to do with pfBlockerNG updating every hour.  Is there a way to eliminate pfBlockerNG update from firing off the auto config updater? thanks, Jim

@KOM: But did you actually disable IPv6?  Read this: Block all IPv6 without logging and without bogonsv6 table One would think that when you chose to have IPV6 disabled that means don't freaking bother me with stuff like this. I wonder where the human element of these changes come from because I see no common sense to it. I am going to read that thread and then head to each and every box to turn this off… WHY?????????

That's SSDP/UPnP from your ZTE router. http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Just ignore it.

Indeed it was. I will definitely do that. Thanks for your feedback!

Go back to MicroCenter and buy a switch. Take back the wireless card and buy a separate AP. You'll have much better performance and coverage from the wifi.

@almabes: If you're not running the NanoBSD image put your pfSense box on a UPS.  The UFS filesystem doesn't like to deal with repeated failings of the local electrical utility.  That killed another customer pfSense firewall. After getting the bill for the firewall recovery, they had no problem with me installing a UPS. My PC, laptop, pfsense box and monitor are all hooked to a UPS.  I spent too much money on my main PC to trust the electrical of a 60 year old house.  :-)

I see….... I think i need to clean my glasses  :o