Hi,
danke für die Rückmeldung. Hast Du auch Erfahrung bezüglich der Virtualisierung der 3.0 auf XenServer? Welche Modifikationen müssen dafür gemacht werden?
Gruß
Arno
Beiträge von arno.filter
-
-
Hi,
hat jemand von Euch schon die Community Version der EFW 3.0 virtualisiert (in vergleichbarer Art wie die kommerzielle Version)? Oder anders gefragt gibt es bereits ein HowTo wie man die EFW 3.0 Community als Virtual Appliance aufsetzt?
Gruß
Arno -
Hi EFW-Community,
ich habe heute das OpenVPN meiner EFW in Betrieb genommen, was Dank dieses Beitrags von devaux (https://www.efw-forum.de/www/forum/view…hp?f=9&t=66) auch gut funktioniert hat. Lediglich das Verwirrspiel bzgl. der Passwörter und der Bug das der DNS nicht übergeben wird haben etwas genervt.
So jetzt würde ich gerne die two factor authentication mit X.509 certificate und PSK (also Benutzer- und Passwortabfrage) zum laufen bekommen. Leider bin ich dazu irgendwie zu blöd. Ich scheitere schon daran, dass ich nicht genau weiß wie die conf.ovpn dafür aussehen sollte. Hier ist das was ich probiert habe:
Code
Alles anzeigenclient dev tap proto udp remote xxxxxx.dyndns.org resolv-retry infinite nobind persist-key persist-tun verb 3 comp-lzo auth-user-pass # Damit erfolgt die User und Password Abfrage pkcs12 alcedo.p12 # Client Key ca ca.crt # Server Certificate ns-cert-type server
Das Hauptverständnisproblem für mich ist, dass ich nicht genau weiß welche Zertifikate hierfür gebraucht werden. Brauche ich das Zertifikat der EFW, das auch sonst für die PSK-Authentifizierung genutzt wird? Oder brauche ich dafür das Zertifikat, welches beim Erstellen des Client-Keys verwendet wurde und wenn ja welches?
Ich hoffe jemand von Euch hat das auch schon mal versucht und kann mir hier weiterhelfen.
Gruß
Arno -
Hi Dave,
wie baust Du denn die VPN-Verbindung auf? Es gibt nämlich das Problem, dass bei der ausschließlichen Verwendung von X.509 Zertifikaten der DNS-Server nicht übergeben wird (vgl. Endian Issue Tracker ID 0002682). Ich habe bei mir mit der Version 2.4.1 das dort beschriebene Problem leider immer noch. Allerdings funktioniert der dort beschriebene Workarround:
Du musst einen User mit dem Namen DEFAULT anlegen und in diesem Account unter der Custom push configuration explizit DNS und Domain angeben. Wichtig ist dann, dass Du beim Client routing das Häckchen bei Push only global options to this client weg lässt (denn diese werden ja leider wegen des Bugs nicht übergeben).
Bei mir hat das so funktioniert.
Gruß
Arno -
Hi nic-moe,
ich hatte ein ähnliches Problem. Schau Dir mal meinen Beitrag zu dem folgenden Tip an, der sollte Dein Problem lösen:
Foren-Übersicht > Tips,Tricks, HowTo´s > Tips, Links > x.509 Zertifikate erstellen
https://www.efw-forum.de/www/forum/view…mp;p=7228#p7228Gruß
Arno -
Zitat von "horst"
Frage:
Das gleiche Problem habe ich auch. Ich habe das Zertifikat unter Windows XP erstellt. Das Zertifikat scheint ok (ist größer als 0KB). Das Kennwort habe ich auf "123456" gesetzt (also keine Zeichen die Probleme machen könnten. Wofür ist eingetlich dieses "Export-Passwort" nachdem zum Schluss der Zertifikaterstellung gefragt wird? Das Challange-Passwort wird ja vorher auch schon abgefragt!?Hi!
Ich hatte bei mir genau das gleiche Problem. Nach einigem Rumprobieren habe ich jetzt folgendes herausgefunden:
- Auf der Web-Oberfläche der EFW steht zwar beim Import der p12-Datei "Challenge Password", tatsächlich muss man aber das "Export Password" eingeben (ich habe einfach mal verschiedene Kombinationen von Passwörtern probiert, bis ich bei diesem Punkt war). Aus meiner Sicht ist das ganz klar ein Bug in der EFW-GUI.
- Wenn man beim Client-Key Passwörter angibt (für Challenge und Export), dann wird beim Aufbau der VPN-Verbindung nach auch dem "Export Password" gefragt.Mich hat dieses Verwirrspiel auch ziemlich genervt. Deswegen habe ich im Netz nach ergänzenden Infos gesucht. Zum "Challenge Password" habe ich in einem anderen Forum folgende Erklärung gefunden:
This is a password that will be placed into the request that is being generated. The idea is that it may be used to verify the identity of the requestor at a later time when the certificate is being returned to him.In dem ein oder anderen Beitrag von anderen Foren wurde auch beschrieben, dass das "Challenge Password" wieder abgefragt wird wenn man es angibt, z.B. beim Aufbau der VPN-Verbindung oder beim Neustart des VPN-Servers. Allerdings habe ich den Eindruck, dass das nicht stimmt sondern immer nach dem "Export Password" gefragt wird (was entsprechend der Beschreibung bezüglich des "Challenge Password" auch passen würde).
Gruß
Arno -
Hallo Community,
die Anmerkungen von aender haben mich auf eine für mich neue Spur geführt. Das Problem des Multicastings besteht wohl auch bei IPTV. Es gibt ein paar Einträge hier im Forum, die sich damit auseinandersetzen. Dort sieht es so aus, als könnte das Problem mit ein paar manuellen Eingriffen in die iptables und der Installation eines IPMG-Proxys gelöst werden.
Bevor ich jetzt anfange zusätzlichen Code auf der EFW zu installieren und manuell in die iptables einzugreifen hätte ich gerne von Euch ein paar Hinweise ob dieser Weg überhaupt funktionieren kann.
Hat denn wirklch niemand bisher Erfahrung mit der von mir beschriebenen Konstellation?? Dabei dachte ich, dass das eigentlich die Regel sein müsste (Media-Server in Green und mobiler Media-Client in Blue) ...
Gruß
Arno -
Hi Aender,
danke für den Hinweis! Aber ganz so einfach gebe ich noch nicht auf!!
Bei meinem WLAN Acesspoint WRVS4400N von Linksys gibt es beispielsweise die Möglichkeit "Multicast Passthrough" in den Einstellungen der Firewall zu aktivieren. Vielleicht liege ich falsch, aber daraus schließe ich, dass es für mein Problem eine Lösung geben muss. Ich finde auch immer wieder Hinweise in anderen Foren darauf, dass so etwas mit anderen Firewalls bereits umgesetzt wurde (leider ist mir der Transfer auf meine Konfiguration bisher nicht gelungen).
Also im ersten Schritt muss ich erstmal den Hinweg schaffen. Von meiner Green Zone (192.168.1.0/24) über die EFW zur Blue Zone (192.168.2.0/24) und dann über den Acesspoint ins WLAN.
Gruß
Arno -
Hi Aender,
ja in Artikeln zu UPnP oder auch der Anleitung zum Twonky-Server wird hier und da mal geschrieben, dass das für Geräte im gleichen Netzwerk funktioniert. Ich habe aber noch nichts darüber gelesen, dass es über Netzwerke hinweg auf keinen Fall geht. Ich dachte, dass das mittels Routing und NAT eigentlich machbar sein sollte.
In der Twonky-App auf dem iPod lässt sich leider keine IP oder Hostname angeben. Die App scheint ausschließlich auf den Multicast der DLNAs zu höhren (ohne entsprechende Weiterleitung kommt der natrülich bei Blue nicht an).
Das W-LAN in die ZONE Green zu integrieten funktioniert natürlich. Aber das Grundkonzept der EFW sieht ja die Trennung vor (LAN: Green, W-LAN: Blue) an der ich auch festhalten möchte.
Gruß
Arno -
Hallo EFW-Community,
ich versuche jetzt schon seit einiger Zeit mit verschiedenen Einstellungen den Zugriff von meinem iPod (Zone Blue) auf den unter Windows laufenden Twonky-Server (Zone Green) zu realisieren, leider bisher ohne Erfolg. Folgendes habe ich schon probiert:Static Routing:
source network: 192.168.1.0/24 (Green)
destination network: 192.168.2.0/24 (Blue)
gateway: 192.168.1.1NAT in verschiedenen Varianten
Der Zugriff auf das Web-Interface des Twonky-Server funktioniert aus dem W-LAN. Aber die Twonky App auf dem iPod oder auch der Mediaplayer auf dem Windows Laptop finden den Twonky-Server nicht als Medienbibliothek (UPNP DLNA). Leider ist für mich aus den Log-Dateien der EFW nicht ersichtlich an welcher Stelle die Verbindung nicht funktioniert.
Hat jemand von Euch Erfahrung mit einer solchen Konfiguration?
Gruß
Arno -
Hallo,
super Beitrag! Ich hatte genau das gleiche Problem und mir schon fast einen Wolf gesucht um das Problem zu lösen. Der beschriebene Eintrag einer SNAT-Regel hat auch bei mir funktioniert.
Gruß
Arno