Messages

1

Virtual private networks / Re: OpenVPN Client to Instance migartion

« on: April 10, 2024, 05:40:58 pm »

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 )

2

Virtual private networks / Re: Questions to Migrate OpenVPN Servers legacy to Instances New

« on: April 10, 2024, 05:37:16 pm »

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.

3

German - Deutsch / Best Practice OpenVPN RW mit "Instances" ?

« on: April 09, 2024, 05:16:45 pm »

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]

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

4

German - Deutsch / Re: RW IpSec läuft, aber Windows-Anmeldung hat einen Fehler

« on: April 07, 2024, 12:24:20 pm »

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.

5

German - Deutsch / [gelöst] RW IpSec läuft, aber Windows-Anmeldung hat einen Fehler

« on: April 05, 2024, 09:58:12 am »

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

6

German - Deutsch / Re: Lenovo ThinkCentre M910Q als Router mit DECT?

« on: March 26, 2024, 11:36:36 am »

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.

7

German - Deutsch / Re: HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 26, 2024, 10:44:32 am »

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

8

German - Deutsch / Re: HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 22, 2024, 07:09:32 pm »

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.

9

German - Deutsch / Re: HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 22, 2024, 05:35:29 pm »

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

10

German - Deutsch / Re: HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 22, 2024, 05:08:00 pm »

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)

11

German - Deutsch / Re: HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 22, 2024, 04:38:19 pm »

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]

-------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]

(WAN_GW (active) 0WAN IPv4 255 (upstream) 192.168.30.254) ~~~ Interface WAN Gatewayund 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?

12

German - Deutsch / Re: HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 19, 2024, 05:39:23 pm »

Habs nun testweise gemacht:

Code: [Select]

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?

13

German - Deutsch / Re: HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 19, 2024, 04:19:45 pm »

Code: [Select]

root@OPNsense:~ # sockstat | grep haproxy
www      haproxy    79957 5  tcp4   192.168.30.222:443    *:*
www      haproxy    79957 6  tcp4   192.168.30.222:80     *:*
www      haproxy    79957 7  stream /var/run/haproxy.socket.78615.tmp
root     syslog-ng  19776 24 dgram  /var/haproxy/var/run/log
root@OPNsense:~ # sockstat | grep lighttpd
root     lighttpd   15613 7  tcp4   127.0.0.1:443         *:*
root     lighttpd   15613 8  tcp6   ::1:443               *:*
root     lighttpd   15613 9  tcp6   fe80::1%lo0:443       *:*
root     lighttpd   15613 10 tcp4   192.168.3.254:443     *:*
root     lighttpd   15613 11 tcp4   192.168.0.254:443      *:*
root     lighttpd   15613 12 tcp4   192.168.9.254:443     *:*
root     lighttpd   15613 13 tcp4   192.168.21.254:443    *:*
root     lighttpd   15613 14 tcp4   192.168.60.254:443    *:*
root     lighttpd   15613 15 dgram  -> /var/run/logpriv


14

German - Deutsch / [gelöst] HaProxy http/https (80/443) und wpad.dat Konflikt

« on: March 19, 2024, 02:27:16 pm »

Hallo Allerseits,

folgende Konfiguration:
opnsense mit 8 Schnittstellen:
WAN (derzeit Testbetrieb hinter einer weitern Firewall, später soll opnsense alleine ins Netz) IP 192.168.30.222
LAN1 bis LAN7 zur Netzsegmentierung 192.168.0.0 usw.
UnboundDNS ist auf einigen LAN Schnittstellen angeboten und läuft
Squid wird auf einigen LANs angeboten und soll in diesen Netzen automatisch über DHCP (wpad.dat) zwangsweise verwendet werden (funktioniert, realisiert durch die Auslieferung über den Standardport 443 des Webservers der Weboberfläche https://opnsense.******.gmbh/wpad.dat )

Ich kämpfe nun seit mehreren Wochen damit, Haproxy ans laufen zu bekommen. (Grundsätzliches Verständnis ist vorhanden, Haproxy bereits auf IPFIRE im Einsatz, seinerzeit ohne Weboberfläche konfiguriert)

Nun klappt selbst die einfachste Variante, mit nur einem Server, nicht, obwohl der Dienst läuft und die Firewall nicht blockt (livelog der FW ist grün)

Ich vermute nun den Fehler da drin, dass ich den öffentlichen Server nicht auf 0.0.0.0:80 oder 443 betreibe sondern auf der 192.168.30.222:80 bzw. 443 (private Netze und bogon Netze blockieren auf WAN ist AUS)

Hproxy an 0.0.0.0 zu binden, habe ich es auch schon versucht, dann geht aber gar nichts mehr, was die Ports 80/443 betrifft. (weder Weboberfläche, noch Haproxy, noch wpad.dat Ausliefern)

Ziel wäre also, die Weboberfläche z.b. auf LAN1:443 und haproxy auf WAN:443 und WAN:80 zu haben.

Code: [Select]

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbthread                    3
    hard-stop-after             60s
    no strict-limits
    maxconn                     5000
    httpclient.resolvers.prefer   ipv4
    tune.ssl.default-dh-param   2048
    ssl-server-verify           none
    spread-checks               2
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 info
    lua-prepend-path            /tmp/haproxy/lua/?.lua

defaults
    log     global
    option redispatch -1
    maxconn 5000
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc
    default-server maxconn 5000

# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends

# autogenerated entries for stats


# Resolver: localhost
resolvers 65f07c72079ab5.15927014
    nameserver 127.0.0.1:53 127.0.0.1:53
    parse-resolv-conf
    resolve_retries 3
    timeout resolve 1s
    timeout retry 1s

# Frontend: frontend_https_passthrough ()
frontend frontend_https_passthrough
    bind 192.168.30.222:443 name 192.168.30.222:443
    mode http
    option http-keep-alive

    # logging options
    option httplog
    # ACL: gitlab_*******_gmbh_condition_443
    acl acl_65f8573505fac0.51650234 hdr(host) -i gitlab.*******.gmbh

    # ACTION: gitlab_*******_gmbh_rule_443
    use_backend gitlab_*******_gmbh_443 if acl_65f8573505fac0.51650234

# Frontend: frontend_http_passthrough ()
frontend frontend_http_passthrough
    bind 192.168.30.222:80 name 192.168.30.222:80
    mode http
    option http-keep-alive
    option forwardfor

    # logging options
    option httplog
    # ACL: gitlab_*******_gmbh_condition_80
    acl acl_65f853365a5227.06377745 hdr(host) -i gitlab.*******.gmbh

    # ACTION: gitlab_*******_gmbh_rule_80
    use_backend gitlab_*******_gmbh_80 if acl_65f853365a5227.06377745

# Backend: gitlab_*******_gmbh_80 ()
backend gitlab_*******_gmbh_80
    # health check: gitlab_*******_gmbh_80_health
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    option forwardfor
    server gitlab gitlab.*******.gmbh:80 check inter 5s port 80

# Backend: gitlab_*******_gmbh_443 ()
backend gitlab_*******_gmbh_443
    # health check: gitlab_*******_gmbh_443_health
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    option forwardfor
    server gitlabs gitlab.*******.gmbh:443 check inter 5s port 443  ssl sni str(gitlab.*******.gmbh) alpn h2,http/1.1 verify none

# statistics are DISABLEDReal-Server habe ich bereits sowohl als IP, als auch auch FQDN versucht, daran scheint es aber nicht zu liegen, da die Auflösung an sich funktioniert und die IP auch richtig im Maintenance-Bereich angezeigt wird.

Danke im Voraus