Yeah you can do this if you have a tunnel or transport subnet between the two locations are can NAT the traffic at both ends. It sounds like you are trying to have the 192.168.0.0/24 subnet on two interfaces on the same pfSense router here though. That cannot work.

@clevers Tried a web search? Virtualizing pfSense Software with VMware vSphere / ESXi

@steveits Thank You -- I have set it to 1.1.1.1. (CloudFlare) - and it appears to have made the red go 'bye-byez' [image: 1682523209539-c40bfc16-2797-4b99-bea6-5912060b408a-image.png]

What actual errors are you seeing? At either end?

@gertjan Thanks! I meant swapping it with the drive with the Untangle installation if I can’t configure the pfSense installation to my liking. As suggested by @stephenw10, this might be easier than reinstalling and restoring from backup while I’m still doing all these tests and optimization.

You almost certainly don't want to have VLAN1 tagged on any port. VLAN1 should usually exist inside the switch only so you should probably just have that untagged on 1 and 5-8 or only on 1 with every other port excluded. I don't expect an AP like that to be doing any routing so I would try to disable the WAN ports entirely and setup only a LAN. Though I don't have any direct experience with Omada gear like that. Steve

On top of that tip from @stephenw10 you should be able to set up also the following things; Create a user for each device and user that should be connect to the NAS According to that users set up user Privilegs to the files and folders on that NAS Set up on the PCs shortcuts to that NAS folders. If you are using LDAP and/or Radius don´t forget to sort all users/PCs with an certificate and/or set up the machines correctly in the LDAP role Either working with VLANs and/or plain routing you must set up firewall ruiles on the pfSense according to both subnets or on the Switch you are using the right matching ACLs.

The Akismet plugin for NodeBB has basically zero configuration options. The only thing you can set is the reputation level above which it no longer applies.

Check for IPv6. pfSense will provide IPv6 by default if it sees it available and many devices will try to use it by default. If something upstream changed you might have IPv6 when you didn't before.

Hmm, Limiters do not have a priority like that in order that External traffic will get bandwidth. It does have Weights but that simply divides traffic in ratio. It could help here but it won't solve it entirely. You do need to use dynamic queues as shown in that blog post to share the bandwidth though. You might be able to do it be using a 10M pipe for all traffic and an additional 10M pipe to Internal destinations. With both setup using dynamic queues to share bandwidth. That does mean you can never see the full 20M to an internal destination though even if there's only one client.

You can open a Redmine for that, will get addressed eventually. Seems like it will be quite a bit trickier to solve than it appears on the surface, though.

@gtenorio Are you using PPPoE? Since version 2.6, pfSense will be able to transport the entire WAN load over much more then one queue. So if the CPU is sorted with much cores and/or threats it can be a really good chance to get a fast as can WAN port / throughput. If you are running or using PPPoE you will be nailed to one CPU core and one queue! So if you now having much more to do for the CPU, it can be pointed to that circumstance told above (more queues = more throughput = more CPU load or tasks) 7 x 1Gbps down/100Mbps up fiber 1 x 50Mbps leased line fiber And with that much WAN ports, the entire amount of queues can be short and fast increasing once more again and also stress the CPU once more as I see it.

You were correct. Swapping over to the latest 2.7 did not improve anything. I have rolled back to 23.01 at this point.

You might be able to do it for force reinstalling the repo pkg from: https://pkg00-atx.netgate.com/pfSense_v2_4_3_amd64-pfSense_v2_4_3/All/pfSense-repo-2.4.3_4.txz Then selecting previous version. However even that looks like it's set to use 2.4.4. So maybe: https://pkg00-atx.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/pfSense-repo-2.4.2_3.txz Or create a custom repo conf file: FreeBSD: { enabled: no } pfSense-core: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_3_amd64-core", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes } pfSense: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_3_amd64-pfSense_v2_4_3", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes }

The 2 links in a lagg is a much nicer setup but the switches should support cross-chassis LACP really.

@stephenw10 Got it thank you