@balanga said in Logging to loghost: @bmeeks said in Logging to loghost: Yes, you can configure a remote syslog server on the system logging tab. Here is a link to the official documentation: https://docs.netgate.com/pfsense/en/latest/monitoring/logs/remote.html describing how to configure this. I don't see a system logging tab. The docs mention :- @bmeeks said in Logging to loghost: Yes, you can configure a remote syslog server on the system logging tab. Here is a link to the official documentation: https://docs.netgate.com/pfsense/en/latest/monitoring/logs/remote.html describing how to configure this. I don't see a system logging tab. The docs mention: The Remote Logging options under Status > System Logs on the Settings tab allow syslog to copy log entries to a remote server. I don't have a System Logs entry under Status. I'm using 2.4.5_1 You should see exactly the same screens as user @Gertjan posted earlier. This basic menu and screen layout has not changed for several pfSense versions.

@wmheath586 you might also want to drill down further to the MAC address tables in your router. If you are using a managed switch you should be able to telnet into your router and inspect the MAC address table. This would be relevant if you are running multiple VMs and have left the MAC addresses at their defaults.

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.