Messages

Aber hier sieht doch alles danach aus, als sei das Gegenteil der Fall: die Kette ist zu kurz. Normalerweise sollte sie so aussehen wie im Fall der firewall oben -- also über 3 Zertifikate gehen

Das root-cert ist doch per default installiert, oder??
DST Root CA X3 ist vorhanden.

Code Select Expand


DST_Root_CA_X3.pem -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt


Am besten mal das cer anschauen in text editor.

Wie meinst du das -- bzw was dann?

Hallo.
Ich habe unsere OPNSense-Firewall so eingerichtet, dass sie über das LE-Plugin Let's Encrypt Zertifikate holt und erneuert. Nun brauchte ich dieses Zertifikat nicht nur auf der FW sondern auch lokal auf einem Server. Daher habe ich alle Dateien unter

"/var/etc/acme-client/home/"

heruntergeladen und lokal verwendet.
Wenn ich nun

Code Select Expand

echo -n | openssl s_client -connect server:443 verwende, erhalte ich

Code Select Expand


CONNECTED(00000005)
depth=0 CN = server.meine-domain.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = server.meine-domain.de
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:CN = server.meine-domain.de
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---

Und ganz unten dann nochmals:

Code Select Expand


Verify return code: 21 (unable to verify the first certificate)


Wenn ich das gleiche auf der Firewall selbst ausführe, ist die Zertifikatskette vollständig. Dort erhalte ich dann die richtige Ausgabe:

Code Select Expand


---
Certificate chain
0 s:CN = firewall.meine-domain.de
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---


Die Frage ist: Warum? Was fehlt da bzw was ist falsch konfiguriert?
Am HAProxy liegt es offenbar nicht, denn wenn der Service ausgeschaltet ist, erscheinen die gleichen Meldungen.
Danke für eine gute Idee!

Ok, ich bin einen Schritt weiter ... habe mit einem anderen Client im WAN versucht, auf die DMZ-Adresse zu gelangen. Da gelingt ebenfalls nicht (wird aber auch nicht gelogged). Daher muss es offenbar daran liegen, dass es weitere Regeln für das WAN geben muss, damit der Zugriff auf die DMZ gelingt?

Ich habe diese Regeln für NAT und WAN eingerichtet -- scheint nicht zu reichen?

[internen]

Hallo.
Ich habe einen HAProxy (später zusammen mit LE geplant) auf unserer OPNSense-FW installiert.

Das Setup sieht so aus:
Unsere Domain "meine-domain.de" wird bei HostEurope gehostet, wo ein CNAME-Eintrag auf einen dyn-dns-Anbieter zeigt. So werden alle Anfragen, die bei *.intern.meine-domain.de ankommen, an die eingetragene dyn-dns-Adresse umgeleitet. Dort hängt zunächst eine FritzBox, die Port 80 und 443 an die WAN-Schnittstelle der OPNSense durchlässt. Auf der FW ist unter NAT eine Portweiterleitung für WAN auf die HAProxy-Adressen gesetzt. HAProxy soll das an einen Rechner in unserer DMZ weiterleiten. Zudem sind FW-Regeln eingetragen, die den Zugriff von WAN --> DMZ erlauben. Soweit der Plan.

Wenn ich nun im internen Netz (also sowohl LAN als auch DMZ) http(s)://nextcloud.intern.meine-domain.de nutze, funktioniert alles. Ein Seitenaufruf geht an die FW bzw HAProxy und wird dann ordnungsgemäß an den Rechner in der DMZ weitergeleitet. Wenn ich das gleiche aber von außen versuche, erhalte ich immer "Unable to retrieve .... Verbindungsaufbau abgelehnt!".
Das kann doch nur eine Kleinigkeit sein, an der das scheitert aber ich sehe den Fehler gerade nicht.
Woran kann das liegen bzw welche Einstellung fehlt hier? Die Liveansicht der FW-Protokolldateien zeigen leider auch kein "Blocked" oder so...

