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

[AlexS]

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 Expand

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 DISABLED
Real-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

[AlexS]

Code Select Expand

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


[Monviech (Cedrik)]

WebUI auf allen Interfaces hören lassen. Keine Interfaces einzelnd auswählen. (Da steht aus gutem Grund "All (recommended" bei Listen Interfaces.)

WebUI Port auf z.B. 8443 stellen. Redirect Regel austellen.
(System - Settings - Administration)

[AlexS]

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?

[Monviech (Cedrik)]

Ja, all interfaces kann beim Bootvorgang auch gebunden werden, wenn ein physikalisches Interface nicht verfügbar ist.

WebUI einschränken/Freigeben macht man über Firewall Regeln.

Schade dass HA Proxy noch nicht geht, Ports überschneiden sich nicht mehr.

[AlexS]

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?

[viragomann]

Hallo,

- Gibt es nun eine Einstellung, die eine solche Kommunikation erlauben würde? (also aus dem 30.0-Netz) oder ist das mit Absicht so?

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

- Kann ich Haproxy so konfigurieren, dass Anfragen opnsense.************.gmbh:443 über den Haproxy auf localhost:444 (also die jetzt umgezogene Weboberfläche) weiterleitet?

Habe ich zwar noch nicht gemacht, aber ich denke, das müsste gehen, wenn du localhost:444 als Backend hinzufügst.

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

[AlexS]

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)

[Monviech (Cedrik)]

Was machst du denn mit HA Proxy, gibt es irgendwelche TCP oder UDP Streams die du benötigst? Oder ist es nur für HTTP/HTTPS Reverse Proxy?

[AlexS]

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

[viragomann]

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.

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

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)

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

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.

[Monviech (Cedrik)]

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

Ist auch einfach die WebUI zu Proxien und den Zugriff auf intern einzuschränken.

https://docs.opnsense.org/manual/how-tos/caddy.html#reverse-proxy-the-opnsense-webui

[AlexS]

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.

[Monviech (Cedrik)]

Für den gehobenen Anspruch ist HA-Proxy definitiv die flexibelste und beste Wahl.

[AlexS]

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