Posts by mkoehler

Hallo zusammen,

nachdem ich bei der Suche hier im Forum nur ein ähnliches Problem gefunden habe (ping via VPN auf LAN) und die Lösung mir nicht hilft, mache ich jetzt ein neues Thema auf. Falls ich im Forum eine doch schon vorhandene Lösung übersehen haben sollte, bitte ich Nachsicht und Hinweis.

Ich betreibe in dem angehängten Netzwerk LAN_20200706.pdf einen Apache2, auf dem ich Interseiten baue. Und auf dem auch meine eigene läuft (mein Router hat WAN seitig auch eine feste IP). Auf diesem sollen die jeweiligen Subdomains sowohl von draussen erreichbar sein (für meine Kunden während des bauens) als auch von drinnen über den ServerAlias xxx. test.local.

Mein Problem: Von draussen läuft es, aber von drinnen ist test.local nicht erreichbar. Ein Ping von 192.168.0.2 auf 192.168.200.2 erhält keine Antwort. Umgekehrt funktioniert es. Ein nslookup auf 'domain.de' liefert meine WAN IP ,auf 'test.local' liefert die korrekte 192.168.200.2 ab, die auf meinem DNS für test.local hinterlegt ist. Die Inter-Zonen Firewall in der Endian hat Regel für beide Richtungen. Auch wenn ich sie abschalte, das gleiche Bild. Ein tracert für bis zur grünen seite der Firewall, dann nur Sternchen.

Ich könnte natürlich getrennte domain.conf Dateien für drinnen und draussen auf dem Apache anlegen, aber dann muss ich alles doppelt pflegen und ich möchte den Apachen auch nicht gerne auf der LAN seitigen Karte horchen lassen. Bisher kenn der die Karte nicht. Und mit ServerName und ServerAlias müßte ich doch beides über die DMZ Karte laufen lassen können. Oder?

Meine Vermutung ist, das Ping erreicht den Webserver auf 192.168.200.2, findet dann aber den Rückweg nicht. Ist aber nur eine vage Idee.

Meine Routingtabelle: (192.168.120.0 ist übrigens der VPN Proxy)

Hat jemand eine Idee, was die Firewall da tut, das ich übersehe?

Vielen Dank für Eure Hilfe.

Michael

Nachtrag:

Um es noch etwas spannender zu machen:

Ping von 192.168.0.11 (AD Server) auf 192.168.200.2 (Webserver in der DMZ) kommt nicht.

Ping von 192.168.0.11 (AD Server) auf 192.168.200.100 (Firewall DMZ Adapter) kommt.

Ping von 192.168.0.100 (Firewall via SSH) auf 192.168.200.2 (Webserver) kommt.

Also die Endian routet richtig. Und der Webserver anwortet grundsätzlich.

Jetzt bin ich völlig sprachlos.

Hallo allerseits,,

ich bin leider noch nicht weiter.

Ein workaround war der Client. Statt der OPENVPN GUI habe ich eine von SecurePoint verwendet, die hat die fehlende Key Usage Extension in dem Zertifikat nicht bemeckert und die VPN Verbindung aufgebaut.

Das holt mich aber jetzt an anderer Stelle wieder ein, an der ich diese andere GUI nicht verwenden kann.

Ich habe es auch über einen Import meines externen Comodo Zertifikates für meine Domain versucht, dieses ist ein Wildcard Zertifikat und enthält diesen beiden extensions. Und st natürlich CA=TRUE. Aber Endian erkennt dieses nicht als für die firewall CA an.

Es muss doch einen Weg geben, dass das in der Endian Weboberfläche im Reiter Zertifizierungsstelle erstellte CA Zertifikat die Extensions X509v3 Key Usage und X509v3 Extended Key Usage mit erstellt werden.

Hallo wolfili,

danke ersteinmal für Deine Antwort. Es hat leider etwas gedauert, bis ich mich wieder mit dem Thema befassen konnte. Ich habe so viel probiert, dass ich versuchen muss, mich kurz zu fassen.

Zuerst habe ich versucht herauszufinden, woher das Sytsem die Daten für die Zertifikate bezieht. Das war nur teilweise erfolgreich:

1. /etc/ssl/endian-vpn.conf
2. /etc/ssl/openssl.cnf
3. /etc/openvpn/openssl.cnf
4. /usr/lib/ssl/openssl.cnf (scheint für mich ein hardlink auf die /etc/sll/openssl.cnf zu sein)

Darin habe ich einige Dinge gefunden, die mir nicht klar werden wollen.

1. in der openssl.cnf befinden sich Pfadangaben im Bereich [IPCop], die es im System praktisch nicht gibt (z.B. /var/efw/certs). in der endian-vpn.conf sind diese Angaben korrekt.
2. Von den Definitionsbereich [v3_ca] würde ich jetzt mal annehmen, das er die Erstellung der Root- und Serverzertificate bedient, und [usr_cert] die Benutzer-Zertifikate. Was ist dann aber [v3_req]?
3. Ich habe in allen dreien Datein mit den default-Werten in Bereich [req_distinguished_name] gespielt ,bzw. auch mit den Werten in "default_md = sha256" und "default_bits = 2048," und jedesmal wieder neue Zertifikate erstellt, um herauszufinden, welche Änderung in welcher Datei Auswirkungen auf welches Zertifikat hat. Erfolglos. Es gab Ergebnisse, nicht durchgänging und zuverlässig.

