OpenVPN-Paket

[ultimatejimmy]

Scheinbar sucht openvpn da was in der Liste der "zurückgezogenen Zertifikate". Kannst du mal die Config rausziehen? Am einfachsten per "Rudi-Shell" indem du dort ein "cat /mod/etc/openvpn.conf" eingibst.

Jörg

 

[MaxMuster]

Auf die Schnelle hilf da ein:
grep -v crl.pem /mod/etc/openvpn.conf > /tmp/openvpn.conf
openvpn --config /tmp/openvpn.conf

Ich schau mir mal an, wie man das dem VPN wieder "abgewöhnen" kann. Die Datei muss vermutlich leer sein (das sollte über die GUI gehen) oder nicht existieren (versuche einfach mal ein rm -f /tmp/flash/crl.pem)..

Jörg

EDIT Es wird geprüft, ob eine lesbare Datei "/tmp/flash/crl.pem" existiert. Die zu löschen (und danach ein "modsave" zum Speichern), sollte also das Problem lösen

 

[ultimatejimmy]

jo geil,

das hat geklappt!

habe
"rm -f /tmp/flash/crl.pem" & "modsave"
ausgeführt, danach restart und schon gings

DANKE

werd heute abend gleich mal alles testen ob mit der bridge all das geht was ich mir vorstelle....


Jimmy

 

[kriegaex]

Moderatoren-Hinweis: Bitte keine Screenshots posten, wenn es Möglichkeiten gibt, den Text stattdessen zu zitieren. In Putty kann man den gesamten Textpuffer (auch die nicht sichtbaren Teile) übers Kontextmenü des Fensters kopieren, in VMware mit VMware Tools (in Stinky vorinstalliert) geht es auch, ansonsten einfach mit SSH oder Telnet zur VM oder zur Fritz!Box verbinden und Texte per Maus oder Menü heraus kopieren. Siehe dazu auch die Hinweise im Beitrag #1 des Release-Threads zu ds26-15.2.

 

[ultimatejimmy]

@Alexander
sorry, werde ich in Zukunft beachten.

@Jörg, all
Kann immer noch nicht auf die Windows Freigabe zugreifen...
IP-Adresse bekomme ich die 192.168.200.4 als VPN Client.

Muss evtl noch das routing aktiviert werden?
da ist bislang im webif nur das "lokale Netz" eingetragen
nicht aber das "entfernte Netz" muss man das explizit eintragen?
und wenn ja was genau? 192.168.200.0 255.255.255.0 funktioniert nicht.

Jimmy

 

[MaxMuster]

Du kannst auf die Freigaben nur über die IP zugreifen (net use x: \\192.168.0.25\c$) oder du erstellst dir auf dem Client-PC eine lmhosts mit einem Namen zur IP)

Als erster Test sollte "net view \\<ip-des-Ziel-PC>" funktionieren.

Jörg

 

[ultimatejimmy]

Du kannst auf die Freigaben nur über die IP zugreifen (net use x: \\192.168.0.25\c$) oder du erstellst dir auf dem Client-PC eine lmhosts mit einem Namen zur IP)

Als erster Test sollte "net view \\<ip-des-Ziel-PC>" funktionieren.

Jörg

Hm sorry,
funktioniert leider nicht mit IP-Adresse.
auf Kommandozeile nach Deiner Anleitung klappt leider auch nichts..
ein ping zu der ip-adresse klappt jedoch!

Jimmy

 

[MaxMuster]

Vermutung: Firewall auf dem "Zielrechner?!?

Jörg

 

[ultimatejimmy]

Vermutung: Firewall auf dem "Zielrechner?!?

Jörg

jap, die windows-eigene..
aber ich dachte mittels bridging befindet man sich "richtig" im internen netz und man hat dieses Firewall Problem nicht..
denn wenn ich wirklich zu hause im internen netz an die dose gehe, sehe ich die windows-freigabe per ip-adresse ohne probleme..
siehe Post von Hermann, seite zuvor..

jimmy :noidea:

 

[MaxMuster]

