@gertjan yeah, it's a classic PC. i don't see anything on the monitor/console when booting up. @JKnott i'm thinking i'll pick up a smaller form factor unit like what you're running, or something similar. thanks all for the responses - it's helpful.

@stephenw10 Yes, I think that must have been where the corruption was - I removed it and it is all working properly now.

@gertjan Thank you .. I thought I need to open the WAN port with this rule.

Or any 'easy free fast' service with free pop-up notification, every-phone-on-earth support - limited (15Gbytes ..) storage etc. Just naming one : a gmail account just for your pfSense. Depending on what you use - how many updates come along in a year, and how often you reboot pfSense - and how often a power failure is signalled by NUT (and arpwatch, acme.sh certificate auto updates etc etc) : maybe 500 mails a year ... Placing all these in the local config.xml is probably not the best idea.

Bittorrent is a special case because it generally relies on incoming connections too if you are seeding and want good performance. That may not be possible via a commercial VPN provider. But routing all outbound traffic from a particular internal IP via the VPN is certainly possible. It should only require a policy routing rule to do so. Steve

Rule 1 there is for UDP/TCP only so it will not catch ping traffic. It also show 0 states created against it so, when that screenshot was taken, no traffic is matching it. What are you using for DNS on the LAN? By default pfSense hands clients the interface IP to use and listens on that with Unbound. If you policy route all traffic via a WAN gateway like that clients will not be able to connect to the DNS service, traffic is forced out of the WAN. You may need an additional rule above that to allow clients to reach the LAN address on the port 53. However that would also affect policy routing one client. And it would not be caused by just changing the default route. Steve

Hmm, that's an unusual error it if is. But you should be able to just reload the default config either from the webgui (if you can access it) or from the serial console menu. https://docs.netgate.com/pfsense/en/latest/solutions/sg-1100/connect-to-console.html However if that fails for some reason I would just reinstall the firmware to get back to a known state. Steve

@fenglingfu Here : Status >System Logs > System > General [image: 1637567351532-817c2ee3-1455-4d0e-9ff5-92ed5455fcf7-image.png]

@stephenw10 said in What would cause one computer to take a while to reconnect to WiFi after coming out of sleep when using pfSense + Unifi switch and AP but not with a UDM?: Is it actually the wifi connecting or is that 30s until you appear to have connectivity? 30s until wifi connectivity. pfSense cannot affect wifi linking. Got it. I will check the Unifi AP. It's strange I didn't have this issue when I was using the Unifi UDM with the same setup. I would be looking at IPv6. If pfSense is handing out v6 IPs but there isn't actually v6 connectivity there will be a delay until it falls back to v4. I have IPv6 disabled across the board. I will confirm.

Hmm, the returned killed 0 states implies it's not matching any states. Sure looks likeit should though.

@neo4070 said in Why not same speed on LAN vs OPT (SG-1100)?: How can pfsense so quickly "detect"/negotiate it to being 100 instead of 1000? I've tested it with my network cable tester and all wires in correct place. Something is wrong with this cable. And even if I get approx 100 MBits/s now - I still want to be able to understand what is wrong with it and if I can "trust" it... Pfsense doesn't do that, the NIC does. If that's a simple continuity tester, it may show it's correctly wired, but not other issues, such as crosstalk. Anyway, it's easy enough to try another cable.

@cabledude Edit : another possibility is that the ISP modem router was stuck somehow and rebooting it once brought it back altogether .

No it doesn't.

@colonnesel said in Need to allow access to specific corporate network IP from guest network: Rookie mistake Not sure I would say that - it does come up quite a bit around here to be honest.. Quite often users policy routing and wondering why they can not get to some other vlan, etc. I honestly have no idea why I would've thought that to be honest because it makes no sense. Huh - if you understand how the rules are evaluated, and how policy routing works then its quite clear that if you forced traffic out a gateway that can not get to where you want to go.. you wouldn't be able to get there.. To be honest I would be disappointed if I had a rule that said use this gateway, and this was first in my rules, and it didn't send traffic down that gateway even if there was another route.. If that is how it "should" work per what @stephenw10 has mentioned. That really should be CLEARLY stated that it will work that way.. Which in 10 some years using pfsense, do not recall it ever doing that with any sort of negate rules, etc. That is what can happen if the gateway your forcing traffic out is DOWN, and you have setting to not use that rule if gateway goes down, etc. But if the gateway is UP, and rule is before another rule - then it should force the traffic out the gateway. [image: 1637352599404-skiprules.jpg]

Sorry, OutBound Nat. Gets tedious typing it every time!

It would be nicer to detect that sort of case but it's highly unusual for anything to have serials like that, since to revoke a cert in the GUI the CA has to be internal to pfSense, and it's rare for anything but pfSense to have created certificates for such a CA. So it's something we could maybe add eventually, but it's not something I'd consider a priority.

@lewis said in Single device vlan: I still need to find a reason to use VLAN to learn about it but my setup is much nicer now thanks to the input in this post. If you put your wifi on a different network than your lan - your already doing vlans ;)

Locking completely with no crash report and unresponsive console starts to look like a hardware problem. Comparing old crash reports, and finding them all different, would confirm it if you could. Steve

Cool. Yeah looks like an issue in VBox then somehow.

Testing either to or from the firewall itself is not a good test as uses significant CPU cycles just to run iperf. To see the real throughput of your hardware you need to test between two hosts on separate internal interfaces. The LACP LAGG is unlikely to make a significant difference. Steve