Messages

Kann man eigentlich das Legacy UI jetzt schon deaktivieren oder zumindest ausblenden?
Bin vor einem halben Jahr zu Opnsense migriert und direkt alles auf Instances umgesetzt. das Legacy UI ist daher nur störend.... :)

is solved here: https://forum.opnsense.org/index.php?topic=45484.0

# opnsense-patch https://github.com/opnsense/core/commit/695772d2017
# service configd restart

Same here on 3 different Systems with Intel CPU ( i5-8250U / i5-6200U / i7-7500U)
seems to be a Bug

[use a loopback address combined with a port forward when the external address is not static]

Note 1: Leave empty to bind to all addresses assigned to this machine or use a loopback address combined with a port forward when the external address is not static. (found here: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html )

[use a loopback address combined with a port forward when the external address is not static]

Note 1:
Leave empty to bind to all addresses assigned to this machine or use a loopback address combined with a port forward when the external address is not static. (from here: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html )

I'm trying to set up OpenVPN with instances too (posted here: https://forum.opnsense.org/index.php?topic=39912.0 but we can continue here)
didn't found more information about this case and faced some troubles, but i think it will be a better solution when it is done.

ich migriere derzeit von IpFire zu OpnSense.
die Roadwarriors sollen, wie bisher per OpenVPN auf die LAN-Netzwerke zugreifen.
Es gibt ja nun die Möglichkeit, die Legacy-Einstellung (Server/Client) zu verwenden.
Da es ja nun eine neue Art der Konfiguration für OpenVPN gibt, und ich sowieso alles neu mache, wollte ich das auch direkt diese neue Art verwenden.
für einen Testclient habe ich das nun nach dieser Anleitung hier: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html ans Laufen bekommen. (OpenVPN Client 2.6.10, zunächst noch nicht als Service, das muss noch getestet werden)
mir ist nun aber nicht ganz klar, wie ich das ganze auf 50+ User skalieren kann.
wenn ich eine Instanz lasse, teilen sich alle Clients ein Zertifikat
wenn ich für jeden Client eine eigene Instanz machen muss, entsteht sehr viel Konfigurations-Overhead, wo man jede Instanz praktisch mit identischen Daten für Local Network etc. füttern muss, und zwar immer mit jeweils eigenem "tunnel network used"

Code Select Expand

Property site B
Role Server
Description MyServer
Protocol UDP (IPv4)
Port number 1194
Bind address 10.10.8.1
Server (IPv4) 10.1.8.0/24 (the tunnel network used)
Certificate choose the prepared server certificate
TLS static key choose the prepared static key
Authentication Local Database
Strict User/CN Matching [V]
Local Network 192.168.8.0/24

habe ich irgendwo einen Denkfehler? Wie bekomme ich für jeden Clienten eine fixe IP (optional)?

Danke und Gruß

EDIT: es geht hier weiter: https://forum.opnsense.org/index.php?topic=38532.0

hab ich tatsächlich nicht selbst gefunden, aber jetzt läuft es, wie erwartet. Vielen Dank

für die Nachwelt:

ein etwas "besserer" Link https://administrator.de/forum/windows-vpn-l2tp-falsche-anmeldedaten-3678210108.html

unter ...\AppData\Roaming\Microsoft\Network\Connections\Pbk die Datei rasphone.pbk angelegt mit den Einstellungen der VPN Verbindung.
Der Eintrag UseRasCredentials=0 oder 1 regelt ob Windows den VPN-Benutzer-Namen beim Zugriff auf Netzwerkressourcen nutzt oder den Windows-Anmeldenamen.
UseRasCredentials=1 ist der Standard nachdem Einrichten und es wird der VPN-Benutzer genommen
UseRasCredentials=0 es wird der Windows-Benutzer genommen.

Hallo Allerseits,

habe die RW Verbindung nach dieser Anleitung https://forum.opnsense.org/index.php?topic=33020.0 gemacht und es funktioniert fast alles, wie erwünscht.

die Verbindung erfolgt an vpn.*********.com mit dem Nutzernamen wws16 und einem längeren Kennwort, welches nur für die Tunnelverbindung genutzt wird.

der zugriff auf ein Qnap-Nas über \\nas1 im Explorer funktioniert, Namensauflösung, Remotedesktop, Zugriff auf Webdienste, ping, tracert etc, ins LAN funktioniert auch.

ruft man nun \\nas2 auf, welches ein Windows-Server ist, verlangt nach einem Passwort, statt meinem Usernamen domain.lan\a.nachname (eigentlich sollte das komplett im Hintergrund ablaufen, ich bin ja am System angemeldet) kommt eine Passwort-Abfrage für den Nutzernamen wws16.
Das gleiche passiert  auch, wenn man \\domain.lan im Explorer aufruft, hier scheint die Domainanmeldung nicht mit richtigen credentials zu laufen.

