abrupt power loss and UFS has always been bad mix.. You should be on a ups for sure to prevent such events. ZFS is better at handling them from my understanding, but would still suggest ups. I recently changed to using zfs in the lastest release of pfsense. But I have personally not tested abruptly removing power ;) And have no plans of doing that either - better to make sure it doesn't happen then to test what happens when it does if you ask me ;)

@piersciclark said in User Manager only allows password reset of local user?: Yes, I had the same question In 2019. ..... 2.4.4-p3 had a user manager bug. Why is that, today, important ?

@alanhjames check and see if your gateway is in the 169.254.x.x range. if it is, go back to 2.5.0 to fix. I hear there is a patch for 2.5.1 to fix as well, but do not know where that is.

@gertjan Interesting ... I have a cable modem (Motorola) and when the service is down or disrupted, I get WAN n/a however, I have no RF1918 checked on WAN. Thanks for sharing, I learn something new today.

@tgimagine What do you have for an outbound NAT rule?

@twiztddwg See if they boot up without a network error then make some calls. Fingers crossed.

@viragomann connected only show in the ethernet under network & internet settings. PPPoE (OPT1) did not get any IP

Well not by anything that counts! But, OK, not in the way 169.254 is non-routable. Anyway the fact RFC1918 IP destinations are sent out of the WAN is not a problem and is required in some situations. Steve

@mrhub Hello the updated repositories to install Netdata in pfsese 2.5.1 pkg install -y pkgconf bash e2fsprogs-libuuid libuv nano pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/Judy-1.0.5_2.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/json-c-0.15_1.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-certifi-2020.12.5.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-asn1crypto-1.4.0.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-pycparser-2.20.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-cffi-1.14.5.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-six-1.15.0.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-cryptography-3.3.2.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-idna-2.10.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-openssl-20.0.1.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-pysocks-1.7.1.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-urllib3-1.25.11,1.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/py37-yaml-5.3.1_1.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/netdata-1.29.2.txz

Yup, that. Or have a transport subnet between the two routers with static routes over it so each has a route to the subnets on the other. That could be a separate VLAN between them. 'Two routers, one subnet' is almost always a bad idea. You can work around it with outbound NAT rules like that but it's much cleaner to avoid it. Steve

@akegec In the meanwhile the ISP has been changed and the problem solved, but thank You, it could help me in the future.

@kiokoman is J1900 4GB Ram, new appliance. bios is updated with a version of 2018. i have same appliances working with no issues

Figured it out… In case someone runs into the same issue: After finding this reddit post, I tried to power down the modem only, while leaving my SG-1100 on. And that did the trick for me, pfsense could finally pick up the IP for my WAN. Take that with a grain of salt though, 'cause I'm 90% sure that's the first thing I tried, so it could be a coincidence and some cache cleared somewhere or something else? ‍️ Something to try if you get stuck like me though… Thanks guys!!

@lousylucky The ICMP replies you can see in the WAN capture might be the gateway monitoring from pfSense. There is nothing redirected to the Proxmox IP without any DNAT rule. The second line in the capture screenshot shows that the packets go out with the LAN address and the Outbound NAT screen shows no rule. So for sure, there is nothing translated when packets go out on WAN and therefor if you set the rule on Proxmox for the LAN subnet, ping to public IPs will work. @lousylucky said in Can ping Internet from Pfsense but cannot from LAN: I can't get access to the internet (but as we can see data are going to the internet and stopped on pfsense) Where do you think to see that? pfSense should add outbound NAT rules automatically for internal networks to interfaces which have a gateway defined. A assume the Proxmox IP is set as gateway in the WAN interface settings, cause of the gateway monitoring, but check it again, please. Then go to the outbound NAT, select "automatic rule generation" and hit save and check if an auto-rule is generated. If not switch to the hybrid mode and re-enable the manual rule.

