Messages

Erst mal gelöst, siehe https://github.com/opnsense/plugins/issues/4266

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

Code Select Expand

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

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

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).

Code Select Expand


#/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

Same here, please see https://github.com/opnsense/core/issues/4652

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

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 :-)

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.

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