Bandwidthd will probably give you enough data: https://docs.netgate.com/pfsense/en/latest/monitoring/graphs/bandwidth-usage.html#bandwidthd Steve

It looks like you have assigned the switch as an interface. Did you also move the rule filtering to the bridge interface from the members? https://docs.netgate.com/pfsense/en/latest/bridges/firewall.html#bridging-and-firewalling Really it depends what you have enabled in pfBlocker though. You probably want to put the pfBlocker auto rules on the switch though. Steve

@steveits Oh! Good to know! I guess that's what I get for assuming, but now I understand why the button didn't seem to do anything.

Yeah, more info needed, mostly: what bandwidth is this expected to pass? Also, what is it connecting to? Steve

I expect line 412 to need to be moved also so that 'pipes_to_remove' is populated.

You're only using it to limit bandwidth per device in the LAN? You should just use the Limiters directly for that rather than via the CP. Steve

Yes, it's all back to normal now. The backend servers were upgraded to a different OS and their IPs were different so they would not conflict with the live servers. I thought I looked at the aliases so never thought about it again and figured something was up with the proxy until you commented which caused me to double check. All good now.

@stephenw10 I have noticed that a non loopback is loaded in the config and the ip is commented out for this. I attempted to turn on the ip and the port however it defaults back to commented out and deletes the lines I added in yellow. Orange highlighted is standard [image: 1670968472441-clamav.png]

I do not remember exactly which webpage I used to open a ticket and never received an email from Netgate at the time I thought I opened a ticket in November, though I was obviously in the wrong place. I was since able to complete the factory firmware reset on my Netgate 6100 and get back to a flashing blue diamond LED but still was unable to reconnect to the GUI or through the port console despite trying everything in the online manual. I opened a new ticket today at the link suggested above and got an immediate email response from Netgate with a 10-digit support number, and I can see the open ticket in my new account in Netgate's customer support portal. So we'll see how it goes from there. Thanks to all who helped above.

Yes, it looks like you do have LAN side static routes which require that gateway. So just make sure the WAN gateway is set as the default to prevent the LAN gateway becoming default which would produce the behaviour you're seeing. Steve

@tunnlrat Wireguard is the bomb. You'll get way better performance over it than you will OVPN. Performance will ultimately be based on the power of your router CPU but you will likely be able to push packets at a great rate per second.

@stephenw10 Just a quick followup that I figured out the issue to this problem. The problem had to do with a rule cleanup that took place prior to the upgrade. While while the rules that were cleaned up didn't pertain to the VPN traffic directly, it did reveal that the rules specific to this segment's traffic were impacted by two specific issues. 1. The direction of the traffic flow since a floating rule that altered the gateway used existed. and 2. Quick match was not enabled which means the rules pertaining to the traffic were not being applied immediately and were PROBABLY being addressed by a rule downstream. some additional tcpdumps that showed the return traffic hitting the firewall on the new VLAN segment for the VPN, but NOT hitting one of our SERVER VLANS where the request originated. This pinpointed the issue as being firewall related. I didn't want to just dismiss it as a bug without further troubleshooting, but was running out of ideas initially. At any rate, all has been fixed and is working again. Thanks so much again for chiming in!

Could have potentially been this: https://redmine.pfsense.org/issues/13381 Steve

Hmm. Well that implies it requires UPnP. You could test that by disabling UPnP though. And that means it can't work behind double NAT. However if it works by simply disabling the VPN you should be able to simply route the console traffic past it. It seems likely the VPN is changing the default route on the firewall. Or perhaps causing UPnP to show the VPN interface as the external IP. Steve

@akinori said in Allow traffic: going to let traffic coming from LAN interface going out to WAN and vice versa? By default pfSense will pass all traffic out and in on the LAN interface. WAN blocks all inbound traffic by default and will allow all outbound traffic without any special rules.

Issue with the flux capacitor?

I would definitely test enabling (or disabling) flow control at the link level on the NIC. Some connections absolutely require that.

@johnpoz, I've done nothing for you to act so childish in this question and have provided what ever information I can but you just keep on making assumptions and even saying my info is BS. There is nothing mysterious here, it's just something where I cannot share the customers technology. They are doing something that's proprietary and that's that. The only thing I can share is my mention of UDP and that's where it doesn't work with a host, it has to be bare metal. Again, thank you for your help.

Yes, that sounds very much like you're hitting that issue. Try setting the supersede option and see if it returns.

@stephenw10 Thanks for the reply!!