[go: up one dir, main page]

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Categories

  • Discussions about TNSR

    379 Topics
    1k Posts
    M
    Not sure why but there is no ability to log ACLs or VPFs rules. I cant troubleshoot when i dont know if an ACL rule is blocking or accepting a connection. To say nothing for auditing and having those logs sent to a syslog collector...

  • Discussions about pfSense Software, click a category below

    122k Topics
    783k Posts
    M
    See https://forum.netgate.com/topic/200959/pkg-warning-for-missing-le-e7-cert

  • Discussions about pfSense software packages

    21k Topics
    130k Posts
    jimpJ
    The description of that setting means what it says, though in the past that may not have been true, and it did change out of necessity because of upstream changes in Let's Encrypt. Let's Encrypt recommends renewing at 2/3 the lifetime remaining (e.g. 60 days remaining out of 90), not 2/3 expired (30 days left). The lifetime of LE certs can now vary wildly depending on the profile you specify, and can be as low as 6 days for shortlived certs. Future default lifetimes are going to be 45 days instead of 90, too. I had to "future-proof" the GUI option as that lowers so someone's hardcoded number wouldn't break the logic as LE updates their lifetimes automatically as time goes on. If someone hardcoded 60 in there and the cert lifetime lowered to 45, this avoids the user getting a rude awakening when it never renews. So now you set the number of days remaining in the lifetime at which the certificate gets renewed, if you care to set a manual value at all. If you want it to renew when it has 30 days of lifetime left, enter 30. See also: https://redmine.pfsense.org/issues/16603 This also aligns it with the expiration notification behavior: https://redmine.pfsense.org/issues/16605

  • Discuss pfSense in other languages

    43k Topics
    268k Posts
    D
    Update Heute Morgen ist der Fehler erneut aufgetreten. Hier der relevante Auszug aus dem Authentifizierungs-Log: Jul 27 08:58:52 openvpn 64884 /openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials. Jul 27 08:58:45 openvpn 64884 user 'User_3 could not authenticate. Jul 27 08:58:45 openvpn 64884 /openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials. Jul 27 08:58:40 openvpn 64884 user 'User_3' could not authenticate. Jul 27 08:58:40 openvpn 64884 /openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials. Jul 27 08:42:45 openvpn 64884 user 'User_4' could not authenticate. Jul 27 08:42:45 openvpn 64884 /openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials. Jul 27 08:38:10 openvpn 54810 user 'User_1' authenticated Jul 27 08:38:00 openvpn 33838 user 'User_1' authenticated Jul 27 08:37:58 openvpn 28831 user 'User_5' authenticated Jul 27 08:37:53 openvpn 64884 user 'User_1' could not authenticate. Jul 27 08:37:53 openvpn 64884 /openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials. Jul 27 08:36:56 php-fpm 84141 /index.php: Successful login for user 'admin' from: 10.49.255.204 (Local Database) Jul 27 08:36:45 php-fpm 84141 /index.php: Session timed out for user 'admin' from: 10.49.255.204 (Local Database) Jul 27 08:17:36 openvpn 84141 user 'User_2' authenticated Spannendes Detail im Log: Während der PHP-Prozess mit der PID 64884 dauerhaft fehlschlägt, konnten andere PIDs (28831, 33838, 54810) dazwischen erfolgreich authentifizieren. Das Problem betrifft also offenbar gezielt hängende PHP-Worker-Prozesse bzw. veraltete Socket-Handles. Ich habe sofort folgende Tests auf der pfSense-Konsole durchgeführt, während der Fehler aktiv war: Ping auf den Hostnamen des DCs: Erfolgreich. DNS-Auflösung des DCs: Funktionierte, wirkte aber gefühlt etwas verzögert ("hat ein wenig gedauert"). Zertifikat via OpenSSL: openssl s_client -connect <DC_IP>:636 -showcerts hat sofort das korrekte LDAPS-Zertifikat geliefert. PHP-FPM Restart: Ich habe /etc/rc.php-fpm_restart ausgeführt. Direkt danach funktionierte die OpenVPN-Authentifizierung sofort wieder für alle Benutzer! Hat jemand eine Idee, wie ich dieses Problem in den Griff bekomme?

  • Information about hardware available from Netgate

    3k Topics
    21k Posts
    M
    For reference: https://github.com/influxdata/telegraf/issues/19072

  • Information about hardware available from Netgate

    44 Topics
    211 Posts
    AriKellyA
    It looks like unified web management could be coming soon. It would be great if it means easier control and management of all web services in one place. Let's see if any companies announce more details about it!

  • Feel free to talk about anything and everything here

    4k Topics
    19k Posts
    stephenw10S
    You should just set the identifier to something specific but valid. So I'd use FQDN, it doesn't change with actual IP address used. It only needs to match at each end.
Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.
Privacy Policy · Cookie Policy