Ich vermute, dass man dieses Verhalten per Powershell oder Registry abstellen kann, habe aber über Google noch nicht die richtige Lösung gefunden, vielleicht hatte jetmand hier das gleiche Problem und kann mir einen Tipp geben.

Danke im Voraus

DECT lässt sich nicht mit einer PC-Hardware realisieren, du kannst aber fast beliebige DECT-Router hinter OPNSENSE packen, die Telekom-VOIP nach DECT wandelt.

Ich denke, der Thread hier ist nun erledigt.
Haproxy läuft und auch der Zugriff auf die Weboberfläche über 443 aus dem LAN ist möglich:

HAproxy kennt die ACLs "Source IP is local" oder "Source IP matches specified IP"

source IP is Local hat nicht gegriffen, aber source IP matches specified IP mit der passenden IP klappt.

http mit haproxy hat eigentlich praktisch sofort funktioniert, nachdem ich die Testumgebung angepasst habe (Zugriff übers vorgelagerte Gateway)
bei https hatte ich für passtrough einen entscheidenden Fehler eingebaut: bei Real Server SSL angehakt. Wenn es gesetzt ist, funktioniert es nicht. Erst die Entfernung des Hackens hat das gewünschte Ergebnis geliefert.

das ganze habe ich mit Hilfe dieser Anleitung ans Laufen gebracht: https://forum.opnsense.org/index.php?topic=18538.0

In den Firewall Logs ist ja die zuständige Regel ersichtlich. Hilft diese Info nicht weiter?

