Possibly. It's not something I would normally advise doing. The traffic shaping could be problematic. The filtering to keep each customer separate will be...interesting. But it might work I can only really suggest you try it if you can test it in something. I will say that trying to run that virtualized will almost certainly fail without a bunch of additional tweaks. I would test on real hardware if you can. Steve

It would be interesting to try a much longer timeout in the dhcp settings instead, The suggested 900s for example. However I don't expect that to work since the timing difference in the logs is only ~15s. A setting of 120s would have worked if it could. Steve

Thx! Got it to work by selecting "Pure NAT" on "NAT Reflection mode for port forwards" Although i'm not exactly sure what that means in terms of security. Will dive into that matter later on, so i know what i'm doing. ;-)

Yes, you will always see some interrupt load from the NICs when traffic is passing. That's where both the loading from simply forwarding packets appears and the loading from pf itself. NIC queue / core affinity should be automatic. It's not really a huge issue in a 3100 because the mvneta NIC/driver is single queue. Steve

@stephenw10 thank you very much, Stephen. You really helped me to understand a lot go things. Have a great day. See you in the next topic :)

The Netgate Azure image does not have SWAP at all. And in general if pfSense is using SWAP it's probably misconfigured. Performance is dramatically reduced. If it does have swap though it's a separate disk slice that's formatted as swap. You would see it listed in geom part list Steve

Yes, important to realise that in that example 'NORD' is an internal interface and clients on that have their traffic policy routed via the 'NORD' gateway group. It's that policy routing that determines where the traffic is sent and nothing to do with outbound NAT rules. Though OBN rules are still required. Steve

@barth said in pfSense support?: My guess there's something in pfBlockerng that's preventing access. Seems Netgate should have a little talk with them! No need to guess. When you using pfBlockerng-devel => go to Firewall > pfBlockerNG > Alerts and look at the Deny and DNSBL (below) part of that page. If you added IP and/or DNSBL feeds yourself to pfBlockerng=, you should be aware that these lists could contain IPs or host names that you actually want to visit. Their IP and/or host names will get listed as blocked. You can white list them, or you can decide to remove the list/feed that you have previously activated. Contacting the list owner might help, but this would be a very slow process.

@axxxxe said in SG-3100 rebooting: 've had that OVPN server configured to listen on 443 since at least January of 2018 and until recently there was no issue. If you've set up OpenVPN using UDP, it could co exist on port 443, as the nginx GUI web server uses TCP. This : Sharing a Port with OpenVPN and a Web Server tells me that it is possible to use TCP for both a web server and OpenVPN to use port 443/TCP.

If you had query forwarding enabled then Unbound (the resolver) would have been forwarding queries to whatever servers are set in System > General Setup. That could also include your ISPs DNS servers if you have it set to allow them to override the entered servers. The OpenVPN client can also add servers too. In a setup like that the important thing is that you have DNS queries be resolved at the same location as traffic is exiting. So using the VPN providers resolvers works well. It's debatable whether it makes any difference if the VPN providers servers support TLS or not since all traffic between you and them is over the VPN anyway. With Unbound in forwarding mode it sends queries to the defined servers using the system routing table which should mean over the VPN if it's set as the default gateway. However you might find the system opens states in the WAN if the VPN is down and if those states remain up pfSense may continue to try to use them. In resolving mode you need to either set the 'Outgoing Network Interfaces' to localhost (and rely on routing to use the correct interface) or set it to the OpenVPN interface directly. There is a diagnostic file you can retrieve via the unlinked page <your firewall>/status.php We use that in support and a lot of things are redacted. You still wouldn't want to post it publicly though. Steve

The Synology DS214+ has an ARM CPU. The DS214 and RS214 also do. The DS214play appears to have an Atom CPU, is that what you have? It doesn't specify which one exactly but since it's 1.6GHz it's probably a D510 which is at least 64bit. That's pretty weak though especially with 1GB RAM. pfSense will run in that but throughput won't be anything special. What's the available WAN speed there? Steve

Ah, OK do you see anything in the sysctls that looks like the same error count shown in the interface status?

I'd be looking for anything showing an interface or switch port link going up or down. Anything that shows a route changing or gateway status change. Or any sort of error message.

@firewalled_lotusdew It might be trivial now. Try it.

@stephenw10 yup use that if its not openvpn it sends it to the port that haproxy is listening on. port-share 127.0.0.1 9443

@stephenw10 said in Repetitive lines in /boot/loader.conf: I'm seeing that in 23.01 dev snaps. What version are you testing? It's ugly but harmless. There is a bug open for it: https://redmine.pfsense.org/issues/13280 Steve I am on the following version: 22.05-RELEASE (amd64) built on Wed Jun 22 18:56:13 UTC 2022 FreeBSD 12.3-STABLE Agree, it is indeed ugly. Thanks for the link to the bug report.

Hmm, yeah that should definitely work. You were restoring a 2.6 config into 22.05? Steve

That should work fine.

not sure how that got unblocked. thanks. I re-blocked it.

It is possible to use a wifi adapter as a WAN directly in pfSense but the support for hardware is very limited. It would be better to use an external wifi/ethernet adapter if you can. Steve