Beiträge von moppel

Hallo,

das OpenVPN-Paket bringt (unter Windows) bereits eine Lösung zum Erstellen der X509-Zertifikate mit, die unter den meisten Linux-Distros auch schon vorhanden ist: OpenSSL. Dafür gibt es ein relativ übersichtliches HowTo auch auf der Seite von OpenVPN http://openvpn.net/howto.html#pki. Das einzige, was dabei nicht passt, ist die Tatsache, dass efw standardmäßig dedizierte Client-Zertifikate vom Klienten verlangt, die mit dem OpenVPN-Standard nicht erstellt werden. Die Lösung dafür findest Du aber auch in diesem Forum unter https://www.efw-forum.de/www/forum/view…hp?f=7&t=61.

Zum Hintergrund: Du benötigst nicht einfach nur ein X509-Zertifikat. Dieses muss zumindest von einer gültigen CA ("Zertifikat-Autorität") signiert sein und sollte für die Verwendung mit der efw auch bestimmten Typen entsprechen. Ich weiß nicht mehr, inwiefern selfcert eine CA-Signierung mitbringt und daher ggf. nutzbar wäre, aber mithilfe von OpenSSL kann man innerhalb kürzester Zeit eine eigene CA generieren und Server- und Client-Zertifikate erstellen, ohne dafür Zertifikate bei echten CA's zu ordern...

Da ist zwar ein bisschen Einarbeitung erforderlich, aber danach kannst Du die Zertifikate mit gutem Gewissen als sicher ansehen (wenn Du diese nicht unsachgemäß behandelst, also nicht über ungesicherte Verbindungen verteilst, wie http, ftp, o.ä.).

Gruß,
Andreas

Hallo,

sorry, ich hatte vergessen, das der Typ Client nicht im Standard von OpenVPN vorgesehen war. :oops: Für diese Lösung muss also außer den oben genannten Änderungen noch der folgende Code in die openssl.cnf eingefügt werden:

[ client ]
# JY ADDED -- Make a cert with nsCertType set to "client"
basicConstraints=CA:FALSE
nsCertType                      = client
nsComment                       = "OpenSSL Generated Client Certificate"

Dieser Absatz definiert überhaupt erst die extension "client" und daraus holt sich OpenSSL auch die Rahmenbedingungen für den gewünschten Typ. Ich habe die Erweiterung direkt nach dem Block "[ server ]" eingefügt und vor dem Block "[ v3_req ]":

...
[ server  ]
# JY ADDED -- Make a cert with nsCertType set to "server"
basicConstraints=CA:FALSE
nsCertType			= server
nsComment			= "OpenSSL Generated Server Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always


[ client ]
# JY ADDED -- Make a cert with nsCertType set to "client"
basicConstraints=CA:FALSE
nsCertType                      = client
nsComment                       = "OpenSSL Generated Client Certificate"


