Nice! I think I've used it one time previously. It's not a commonly known feature! 😉

Steve

@travelmore

Technically, but they do share a cable going from switch to pfSense. Other than that cable, it's a completely separate network.

I bet it's enabled on that laptop. 😃

Yes. That's what I thought you wanted to do from the start.
Won't need a new piHole though, you can just use the existing one but if you want another, go for it.

So that's why I said to make that network a /30.
A /30 gives you 4 addresses, the network address (in your case 192.168.20.0), 2 usable addresses (.1 and .2) and a broadcast address (.3).
If you go into the vlan20 interface, change the name, then change the IPv4 Address from a /24 to a /30.
Disable the dhcp server.
Then set the WAN on the lab pfSense to 192.168.20.2/30 as a static address.
That will give you a lab network with it's own router.
You can keep it at /24 until you're ready to connect the router, or keep it that way forever but there's no need since once the router is connected you'll never use more than 2 addresses.

Yes, you could certainly route between the firewalls. But you need to use a separate transport subnet between the two firewall interfaces and then add gateways and static routes between them.
That way you avoid asymmetric routing and can properly filter traffic at both ends.

If they have separate ISP uplinks you can also setup each as a failover for the other.

Steve

Then I would use a Limiter outbound on the IPSec interface at either end.

https://docs.netgate.com/pfsense/en/latest/trafficshaper/limiters.html

You could also apply that inbound on the source interface if that's known at both ends. Either way it's better to limit at the sending end than receiving.

Steve

Is this an L2TP problem? Open a thread General pfSense Questions if you're unsure. We can always move it. Give as much details about the problem as you can.

Steve

@stephenw10
now it worked thanks to everyone the rule was like this, blocking only the origin of the virtual network to which the guy will connect in the case 40.40.20.0/24

the other openvpn server of the company's employees accesses everything normally via VPN.

Thanks!Capturar.PNG

@jbohbot Hmm, yeah, the APC Windows Personal software has like two settings, and the Business software has 700 settings and a bunch of fancy charts to help you figure out the hole you've just dug for yourself. :) After 20 years I still have to look at it to explain it and I always seem to end up ignoring half of what they show to find out what it's actually going to do. I guess we make the best of it with this free package. :) The Business program also has power on delays for runtime and/or % battery charge.

The one I was looking at had Kill on Power Fail unchecked so I'll have to check that other places. What does "on powerfail" mean anyway? Right away, after shutdown, etc. Seems like it could have been explained in detail. Eh, I'll stop whining now.

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

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