When the system shuts down - a the controlled way - the so called 'journal' emptied : all 'disk transactions' are recorded. But ok, a system can 'crash' (actually never saw it crashing it during the last 10 years, but I am very able to crash it myself when editing core settings by hand). So, it can happen that the system == the disk was not properly 'dismounted' during the last reboot. fsck - you probably know what 'chkdsk' if you're from a DOS world (the thing before Windows existed). Give the "Processing journal entries" some time. Btw :Before you do an upgrade : Make a second backup of your config.xml, that is, one more as the daily backup you already made. Include ALL the info, like also the RDD stats. Double check your insurance : you have the USB drive with the actual installed pfSense version. Check recent system logs (all logs) for less frequent messages. The dashboard tells you there are packages to be updated : don't fall for it : whime there are packages to be upgraded - and your not on the latest pfSense, do NOT upgrade packages. Read the upgrade notices on the Netgate's blog. Test the console access. The GUI exists for the "all is well" days. The console access exists for the more serious things. Make sure the console access is logged ( !! if that works, you'll be sure you never need these logs !! ) While the console access is up, do a initial reboot from the console, to detcet any issue that might exist even before you upgrade. If the system comes back clean, and everything is fine, no you can hit the "upgrade" phase. because the console access works great, use menu option 13 so you can see (and have it logged), the entire process. If there is a failure, you now see what it is, share it with us - if not, just reboot a last time and your good. If it doesn't, don't waste any precious time : get and write to a second (2 !) USB drive the new pfSense ISO (this could have been done upfront ... I know) Reboot the system again, boot from the second USB drive, install pfSense (from scratch) , do a minimal (like minimal !!) setup ==> make WAN work - that's it). Install, manually ( !!! ) all packages you used, do not set them up. Now, and only now, import your config.xml. Reboot the system. Done. Enjoy. This seems a lengthy process, but it isn't. You should always have backup files and ISO's. - that can be done when ever you want. The reboot phases and checking is 5 minute seconds max. Because you took all the precautions, nothing will fail - ever - Murphy is there to protect you. I've tested this procedure during the last ... 20 or more versions of pfSense ? It works. It helped me to detected bad hardware - an ISP connection that was bad and all other situations that are more difficult to handle when you're in the upgrade phase. edit : and before you say : hey, that's a long story for what should be an easy click and pray method. Actually, it isn't. This 'procedure' should be executed before you upgrade your phone, PC, MAC, server, coffee machine and doorbell. Also for firewall/routers.

@dominikhoffmann said in Has my SG-1100 been pwned?: I discovered that I couldn’t log into my SG-1100: In that case - do nothing - and switch over right away to the second access : That could be the SSH access (has to be setup up before) - or the console, which always works. The menu shows up ? Use option 11 - (restart the GUI part). @dominikhoffmann said in Has my SG-1100 been pwned?: Now it again is failing. Time to regain access and do what admin always do : By looking at the dashboard you'll learn nothing. The dashboard is there for the times when all is ok. Look at the - all the - logs. You should always be looking at the logs. Eventually, you'll know what messages are normal. The day things go south, you'll know what messages are new, and you know what happened. @dominikhoffmann said in Has my SG-1100 been pwned?: rather than a maliciously changed password? They would have to use the certificate to gain access, first. Just ise the classic 1234 password for GUI access. Lock down the GUI access to a trusted LAN - do not let non trusted devices access this LAN, and use a OpenVPN access if you need to do some remote admmining of pfSense. See the Youtube => Netgate => OpenVPN vdeos (even the old ones).

@froboz Yes. I am trying to update the FW from 3/31/21 on Intel's Support page. https://downloadcenter.intel.com/download/24769/Non-Volatile-Memory-NVM-Update-Utility-for-Intel-Ethernet-Network-Adapter-700-Series There is another thread that another user got this working: https://forum.netgate.com/topic/162333/intel-x710-issues/8?_=1620678897780

@jknott said in No internet connectivity after replacing cable modem: @soul710 Well, it's time to start some packet captures to see what's happening. As I mentioned, something has to tell pfsense to get the new address. As for rebooting, Is the modem going through the same steps when you reboot pfsense? If so, then all you're doing is repeating the situation. The only alternative I can think of, other than the modem dropping the connection s an extremely short DHCP lease on the first address. Disconnect the modem and reboot pfsense. Once it's up, start Packet Capture on DHCP and reconnect the modem. You might keep an eye on the Ethernet LEDs to see if the link drops briefly when the modem changes addresses. What happens if you use the ifconfig command to disable and enable the WAN port? Okay so, in fact, I had a second router running OpenBSD, and it was suffering from the same issues. I had set up the OpenBSD box as replacement for the pfsense even, and I have used for a while now instead of the pfsense, but now I switched back to pfsense to track down the internet issues. As it turned out, I had a firewall rule which was preventing the traffic: #--------------------------------------------------------------------------- # default deny rules #--------------------------------------------------------------------------- block in log inet all tracker 1000000103 label "Default deny rule IPv4" block out log inet all tracker 1000000104 label "Default deny rule IPv4" block in log inet6 all tracker 1000000105 label "Default deny rule IPv6" block out log inet6 all tracker 1000000106 label "Default deny rule IPv6" Which is a bit weird, after I removed the block out log inet things went back to normal. I don't quite understand this; since I don't have succeeding pass rules, which should have allowed outgoing traffic. So this rule should have blocked internet even before I have replaced the cable modem? The essential change was that the WAN IP of the box changed from 192.168.0.10 to 178.xx.xx.xx (public IP).