[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
...

Der Rest sollte dann eigentlich wieder wie gewohnt funktionieren.

Gruß,
Andreas

Hallo,

hast Du das Problem schon lösen können?

Ich könnte mir vorstellen, dass man das ggf. über die Inter-Zonen-Firewallregeln lösen könnte. Zuerst müsste den VPN-Clients eine feste IP zugeordnet werden, die dann auch als Ident. dienen könnte. Anschließend müsste für die Gruppe der VPN-IP-Adressen eine Regel zum Erlauben des Zugriffs auf FTP BLAU generiert werden und letztendlich eine, die jeden weiteren unerwünschten Verkehr für diese Gruppe von Adressen verbietet. Ist jetzt nur so eine Idee, die erstmal überprüft werden müsste, aber vielleicht hilft's ja ein wenig...^^

Gruß
Andreas

Hallo,

die Zertifikate können mit bestimmten Optionen generiert werden (ns-cert-type = Netscape-Zertifikattyp). Das CA- oder Server-Zertifikat wird meines Wissens in den OpenVPN-Standard-Skripten auch mit ns-cert-type=server generiert. Der Zertifikattyp wird optional beim Signieren der Zert.-Anforderung durch die CA angegeben. In der Praxis könnte das dann so aussehen (hier meine, von den OpenVPN-Skripten adaptierte Variante), das Skript heißt build-client-key:

#!/bin/sh


# Variablen initialisieren
. vars


cd $KEY_DIR


if ! [ -f index.txt -o -f serial ]
then
  echo "
CA-Datenbank ggf. korrupt. Werde index.txt und serial zuruecksetzen
"
  echo -n > index.txt
  echo 01 > serial
fi


echo "
Client-Zertifikat $1 generieren
"
openssl req -days 3650 -nodes -new -keyout ${1}.key -out ${1}.csr -config $KEY_CONFIG       # Zertifikat-Anforderung generieren
openssl ca -extensions client -days 3650 -out ${1}.crt -in ${1}.csr -config $KEY_CONFIG     # Anforderung signieren
openssl pkcs12 -export -inkey ${1}.key -in ${1}.crt -certfile ca.crt -out ${1}.p12          # Zertifikat als PKCS12 exportieren

Damit werden dedizierte Client-Zertifikate generiert, die der Anforderung ns-cert-type=client gerecht werden. Wichtig ist dafür bei der Signierung (openssl ca) die Angabe des Parameters "-extensions client".

Zu Deiner anderen Frage: Die Konfigurationen der efw werden in anderen Dateien gespeichert, als dort, wo sie nach Aktivierung der entsprechenden Dienste zu finden sind. D.h., nahezu jeder Dienst-Neustart (durch Aktivierung oder geänderte Konfiguration) führt dazu, dass die Konfigurationsdateien (z.B. /etc/openvpn/openvpn.conf) erneut geschrieben werden. Dadurch gehen händische Änderungen daran verloren. Es gibt zwar Mittel und Wege, auch diese händischen Eingriffe dauerhaft zu hinterlassen, aber in diesem Fall halte ich es für sinnvoller, einfach dedizierte Client-Zertifikate zu erstellen und gut iss...

Wenn Du näheres wissen möchtest, könnte Dir eine Suche in den Support-Foren nach Hinweisen zu /var/efw/inithooks helfen. Darin befinden sich Dateien, die Anpassungen für diverse Events (Neustart, Konfigurationsänderungen, u.ä.) enthalten können, und die nicht durch Upgrades überschrieben werden. Ich beziehe mich zwar gerade auf einen Artikel, der Firewall-Regeln betrifft, aber vielleicht ist das ja ein Ansatz. http://kb.endian.com/entry/27/

Gruß,
Andreas

Hallo,

leider besteht das Problem immernoch. Die Pakete gehen lt. Wireshark auf jeden Fall auf/über die Ports UDP 67 (Server) & UDP 68 (Client). Ob vielleicht noch andere Ports genutzt werden, kann ich nicht ausschließen, weil der Netzwerk-Traffic bei mehreren Windows-Clients im Netzwerk dermaßen unübersichtlich ist, dass ich nur die Kommunikation über die Standard-Ports genauer betrachtet habe (Lt. IANA.ORG: 67 & 68 jeweils TCP und UDP). Es finden sich auf diesen Ports alle DHCP-Pakete (Release, Discover, Request, Offer, Inform, Ack...), weshalb ich davon ausgehe, dass nur diese benutzt werden.

Ich befürchte mittlerweile, dass es hier nicht ohne weiteres möglich ist, die Pakete adequat auszufiltern, würde mich aber freuen, wenn mir doch noch ein Weg aufgezeigt werden könnte...

Gruß
Andreas

Hallo nochmal,

die Funktionsweise der iptables-Ketten habe ich jetzt glaube ich durchschaut. :? Trotzdem werden DHCP-Request-Pakete offensichtlich immernoch weitergeleitet, obwohl sie im efw-Log eindeutig als -je nach Einstellung- INPUTFW:DROP oder VPNFW:DROP zu finden sind. Auch die Zähler (iptables -L -v) deuten daraufhin, dass die Regeln greifen. Aber der efw-DHCP-Server antwortet nach wie vor. Auch die folgende (ausgehende) Regel war nicht von Erfolg gekrönt (auch nicht mit DROP als Sprungziel):

iptables -I OPENVPNDHCP -v -m physdev --physdev-out tap1 -p tcp --sport 68 --dport 67 -j REJECT
iptables -I OPENVPNDHCP -v -m physdev --physdev-out tap1 -p udp --sport 68 --dport 67 -j REJECT

Nutzt der Server vielleicht doch direkt das tap-Interface obwohl er nur für die Brücke br0 gestartet ist?

Ich hoffe auf frische Ideen, meine sind zur Zeit ausgeschöpft...

Also denn, nochmal 'n guten Rutsch!

Hallo,

wir haben ein Problem bei einer mittels OpenVPN realisierten Ethernet-Brücke. Ich würde mich freuen, wenn mir jemand mit dem Zaunpfahl winken könnte. :oops:

Client-Netzwerk                                                                                         Server-Netzwerk
        ------------+                                                                                           +------------
                    I            +-----------+          +-------------+           +-----------------+           I
        ------------#------------# FRITZ!Box #-.-.-.-.-.#   Router    #-----------#       efw       #-----------#------------
                    I            +-----------+          +-------------+           +-----------------+           I
        ------------+                                                            RED              GREEN         +------------
    192.168.15.65-99/24    192.168.15.64     ((INTERNET))    192.168.12.1   192.168.12.9     192.168.15.1     192.168.15.2-64/24

Der Server läuft auf einer "Endian Firewall Community release 2.2.rc3" und der Client auf einem Router (FRITZ!Box - "OpenVPN 2.1_rc2 mipsel-linux"). Die Verbindung an sich ist in Ordnung, was ja auch schon das Problem ist: DHCP-Clients aus dem Client-Netzwerk erhalten z.T. ihre IP-Konfiguration oder auch nur DHCP-Optionen wie die DNS-Server aus dem Server-Netzwerk. Sobald der Tunnel dann nicht mehr steht (wg. DSL-Problemen auf Server-Seite leider recht häufig), gehen sämtliche DNS-Anfragen ins Leere.

Auf 'ner älteren efw hatte ich das mal per iptables gelöst, aber ich besitze die Doku dazu leider nicht mehr. Ich habe die Regel bereits in verschiedensten Ketten (z.B. OPENVPNDHCP, INPUT, INPUTFW, etc.) ausprobiert, aber der DHCP-Server antwortet immernoch wie zuvor.

iptables -I $CHAIN -p udp --sport 67:68 --dport 67:68 -m physdev --physdev-in tap1 -j DROP

Eigentlich sollte das ja nicht passieren, weil der Request "gedropped" werden soll. Wo erfahre ich, in welcher Reihenfolge die zahlreichen Ketten abgearbeitet werden, oder in welcher Kette müsste die Regel greifen?

Ich habe auch mal versucht, den DHCP-Server der efw durch die benutzerdefinierten Konfigurationszeilen dazu zu überreden, den DHCP-Clients im Client-Netz ihre passende Konfiguration zu senden, was zu bizarren Ergebnissen führte: Das DHCPOFFER-Paket kam zwar mit den untenstehenden (richtigen) Optionen, der DHCPACK kam dann aber mit den falschen.

group brdg-clnt {
        host host1 {
                hardware ethernet 00:11:22:33:44:55;
                fixed-address     192.168.15.65;
        }
        host host2 {
                hardware ethernet 00:66:77:88:99:AA;
                fixed-address     192.168.15.66;
        }
        option subnet-mask 255.255.255.0;
        option domain-name "our-net.local";
        option routers 192.168.15.64;
        option domain-name-servers 192.168.15.64;
        option ntp-servers 192.168.15.64;
        default-lease-time 864000;
        max-lease-time 1123200;
}

Versuch macht halt kluch... Ich möchte die Konfiguration des efw-DHCP-Servers jetzt aber ungerne komplett händisch erstellen. Mir wäre es eh am liebsten, wenn das ganze wieder wie zuvor über die Firewall geregelt werden könnte.

Vielen Dank schonmal im Voraus und 'n guten Rutsch...