Ausserdem ist mir aufgefallen dass:

1. Wenn ich in allen drei Dateien im Bereich [v3_ca] nichts zu "keyusage" angebe, trotzdem das fertige Rootzertifikat dort Daten hat. Es muss also noch eine andere Quelle geben.
2. Wenn ich in allen drei Dateien, sowohl in [v3_req] als auch in [usr_cert], "keyuasge" Einträge mache und ein Benutzerzertifikat erstelle, diese in dem Selben nicht auftauchen.
3. Ich habe versucht, die Zertifikate direkt via Konsole mit openssl zu erstellen und mit der Endian GUI zu importieren. Mit dem Ergebniss, dass Endian dann behauptet, keine CA-Zertifikate zu haben. (kann das vllt. etwas mit der Datei "serial" zu tun haben? Nur so ein Gedanke. Oder sonst irgendeinem Index). Das bemekrenswerte daran ist aber, wenn ich mir diese mit openssl erstellen Zertifikate ansehe, ist keyusage bei allen korrekt ausgefüllt. Aber Endian will sie nicht.
4. Ich habe von Comodo für mein OWA und meine Website ein externes Wildcard Zertifikat und habe auch das importiert:

Das externe CA, die Intermediates und mein Domainzertifikat werden in den Listen der Zertifikate in der GUI angezeigt. Endian erkennt sie aber nicht als verwendbare CAs an.

Das externe Zertifikat für meine Domain kann ich dann aber trotdem dem VPN-Server zuordnen. Hilft nur nicht, weil so keine Benutzerzertifikate erstellen kann, weil Endian eben meldet, es gibt kein root-Zertifikat.

Ich weiss, ich habe jetzt wohl eine ganze Menge Zeug durcheinander auf den Tisch gekippt, ich hoffe damit niemanden zu verärgern. Aber nach der vielen (durchaus systematischen, auch wenn das hier jetzt nicht so aussehen mag) Probiererei ohne irgendein belastbares Ergebnis werde ich selber langsam weich im Hirn.

Grundsätzlich beschäftigen mich unverändert diese zwei Fragen:

1. Warum liefert mir eine saubere Neuinstallation der Version 3.3.0 ein Benutzerzertifikat, das auf dem Clientrechner von der OpenSSL-GUI mit der Meldung "das Zertifikat hat keine keyusage-extension" abgelehnt wird?
2. Wie sind die Zusammenhänge zwischen der Endian, Openvpn, OpenSSL und den Konfigurationsdateien? Ich würde das gerne bis ins letzte verstehen.

Es wäre schön, wenn jemand an der einen oder anderen Stelle etwas Licht in mein Wirrwar bringen könnte. Ich hangel mich dann Stück für Stück weiter.

Vorab schon einmal vielen lieben Dank.

1. etc_ssl_endian-vpn.conf.pdf
2. etc_ssl_openssl.cnf.pdf
3. etc_openssl_openssl.cnf.pdf
4. Endian_Benutzerzertifikat.txt
5. Endian_VPN-Server.txt
6. Endian_CA.txt

Hallo, schönen guten Tag,

ich verwende die efw schon eine gefühlte Ewigkeit und habe bisher alle Probleme in den Griff bekommen, aber jetzt stecke ich fest und wäre dankbar für hilfreiche Hinweise. Folgendes Problem:

Wenn ich von meinem Windows 7 Laptop mit dem aktuellen OpenVPN Client (11.10.0.0) auf mein Netzwerk zugreifen möchte, verweigert dieser die Verbindung mit dem Hinweis auf eine fehlende keyUsage Extension im Zertifikat. Ich habe:

1. Das CA Zertifikat über die Oberfläche der efw erstellt und als cacert.pem exportiert. Siehe Anhang.
2. Den Benutzer mkoehler eingerichtet.
3. Dabei für den Benutzer das Zertifikat erstellt (ebenfalls über die Oberfläche) und exportiert als mkoehlercert.p12
4. Die mkoehlercert.p12 mit Openssl-WIN64 in eine .crt und .key Datei auseinander genommen
   1. pkcs12 -in mkoehlercert.p12 -clcerts -nokeys -out mkoehler.crt
   2. pkcs12 -in mkoehlercert.p12 -nocerts -out mkoehler.key
5. Diese beiden Dateien und die cacert.pem auf den Laptop in den Ordner Benutzerprofil\OpenVPN\config verfrachtet.

Wenn ich den Laptop jetzt verbinde, beschert mir der OpenVPN Client folgende Fehlermeldung:

Certificate does not have key usage extension

Bei den anschließenden Google-Suchen bin ich verschiedenen Hinweisen gefolgt, die in verschiedenen Ausprägungen im Kern das Selbe sagten. gehe per SSH auf die Firewall und ergänze die /etc/openvpn/opendssl.cnf um

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

extendedKeyUsage = serverAuth, clientAuth, codeSigning, emailProtection

Beides brachte leider keine Veränderung. Hier die kompletten Dateien:

cacert.txt

mkoehler_crt.txt

mkoehler_logfile.txt

mkoehler_ovpn.txt

openssl.txt

Die Updates der efw sind natürlich aktuell installiert. Habe ich noch Information vergessen?

Ich hatte den OpenVPN Server mit einer viel älteren Version vor einigen Jahren schon mal in Betrieb, da hat alles funktioniert.

Hat jemand eine Idee, in welcher Richtung in den Fehler noch suchen könnte?

Vielen Dank