I had a good experience migrating a customer firewall from a Soekris x86 box to a SG-2440.  I didn't have any of the queuing or shaping features configured on that box.  The upgrade went well. The webConfigurator is "braindead" according to doktornotor.  If you have configured manually in your x86 configuration to pull firmware updates from the x86 URL, then that configuration will persist.  Just make sure you review it before 2.2.3 is released, otherwise you have the chance of taking your 64-bit box back to 32-bit pfSense.  It's a pain in the butt.  There's a redmine ticket to fix it. Just for completeness… https://forum.pfsense.org/index.php?topic=86915.msg477115#msg477115

So I've now setup pfSense on my VMware ESXi, I've added to LAN's to the VM, one is my default LAN vswitch, and the second is a dedicated "WAN" uplink vswitch which plugs directly into my mikrotik, both vswitches are set with promiscuous mode enabled, I've then bridged my LAN and WAN on the pfsense server and have assigned an IP to the bridge, I've created a floating firewall rule for now which allows all traffic. Everything works except the vlan traffic, the physical switch connecting the port to the ESXi vswitch is set to pass the vlans. When I remove the pfsense bridge my vlan's work as intended, the moment I re-introduce pfsense in the middle the vlans stop, all other default vlan traffic is fine and passing. Under the interface options on pfsense I have added the vlan's however it does not allow you to select the bridge interface, it only lets you choose either the lan or wan nics, so I've added the vlan's to both. Any ideas? Anyone have any similar issue or could perhaps offer some help? Thanks Just to add to this, "block private addresses" are unchecked for all interfaces.

Thanks Tim, That is a great subnet-calculator. I had looked at others. Like others coming up to speed on pfsense I was looking at the drape 2.1 book, but at the specifics for setting the IP address. It was pretty terse. Well, I was just looking in the wrong place I suppose. Your comment prompted me to search for mask in the same document and I found the section, Understanding CIDR Subnet Mask Notation, which of course makes it clear that CIDR is the default means of specifying a subnet … Thanks again. I wish I was still at the customer site to test it! pew

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!