Zwei Dinge:
1. Ist es denn die Firewall? Also geht es, wenn die aus ist?
2. Das Bridging, was du eingerichtet hast, betrifft im Moment nur die viertuellen Adapter. Erst wenn du diese Brücke an dein LAN bändest, hättest du die besagte Konstellation (und alle "Nachteile" des Bridging). Noch hat dein Client zum einen eine "fremde" IP und ist auch nicht im gleichen "physischen" Netz, was das Bridging simulieren würde.

Jörg

 

[recon]

VPN routing über wlan

kriegaex: diesen und die nächsten zwei Beiträge aus anderem Thema hierher verschoben.

Hallo zusammen
ich habe folgendes problem mit meinem vpn netzwerk (ich hab leider nix über suche gefunden, da es schwer ist die richtige suffixe bei diesem zu finden, also wenn es schon ne antwort gibt, bitte einen verweis darauf )

seite1:
WAN <-> FBF1=7170 (29.04.34ds26-15.2)

seite2:
WAN <-> FBF2=7050 (14.04.33) <-Wlan-Repeater-> FBF3=7141 (40.04.37ds26-15.1)

und zwar habe ich ein bestehendes vpn-tun netzwerk zwischen FBF1 und FBF3 (bekomme auf die FBF2 wegen mangelndem platz und zu großem anspruch der FBF2 keine zusätzliche software drauf).
Von dem an FBF1 über LAN angeschlossenem PC bekomme ich eine vollständige verbindung (http, telnet, etc...) an FBF3, aber nicht an FBF2 sowie jegliche ahgeschlossenen geräten auf seite 2. umgekehrt bekomme ich von seite 2 (Lan an FBF2, und Wlan an FBF3) angeschlossenen geräten auch keine verbindung an seite1 (also nicht auf FBF1 und somit auch nicht an die angeschlossenen geräten). das routing muss ja eigentlich richtig eingestellt sein, sonst könnte ich von seite1 nicht zu seite 2 kontakt aufnehmen können (oder?). aber was ich komisch finde, das von seite1 über wan auf seite2 über FBF2 zu FBF3 weitergeleitet wird, aber von dort nicht mehr zurück
da brauch ich doch irgendwie hilfe bei und freue mich über kontaktaufnahme =)
wenn das problem nicht ordentlich geschildert worden ist, bitte nachhacken, da mich das problem ein wenig nervt und ich das gerne mit eurer hilfe beheben würde...
MfG recon

 

[kriegaex]

Möchtest Du auch verraten, welche Art VPN Du betreibst bzw. mit welcher Software? Falls Du z.B. OpenVPN aus ds26 verwendest, könnte ich Dir anbieten, die Frage in das passende Thema zu verschieben, damit es die erforderliche Aufmerksamkeit erhält.

 

[recon]

Ich benutze das OpenVPN system aus dem ds-mod. daher dachte ich das es hier richtig währe, aber danke fürs verschieben!

kriegaex: erledigt.

 

[MaxMuster]

Also, leider enthält deine Beschreibung alle wichtigen Infos nicht (es ist für "Zugriffsprobleme" eher unwichtig, welche Geräte im Einsatz sind, sondern wie die konfiguriert sind ;-)):
Welche Netze sind wo, wie sind die Konfigurationen, welches Gerät ist in welchem Netz Defaultgateway? Dein Problem ist ganz sicher das Routing, wenn die VPN-Verbindung steht und das VPN-Gateway erreicht werden kann.

Eigentlich ist das ganze vermutlich für jeden lösbar, wenn er sich folgende Frage stellt:

Von welcher IP-Adresse greife ich zu?
Auf welche IP-Adresse greife ich zu?
Welchen Weg werden die Pakete nehmen, immer abhängig von den Routingtabellen der Geräte?
Welchen Weg sollten die Pakete nehmen, also wo fehlen welche Routingeinträge.

Aber wenn du die oben genannten Infos schickst (Netze, Gateways, evtl Routingtabellen), können wir dem "Problem" bestimmt beikommen.

Jörg

 

[hermann72pb]

