The Realtek driver and loader values should survive across a minor upgrade like that. The fact the Intel NICs are lost certainly isn't expected. It sounds like something low level if a power cycle brings them back. When they are lost do you see any errors in the boot log when the driver tries to attach? If they are not detected at all that seems like a PCIe error somewhere. Steve

Hmm, that setting it to WAN would have reset the default route. It may have lost it's default route somehow. But that would have broken the connection for everything.

@gertjan said in Starlink and pfSense: Such a scheme would need a specially build DHCP client on the (Starlink) router, and its behavior should be simulated on pfSense. I agree. If we knew what it actually requires we should be able to do it. See: https://forum.netgate.com/topic/176450/starlink-no-internet-when-reject-leases-from-configured

I will have to reinstall everything, plus I have a second problem of overheating but after moving the box in my "lab" ... grrrrrrrrr

@danioj Bigger takeaway: Netgate Device ID is based on your NICs and their MACs. Add VLANs over interfaces to your VM guests -- you'll be happier long-term.

@johnpoz oh, thats a FANTASTIC idea, i hadnt thought of using haproxy to do this!

You should see old leases in /var/dhcpd/var/db/dhcpd.leases if they still exist anywhere. Though if clients are getting a new lease they may not. You can choose to backup the leases in Diag > Backup > Backup extra data. Steve

@jimp Thanks :-) Ideas looks great :) BTW I do want to user + certificate but in that case when I changed password I was still able to login with just certificate(case 2 above).

Mmm, more info needed! I'd guess it's a subnet conflict though. If the upstream device is a modem it might be handing out a private lease before it syncs. Steve

@stephenw10 Thank you very much. Upgrading to version 2.6 fixed the problem. It's working flawlessly now. Thank you again.

https://redmine.pfsense.org/issues/14356 Redmine is open for this issue. I recently learned that it is a bigger issue over just this small part I found.

Be aware that the igc driver only supports autonegotiation. Setting it to 1G simply omits the other link speeds as choices in the negotiation. If something is not enabled for negotiation it will fallback to a default speed or fail to link entirely.

@johnpoz and @stephenw10 That's what i thought as well so I will "master" them again ;). For me this enough information, this can be closed. Thank you for your help

What's the email server you're trying to connect to? How is it configured? What connection type does it expect? Steve

Update: Looks like this was caused by certain SNORT rules. Disabling the SNORT interface and everything works again. Will update further.

@steveits said in RAM Disk Settings - inconsistent limits: I think that is related to this? https://redmine.pfsense.org/issues/13508 Thanks, yes, it does appear to be related, although my focus was on the inconsistent value reported by the GUI (before/after Save). Since my first post, I've retested on 23.05-BETA built May 03 06:05:00 UTC, and it did appear to resolve the problem (the reported limit in the GUI was consistent before, and after successful and unsuccessful changes to the RAM Disk configuration). It also did let me change /var to 300. But the redmine also reports that commit is to be reverted because of other issues. I guess I'll just wait for now.

@viragomann said in LAN Devices Not Accessing Internet through pfsense Firewall Behind 5G Router: is only needed if you intend to allow connections from the internet. Allowing inbound from private IPs on WAN is only needed if you there are other devices in the WAN subnet, which need to access pfSense or devices behind, or if you allow inbound traffic from the internet und you router nats it. To investigate your issue, you should rule out a DNS Thank you for your help and guidance on this issue. I was able to solve the problem by adjusting the DNS settings, and now the LAN devices can access the Internet without any issues.

@stephenw10 yeah its odd for sure - what I would do for testing and validation of the problem would be to duplicate dhcp and vlan without the modem. Fire up something running dhcp and let pfsense pretend its a wan interface getting dhcp and run it through the switch with the same sort of setup. untagged towards your dhcp server/gateway for pfsense, and tagged towards pfsense.. You would use anything for the test, some laptop or pi would work just fine for such testing..

Yup, there was a bug introduced. The next snap will be fixed: https://redmine.pfsense.org/issues/14351 Steve