Hi.
I tried to install HAProxy on our OPNSense-FW and found a step-by-step-instruction...
now some things are working while others dont. I cant' find the mistake – maybe one of the wizzzards here?

I have a DMZ with 172.17.17.0/24 and OPNSense on .254
I used two virtual devices: 172.17.17.252 and .253 and as a Test-Server 172.17.17.5 (later for nextcloud)

When I use http(s)://nextcloud2.linux.my-domain.com in my LAN everything works fine. The apache2 answers correctly for Port 80 and 443. So I guess the configuration is ok?

I also already set a CNAME to *.linux.my-domain.com on our external Server (my-domain.com) and a port forwading for 80 and 443 to the WAN-IP of the OPNSense.

So ping nextcloud2.linux.my-domain.com works everywhere.

Nevertheless I can't access the nextcloud-Host behind the Rev.Proxy from my DMZ, WAN or from outside.
Can anyone tell me what's wrong or missing?
DMZ: HTTP/1.1 301 Moved Permanently
WAN: No route to host.

Thanks for a hint.

Code Select Expand


#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    # NOTE: Could be a security issue, but required for some feature.
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket level admin
    nbproc                      1
    nbthread                    1
    tune.ssl.default-dh-param   1024
    spread-checks               0
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log /var/run/log local0 info

defaults
    log     global
    option redispatch -1
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3

# autogenerated entries for ACLs

# autogenerated entries for config in backends/frontends

# autogenerated entries for stats


# Frontend: http_DMZ_WAN (internal and external http)
frontend http_DMZ_WAN
    bind 172.17.17.252:80 name 172.17.17.252:80
    bind 172.17.17.253:80 name 172.17.17.253:80
    mode http
    option http-keep-alive
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options
    # ACL: find_acme_challenge
    acl acl_45e5bfd9525e2e7.18783878 path_beg -i /.well-known/acme-challenge/
    # ACL: Nextcloud_Bedingung
    acl acl_5ebafdd99a40d7.14505678 hdr_end(host) -i nextcloud2.linux.my-domain.com

    # ACTION: redirect_acme_challenges
    use_backend acme_challenge_backend if acl_45e5bfd9525e2e7.18783878
    # ACTION: Nextcloud
    use_backend Nextcloud_Backend if acl_5ebafdd99a40d7.14505678

# Frontend: https_DMZ_WAN (internal and external https)
frontend https_DMZ_WAN
    bind 172.17.17.252:443 name 172.17.17.252:443 ssl  crt-list /tmp/haproxy/ssl/4baf2ad81dea1.61416316.certlist
    bind 172.17.17.253:443 name 172.17.17.253:443 ssl  crt-list /tmp/haproxy/ssl/4baf2ad81dea1.61416316.certlist
    mode http
    option http-keep-alive
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options
    # ACL: Nextcloud_Bedingung
    acl acl_5ebafdd99a40d7.14505678 hdr_end(host) -i nextcloud2.linux.my-domain.com

    # ACTION: Nextcloud
    use_backend Nextcloud_Backend if acl_5ebafdd99a40d7.14505678

# Frontend: https_DMZ (internal https)
frontend https_DMZ
    bind 172.17.17.253:443 name 172.17.17.253:443 ssl  crt-list /tmp/haproxy/ssl/5dbaf62c571809.61471992.certlist
    mode http
    option http-keep-alive
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options

# Backend: Nextcloud_Backend (Nextcloud_Backend)
backend Nextcloud_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    # ACL: not-SSL
    acl acl_5dbaf90c2d38c3.66671068 req.proto_http

    # ACTION: redirect_SSL
    http-request redirect scheme https code 301 if acl_5dbaf90c2d38c3.66671068

    http-reuse safe
    server nextcloud_Host 172.17.17.5:443

# Backend: acme_challenge_backend (Added by Let's Encrypt plugin)
backend acme_challenge_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server acme_challenge_host 127.0.0.1:43580




Ok, dann könnte ich den Unifi-Controller z.B. so abdichten:

Code Select Expand


ufw reject from 172.16.0.0/21 port 22 to 172.16.16.253