ich beobachte das immer direkt übers LiveLog, da ist es grün, und auch die richtige Regel, das ist es also nicht. [komme von früher ipcop und zzt noch ipfire, bin also kein Frischling, der keine Logs lesen kann (:  ]

Ich verstehe dennoch nicht den Sinn, von intern über HAproxy auf die WebGUI zu gehen.
Du kannst du local auch eine zusätzlich IP dafür nutzen, wenn es Port 443 sein soll (warum auch immer).

ich will ja nicht primär auf die WebGUI über 443 gehen, es geht um eine elegante Lösung für die wpad.dat-Datei, die auf dem selben Dienst ausgeliefert wird, wie die WebGUI. Also über https://opnsense.firma.de:444/wpad.dat von den internen Interfaces aus (das ist vom DNS her kein Problem, da wird eine LAN-IP übergeben, die aus allen LAN-Netzen erreichbar ist), es ist aber nicht sehr elegant und kann durch den nicht-Standard-Port auch schon mal zu Problemen führen.

Ich habe 4 verschiedene LAN Interfaces, die auf den Proxy über die WPAD zugreifen sollen. (automatische Proxy-Konfiguration über DHCP)

Die Ursprüngliche Idee war also:
webgui-dienst auf Port 443 bei diesen 4 Interfaces zu setzen -> WPAD wird über 443 ausgeliefert
haproxy-dienst auf Port 443 nur bei WAN zu setzen -> Haproxy ist nur von WAN aus auf Port 443 erreichbar und leitet die Anfragen an interne Dienste weiter

jetzt haben wir gelernt: haproxy muss auf all:443, webgui auf all:444

da nun haproxy auch aus internen Netzen zu erreichen ist, kann es doch auch die Anfragen an den GUI-Dienst von IP:443 auf Localhost:444 weitergeben und wir haben (über den Umweg haproxy) genau das, was ursprünglich benötigt wurde. (Firewall lasse ich bei dieser Betrachtung raus, das ist klar, dass das dann zu konfigureiren wäre)

HAproxy kennt die ACLs "Source IP is local" oder "Source IP matches specified IP". Damit sollte sich was machen lassen.
Von pfSense kenne ich es jedenfalls, dass man in diesen ACLs auch Aliases mit (lokalen) IPs oder Subnetzen angeben kann. Das sollte doch bei OPNSense auch gehen. Ansonsten wäre ich hier ohnehin falsch

Danke für den Tipp, das werde ich dann in einem der nächsten Schritte testen.

Wenn du keine WAF brauchst kannst du ja mal os-caddy ausprobieren. Dort hab ich auch ein NTLM Plugin eingebaut für sauberes Exchange Server Reverse Proxying (benutze es mit ein paar, da musst du nicht den Basic Auth Trick verwenden wie z.B. bei Nginx etc...).

das scheint was neues zu sein, davon habe ich schon mal auf der Suche nach dem Fehler gelesen, das werde ich mir vermutlich auch mal ansehen. Haproxy habe ich bereits Jahrelang auf ipfire im Einsatz, und bis auf ein Paar kleinere Ausfälle wegen Update-Fehlern der Distro macht es keine Probleme. Das hat seine Community und wird bestimmt seinen Support nicht so schnell verlieren. Das muss bei os-caddy sich noch zeigen.

nur für HTTP/HTTPS Reverse Proxy, kein Offloading, die Server haben unterschiedliche Zertifikate (Kaufzertifikat aufm Exchange, letsencrypt aufm Nextcloud)

In den WAN Interface-Settings ist standardmäßig "Block private networks" aktiviert. Hast du den Haken entfernt?

klar, wenn der Hacken gesetzt ist, blockt die Firewall alle Anfragen. Das war die erste Anlaufstelle.

Ich würde aber empfehlen, generell keinen dauerhaften Zugriff auf die WebGUI zuzulassen und für diesen Zweck eine VPN einzurichten

das dient eher dem Internen Zugriff auf 443 (Trickshot fürs WPAD auf 443, obwohl lighttpd auf 444 läuft), die WebGUI wird nie von WAN aus Erreichbar sein. (ich hoffe, ich kann haproxy-Regeln so einstellen, dass die Anfragen auf die entsprechende URL nur aus internen Netzen verarbeitet werden)

Alles klar, Danke für die Antwort.

damit kann ich nun arbeiten.

nun zum eigentlichen Problem:
Ich habe festgestellt, dass wenn man im WAN-Bereich zwischen dem Gateway und WAN Interface ist, der Opnsense keine Anfragen annimmt. und zwar sieht es folgendermaßen aus:

Code Select Expand


-------LAN [OPNSENSE] WAN --------------------------- GW [Router] ------- Internet
192.168.1.1|        |192.168.30.222        192.168.30.254|      | ------- weiteres LAN z.b 192.168.0.0

Richtet man nun aus dem Adressbereich 192.168.30.x Anfragen an die 192.168.30.222, sind diese zwar im Firewall-Log sichtbar, werden aber seitens OPNSENSE überhaupt nicht verarbeitet. Weder Ping, noch http https oder sonst etwas.
Und das war eigentlich genau mein Testszenario, welches ich die letzten Wochen zum Laufen bringen wollte.
Die 192.168.30.254 ist als WAN_GW im opnsense eingetragen

Code Select Expand

(WAN_GW (active) 0WAN IPv4 255 (upstream) 192.168.30.254) ~~~ Interface WAN Gateway
und damit funktioniert die Kommunikation beidseitig.

Selbst anfragen aus dem 0.0 Netz an die 30.222 gehen ohne weiteres durch und werden verarbeitet. Damit läuft nun haproxy mit http, https meldet auch schon mal Zertifikatsfehler, ist also noch hinzubekommen.

das wären jetzt noch die Fragen, die jetzt noch habe:
- Gibt es nun eine Einstellung, die eine solche Kommunikation erlauben würde? (also aus dem 30.0-Netz) oder ist das mit Absicht so?
- Kann ich Haproxy so konfigurieren, dass Anfragen opnsense.************.gmbh:443 über den Haproxy auf localhost:444 (also die jetzt umgezogene Weboberfläche) weiterleitet?

Habs nun testweise gemacht:

Code Select Expand

root@OPNsense:~ # sockstat | grep lighttpd
root     lighttpd   94982 7  tcp4   *:8443                *:*
root     lighttpd   94982 8  tcp6   *:8443                *:*
root     lighttpd   94982 9  dgram  -> /var/run/logpriv
root@OPNsense:~ # sockstat | grep haproxy
www      haproxy    26828 5  tcp4   *:443                 *:*
www      haproxy    26828 6  tcp4   *:80                  *:*
www      haproxy    26828 7  stream /var/run/haproxy.socket.26719.tmp
www      haproxy    26828 17 dgram  (not connected)
www      haproxy    26828 18 dgram  (not connected)
www      haproxy    26828 19 dgram  (not connected)
root     syslog-ng  19776 24 dgram  /var/haproxy/var/run/log


Ergebnis:
Haproxy weiterhin ohne Funktion
wpad.dat ohne Funktion

Ich werde das die Tage nochmal ausführlich testen (habe nur kurze Testzeitfenster, kann also dauern)

"all interfaces" scheint mir in meinem Weltbild nicht logisch, vor allem WAN und DMZ sollte so wenig Angriffsfläche anbieten wie möglich. Gibts da eine logische Erklärung für?