@Derelict: So put a block rule for anything not that alias. Yes. But I was asking if there was any way to automatically create and maintain that alias, not about the rule I intend to use it in. If it's not, then oh well.  Was just a thought.

That's a bug in snort, not pfSense per se. I've done Nessus scans against pfSense that come up okay, so I wouldn't worry too much about this issue unless you have snort deployed.  Additionally, I recommend reviewing the snort change log and current version to see if this was addressed.

@charlesa920: @almabes: Ok…what if you wrote a PASS rule on your LAN interface for TCP traffic destined for any IP on ports 6881-6999 and set it to log.  Maybe that will help identify them. This sounds like a workable solution which is likely to find the majority of the clients I'm looking for.  Unfortunately I know no more about writing these rules than I so about snort.  But this sounds like something I can research and learn… Pfsense is versatile and powerful.  Even though I've used it for 5 years I feel like I only have a minimum knowledge and consider myself fortunate to be able to get it to do what I need.  Now that I need it to do more, I'll have to learn more. And that's a good thing. https://doc.pfsense.org/index.php/Firewall_Rule_Basics

Probably because someone worked around it in Linux kernel/some shitty Windows driver supplied with the MB to work around their junky BIOS/ACPI?

@arduino: You're connecting to the WAN address when using OpenVPN, right? Yeah right.

If I get the admin password figured out can be something be changed on the pfsense box to make it work?

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?