Hi. In deinem letzten Satz ist ein typo -- ist so nicht zu verstehen.
Ich frage mich, welches Sicherheitsrisiko größer ist: zusätzliche Route setzen oder Controller einfach in dem WLAN lassen?

Na gut, nehmen wir mal an, ich würde den Controller aus dem Adressbereich, den die Clients bekommen, herausnehmen ...
Im Moment hat der Controller die IP 172.16.16.253,
        die OpnseseFW im WLAN die IP 172.16.16.254
und die Clients erhalten per DHCP (auf OPNSense für dieses Netz aktiviert) den
Bereich 172.16.0.0/21

Nehmen wir mal an, dass der Controller da raus soll und z.B. die IP 10.16.1.4 bekommen soll (eine Adresse im LAN) -- was dann? Würde es reichen, unter OPNSense eine statische Route für 172.16.0.0 -> 10.16.1.4 anzulegen  Welches Gateway?

Also "Routing" ist im Controller selbst nicht aktivierbar, wenn man kein UGS einsetzt. Wir haben einen Layer3-Router von Cisco, der das dann übernehmen müsste -- die einzutragenden Regeln sind mir aber nicht 100%ig klar. Oder meintest  du das so, dass die Route in der OPNSense FW hinzugefügt werden müsste?

Also wir lassen hier mehrere WiFi-Netze mit verschiedenen Aufgaben über die gleichen APs laufen. Eins davon ist für Gäste und funktioniert mit einem Voucher-System. Meines Wissens müssen diese Clients auf die Weboberfläche des Controllers umgleitet werden. Wenn der also in einem anderen Netzwerk ist, finden die Clients ihn nicht ...
Unter normalen Umständen *sollen* die clients natürlich gar nicht auf den Controller zugreifen -- weder per https noch per ssh. Aber mit Voucher bzw Portalseite ist es unumgänglich, fürchte ich?!

hmmm -- dann musst du mir erklären, wie ein Gastportal / Hotspot-Funktion / Captive-Portal von Unifi funktioniert, wenn die Clients nicht auf den Controller zugreifen können??

"der Controller" ist eine VM, auf der der Unifi-Controller läuft -- also die Software, die die AccessPoints steuert. Die läuft (notgedrungen?) im gleichen Netz wie die Accesspoints und die Clients, die sich mit den AccessPoints verbinden. Zumindest ist mir kein Weg bekant, wie/ob man das trennen kann?
Daher wollte ich den AccessPoints aber keinen SSH-Zugriff auf den Controller gewähren.
Ich könnte natürlich eine Software-FW auf dem Controller selbst aktivieren und es dort verbieten -- aber schöner wäre es natürlich, wenn alles zentral an einer Stelle wäre...

Ok, hier alle Regeln ... die erste Regel greift nicht (weder eingehend noch ausgehend) -- ich vermute, weil die FW hier gar nicht im Spiel ist?!


Das WiFi-Netz lautet 172.16.0.0/16

... sehe gerade: Kann es auch sein, dass es mit einer "Anti-Lockout-Regel für SSH"
zusammenhängt? Die dürfte es aber nur im LAN und nicht im WiFi-Netz geben?

Hallo.
Ich habe versucht, eine Regel zu erstellen, die in dem WiFi-Netz den Zugriff per ssh auf den Controller verbieten soll. Diese Regel habe ich bei den Regeln zum WiFi ganz nach oben gesetzt und so angelegt:

Code Select Expand


Ablehnen:
Protokoll      Quelle     Port     Ziel                Port   Gateway Zeitplan Beschreibung
IPv4 TCP/UDP   WiFi-Netz   *       IP des Controllers   22     *      *        ssh Zugriff soll auf Controller verboten sein


Leider greift sie nicht -- ich komme weiterhin per ssh auf den Controller. 
Liegt das daran, dass die IP des Controllers im gleichen Netz liegt? Oder wie muss die Regel richtig lauten?
Eine andere Regel scheint ja weiterhin Vorrang zu haben?
Danke für einen guten Tipp.