@recon: Am besten wäre es, wenn du deine OpenVPN-configs posten würdest (als Anhang bitte!). Da du es aber anscheinend per GUI machst, wird es nicht so einfach sein, dann frag es nach.
Zugegeben, es war schwer deine Konfiguration und Motivation zu verstehen. Ich vermute (wenn ich es richtig verstanden habe), dass dein Problem daran liegt, dass bei TUN die route vom server zu client nicht geht. Deswegen frage ich nach configs. Diese route sollte im Server eingetragen werden. Aber wenn wir deine configs sehen, können wir mehr sagen.
Kannst du auch bitte begründen, warum gerade so eine Konfiguration aus den Boxen notwendig ist. Kann man nicht z.B. 7050 und 7141 tauschen? Die andere Möglichkeit wäre den Downloader zu verwenden. In diesem Falle könntest du sogar die Binaries direkt von 7141 "runterladen".

MfG

 

[mr.Mischa]

hi, hab ein kleines problem: wenn ein client auf den vpn server connectet, sieht erstmal alles ganz gut aus. Der Client kann dann aber nur auf den speedport selbst zugreifen und nicht auf die anderen rechner im netzwerk.

configs im anhang...

hoffe ihr könnt mir weiterhelfen
Gruß Mr.Mischa

 

[MaxMuster]

Vermutlich fehlt entweder dem Client die Route in das Servernetz, oder den Rechnern im "Servernetz" fehlt die "Rückroute" zum Client, wenn der Speedport nicht das Defaultgateway in dem Netz ist.

Ansonsten wäre meine Bitte: Etwas genauer beschreiben, was(Ping, "Freigaben"...) von wo nach wohin (IP-Adressen/Netze) nicht geht. Wie sehen die Routingtabellen auf dem Client und auf dem Server aus?

Jörg

EDIT Mal gerade in deine Konfig geschaut (hatte ich erst übersehen):

Sollte eigentlich gehen, es sei denn, die "Rückroute" fehlt (s.o.). mach doch bitte mal einen Traceroute vom Client zu einem der Rechner und einen von einem der Rechner zum Client:

tracert -d 192.168.178.xy   # auf dem Client
tracert -d 192.168.200.2  # auf dem Rechner im Servernetz

 

[mr.Mischa]

also ich muss dazu sagen, dass ich nicht ganz so bewandt auf dem gebiet bin, aber ich kann folgendes dazu sagen:

ich hatte die ip 192.168.178.24, und der client hatte dann die 192.168.200.2 zugewiesen. Der Client konnte auf das webinterface des Speedports zugreifen, sonst aber niemanden anpingen. ich konnte die 192.168.200.2 anpingen, jedoch nicht übers windows netzwerk drauf zugreifen.

jetzt bin ich am ende mit meinem latein...

hoffe, dass sind genug informationen

danke
Gruß Mr. Mischa

edit
vielen dank für die schnelle antwort, kann das ganze wahrscheinlich erst wieder heute abend testen

 

[MaxMuster]

Du willst also quasi vom PC im "Servernetz" auf den Client per Windows-Freigabe zugreifen?

Dann musst du den Zugriff in der Art

net use x: \\192.168.200.2\c$

machen. Die Firewall muss abgeschaltet sein, oder Zugriffe aus dem Netz 192.168.178.x müssen erlaubt werden.

Andersrum gilt das analog (\\192.168.178.24\<Freigabe>) und auch da FW aus oder Zugriffe von 192.168.200.x erlauben

Jörg

 

[MaxMuster]

Neue Version der "neuen GUI"

Hallo zusammen,

mal wieder einen aktuellen Stand der angepassten "neuen" GUI. Das meiste dazu steht ein paar Seiten zurück.
Es sind nur ein paar Fehler rausgeschmissen (erkennung von geänderten Configs) und die Optik etwas "komprimiert".
Die GUI setzt auf die "kommende" OpenVPN Version auf, die nicht mehr zwischen "mit und ohne lzo" unterscheidet. Ein Patch fürs OpenVPN Makefile ist mit dabei, die neue GUI wird über ein fwmod_custom in das Image kopiert.

Wie immer gilt: Jede Rückmeldung ist sehr willkommen!

Jörg

Ergänzung Bitte "sichert" (heißt hier: Abschreiben) eure Einstellungen vorher und ladet dann einmal die "defaults" und tragt die Dinge wieder ein. Hintergrund ist, dass sich das Format und die Defaults geändert haben und das dann doch "sauber" beginnen sollte.

EDIT 20071003 Sorry: Diff für das makefile war irgedwie eine "alte" Version. Neue eingefügt. (Danke an Wonderdoc für den Hinweis)