1
German - Deutsch / [solved] Re: Nginx - Basic Auth mit Advanced ACLs funktioniert nicht
« on: September 30, 2024, 07:08:59 pm »
Erst mal gelöst, siehe https://github.com/opnsense/plugins/issues/4266
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
German - Deutsch / [solved] Nginx - Basic Auth mit Advanced ACLs funktioniert nicht
« on: September 25, 2024, 07:33:47 pm »
Dear all,
ich versuche in der aktuellen OPNsense 24.7.4_1-amd64 mittels Nginx eine Seite durch Basic Auth zu schützen, die Authentifizierung soll unter Verwendung der Advanced ACLs (aktiviert unter 'Edit Location', 'Enable Advanced ACLs' gegen einen unter 'System: Access: Servers' eingerichteten externen LDAP-Server laufen.
Der externe LDAP-Server ist vollständig eingerichtet, OPNsense kann gegen diesen authentifizieren (validiert via 'System - Tester').
Stelle ich nun in der Nginx-Config unter 'HTTP Server' das 'Advanced ACL Authentication Backend' auf das vorher konfigurierte LDAP-Backend um, erscheint anstatt des Basic Auth Dialogs ein 500er Fehler, im Logfile des Nginx steht
Selbiges passiert wenn ich anstatt des LDAP-Backends auf 'Local Database' umstelle.
Mit Basic Auth gg. eine testweise angelegte Nginx-interne Benutzerdatenbank ('Credential' / 'User List') funktioniert Basic Auth.
Was mache ich falsch?
Vielen Dank, Stephan
Update - habe dazu ein Ticket aufgemacht: https://github.com/opnsense/plugins/issues/4265
ich versuche in der aktuellen OPNsense 24.7.4_1-amd64 mittels Nginx eine Seite durch Basic Auth zu schützen, die Authentifizierung soll unter Verwendung der Advanced ACLs (aktiviert unter 'Edit Location', 'Enable Advanced ACLs' gegen einen unter 'System: Access: Servers' eingerichteten externen LDAP-Server laufen.
Der externe LDAP-Server ist vollständig eingerichtet, OPNsense kann gegen diesen authentifizieren (validiert via 'System - Tester').
Stelle ich nun in der Nginx-Config unter 'HTTP Server' das 'Advanced ACL Authentication Backend' auf das vorher konfigurierte LDAP-Backend um, erscheint anstatt des Basic Auth Dialogs ein 500er Fehler, im Logfile des Nginx steht
Code: [Select]
2024/09/25 19:15:32 [error] 65485#105117: *762 auth request unexpected status: 302 while sending to client, client: x.x.x.x, server: xxx.xxx.cc, request: "GET /favicon.ico HTTP/2.0", host: "xxx.xxx.cc", referrer: "xxx.xxx.cc/?login&href="Selbiges passiert wenn ich anstatt des LDAP-Backends auf 'Local Database' umstelle.
Mit Basic Auth gg. eine testweise angelegte Nginx-interne Benutzerdatenbank ('Credential' / 'User List') funktioniert Basic Auth.
Was mache ich falsch?
Vielen Dank, Stephan
Update - habe dazu ein Ticket aufgemacht: https://github.com/opnsense/plugins/issues/4265
3
23.7 Legacy Series / Virtual IP stops to work after failover
« on: August 27, 2023, 10:10:50 am »
Hi,
got a problem with a Virtual IP: have a setup with two uplinks (VDSL & Starlink) and added a Virtual IP to reach Starlink's Dishy status page (as described here e.g. https://matthias.guru/2021/12/13/starlink-mit-opnsense-pfsense-als-router/).
Now each time an uplink is removed or re-added, the virtual IP setup fails, at least until I go to the Virtual IP page, modify something (no matter what), save & apply, go back to the settings page, revoke my modification to the original settings and save & apply once more.
After that, Dishy is reachable again.
Any ideas?
Thx & regards,
Stephan
got a problem with a Virtual IP: have a setup with two uplinks (VDSL & Starlink) and added a Virtual IP to reach Starlink's Dishy status page (as described here e.g. https://matthias.guru/2021/12/13/starlink-mit-opnsense-pfsense-als-router/).
Now each time an uplink is removed or re-added, the virtual IP setup fails, at least until I go to the Virtual IP page, modify something (no matter what), save & apply, go back to the settings page, revoke my modification to the original settings and save & apply once more.
After that, Dishy is reachable again.
Any ideas?
Thx & regards,
Stephan
4
23.1 Legacy Series / Re: Stale NAT states on WAN-IP change prevent SIP re-register
« on: February 25, 2023, 12:05:49 pm »
What is doing the job for me atm is a small bash script that checks via cron every 5 minutes if the respective IP (pppoe2 here) has changed. In that case, all states related to the old IP are killed.
Not super sophisticated and might miss some edge cases (e.g. if pppoe2 is down and there is no IP, maybe I'll add that case later), but at least for me it works and allows the SIP channels to re-register (here with debug ouptput).
Cheers,
Stephan
Not super sophisticated and might miss some edge cases (e.g. if pppoe2 is down and there is no IP, maybe I'll add that case later), but at least for me it works and allows the SIP channels to re-register (here with debug ouptput).
Code: [Select]
#/usr/local/bin/bash
current_ip=$(ifconfig pppoe2 | grep 'inet' | awk -F ' ' '{ print $2 }')
read cached_ip < /opt/cached_ip
if [[ $current_ip == $cached_ip ]]; then
echo "IPs gleich"
else
pfctl -k $cached_ip
echo "$current_ip" > /opt/cached_ip
echo "States gekillt"
fi
Cheers,
Stephan
5
23.1 Legacy Series / Re: -> firewall: remove deprecated "Dynamic state reset" mechanic
« on: January 28, 2023, 11:28:29 pm »
Same here, please see https://github.com/opnsense/core/issues/4652
6
23.1 Legacy Series / Stale NAT states on WAN-IP change prevent SIP re-register
« on: January 27, 2023, 02:44:27 pm »
Migrated to 23.1 yesterday, good job guys btw!
My OPNSense is connected via a VDSL line (and a second line, so it's multiwan setup if that's relevant) with a public IPV4 on the WAN side,the IP changes every 24 hours.
Behind the OPNSense box there is a FreePBX (Asterisk) registering SIP trunks to Telekom and Sipgate. That's working well. In principle.
As soon as the WAN-IP changes, Asterisk is unable to re-register.
Checking with pfctl -s state -vv | grep FreePBX-IP | grep :5060 confirms that the states still refer to the old, now invalid public IP address, so that the SIP-UDP packets have a wrong origin IP and the anwers never come back.
A similar problem was already mentioned in https://forum.opnsense.org/index.php?topic=10385.msg47423#msg47423
The solution mentioned there was to tick the box for 'Dynamic State Reset', however this box is missing in 23.1 ('firewall: remove deprecated "Dynamic state reset" mechanic').
The only solution atm for me is to manually flush all states using 'Reset state table' from the webinteface. After that the SIP channels are immediately re-registered.
Any advice is welcome - and as a workaround, is there an easy way to execute the flush command automatically on every WAN IP change?
Thanks for help, Stephan
Update: Seems as only the Sipgate Channels are affected, the DTAG channels re-register immediately.
Update 2: Found https://github.com/opnsense/core/issues/2414. According to that, the problem should be already fixed?
Update 3: See also bug report https://github.com/opnsense/core/issues/4652
My OPNSense is connected via a VDSL line (and a second line, so it's multiwan setup if that's relevant) with a public IPV4 on the WAN side,the IP changes every 24 hours.
Behind the OPNSense box there is a FreePBX (Asterisk) registering SIP trunks to Telekom and Sipgate. That's working well. In principle.
As soon as the WAN-IP changes, Asterisk is unable to re-register.
Checking with pfctl -s state -vv | grep FreePBX-IP | grep :5060 confirms that the states still refer to the old, now invalid public IP address, so that the SIP-UDP packets have a wrong origin IP and the anwers never come back.
A similar problem was already mentioned in https://forum.opnsense.org/index.php?topic=10385.msg47423#msg47423
The solution mentioned there was to tick the box for 'Dynamic State Reset', however this box is missing in 23.1 ('firewall: remove deprecated "Dynamic state reset" mechanic').
The only solution atm for me is to manually flush all states using 'Reset state table' from the webinteface. After that the SIP channels are immediately re-registered.
Any advice is welcome - and as a workaround, is there an easy way to execute the flush command automatically on every WAN IP change?
Thanks for help, Stephan
Update: Seems as only the Sipgate Channels are affected, the DTAG channels re-register immediately.
Update 2: Found https://github.com/opnsense/core/issues/2414. According to that, the problem should be already fixed?
Update 3: See also bug report https://github.com/opnsense/core/issues/4652
7
German - Deutsch / IPv6 Präfix-Wechsel (Gateway) beendet dpinger
« on: September 18, 2021, 10:46:26 am »
Die Gateway-IP meines IPv6-Tunnels ändert sich täglich, dpinger sirbt dann. Erst nach einem manuellen Neustart funktioniert das GW dann wieder.
Im 'gateways-Log' steht:
dpinger[52148]: PORTUNITYVPN_GW 2a02:a00:f::c2: sendto error: 50
Bei der Forumsuche habe ich folgenden Beitrag gefunden, allerdings ohne Lösung:
https://forum.opnsense.org/index.php?topic=12901.0
Hat jemand eine Idee, wie man das lösen kann? Danke :-)
Im 'gateways-Log' steht:
dpinger[52148]: PORTUNITYVPN_GW 2a02:a00:f::c2: sendto error: 50
Bei der Forumsuche habe ich folgenden Beitrag gefunden, allerdings ohne Lösung:
https://forum.opnsense.org/index.php?topic=12901.0
Hat jemand eine Idee, wie man das lösen kann? Danke :-)
8
German - Deutsch / Re: PPPOE mit Draytek Vigor 166
« on: September 18, 2021, 10:35:43 am »
Scheint ein sporadisch auftretendes Problem zu sein, mit dem Vigor 130 habe ich gar keine Verbindung hinbekommen, mit dem 165er ging es eine Zeit lang gut, dann nicht mehr. Der 167er läuft seit zwei Wochen stabil.
Log sah bei mir identisch aus.
Wenn jemand eine Idee hat, wie man das Problem weiter eingrenzen kann, wäre ich interessiert.
Log sah bei mir identisch aus.
Wenn jemand eine Idee hat, wie man das Problem weiter eingrenzen kann, wäre ich interessiert.
9
21.7 Legacy Series / Multi WAN same Gateway issue
« on: September 06, 2021, 03:37:19 pm »
Hi all,
just replaced Vigor with Opnsense. Works great, however one issue remains:
I'm running a multi WAN setup, having three uplinks, two to local ISPs using PPPoE, one to Starlink. In this setup I cannot operate the two PPPoE-Uplinks in parallel, they both come up and IP addresses are assigned, but one of the 'PPPoE'-gateways is always marked as down (see screenshots).
Just checked the forum and found https://forum.opnsense.org/index.php?topic=10077.msg46128#msg46128 from 2018.
Is this still the case? Or am I missing something?
Thx for any help & best regards,
Stephan
just replaced Vigor with Opnsense. Works great, however one issue remains:
I'm running a multi WAN setup, having three uplinks, two to local ISPs using PPPoE, one to Starlink. In this setup I cannot operate the two PPPoE-Uplinks in parallel, they both come up and IP addresses are assigned, but one of the 'PPPoE'-gateways is always marked as down (see screenshots).
Just checked the forum and found https://forum.opnsense.org/index.php?topic=10077.msg46128#msg46128 from 2018.
Is this still the case? Or am I missing something?
Thx for any help & best regards,
Stephan
Pages: [1]