Quick status update as I got some progress in the mean time:
- tunnel over TCP functioning well
- pushing routes towards client works however after 10 seconds they disappear from the Windows routing table. This caused the ping to both server IP pool as well as local LAN to fail.
- for the moment I implemented a workaround: added a batch file configuring these routes again 20s later.
- still need to look for the actual trigger such that workaround can be removed.
In fact I do suspect the Firewall agent on my portable as this also blocked the UDP port, which made me decide to move to TCP (not being able to tune the firewall config).
Best regards, Sammy
Ankündigung
Einklappen
Keine Ankündigung bisher.
Wiregate und VPN
Einklappen
Dieses Thema ist geschlossen.
X
X
-
Any news on this?
If it still doesn't work yet please post the complete config and I'll try to reproduce..
Makki
Einen Kommentar schreiben:
-
Hmm, honestly, I never tried with TCP (usually you really want to use UDP here, theres no benefit from TCP here as openvpn handles everything on upper layers!)
Remainder looks fine, I attached a screenshot on how the push route should look like. Otherwise it might really make sense to give the client from openvpn.net a try.
MakkiAngehängte Dateien
Einen Kommentar schreiben:
-
VPN server not reachable
Hi,
I'm re-using this thread to report a Wiregate VPN issue.
After configuring the VPN server I managed to get the VPN connection established however the client is not able to ping VPN server nor any other device connected in the LAN.
All configurations are left default, except following changes:
- VPN connection over TCP iso UDP
- added following optional line to server cfg push "route 192.168.1.0 255.255.255.0"
In the client log I see that server reports successful tunnel establishment, however in the last part it seems to go wrong:
Thu Sep 09 21:21:23 2010 [server] Peer Connection Initiated with 91.182.109.120:1194
Thu Sep 09 21:21:24 2010 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:2: topology (2.0.9)
Thu Sep 09 21:21:24 2010 TAP-WIN32 device [Local Area Connection 7] opened: \\.\Global\{23EB17D4-2F7B-4727-8616-01B8656838F3}.tap
Thu Sep 09 21:21:24 2010 TAP-Win32 MTU=1500
Thu Sep 09 21:21:24 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.24.254.6/255.255.255.252 on interface {23EB17D4-2F7B-4727-8616-01B8656838F3} [DHCP-serv: 172.24.254.5, lease-time: 31536000]
Thu Sep 09 21:21:24 2010 Successful ARP Flush on interface [4] {23EB17D4-2F7B-4727-8616-01B8656838F3}
Thu Sep 09 21:21:24 2010 Initialization Sequence Completed
Thu Sep 09 21:50:01 2010 TCP/UDP: Closing socket
Thu Sep 09 21:50:01 2010 ROUTE: route deletion failed using DeleteIpForwardEntry: The parameter is incorrect.
Thu Sep 09 21:50:01 2010 Closing TUN/TAP interface
Thu Sep 09 21:50:01 2010 SIGTERM[hard,] received, process exiting
-> could there be something wrong with the push command and consequently the route creation at client side?
Or is the route on the LAN router insufficient/wrong?
Note that the OpenVPN FAQ refers to a possible old client version incompatibility with newer servers supporting the --topology option -> could this be the case here?
The client has been installed right from the Wiregate VPN configuration page, I've consequently got an old v1.0.3.
Some more background:
- LAN router: 192.168.1.1
- VPN server LAN IP@: 192.168.1.6
- client IP@ range: 172.24.254.0
- VPN client IP@: 172.24.254.6
- static route added on LAN router with destination 172.24.254.0 mask 255.255.255.0 gtw 192.168.1.6
Any idea what could be wrong?
Thanks for your help, Sammy
Einen Kommentar schreiben:
-
Das ist sicherlich eine sehr weise Einsicht, die ich allerdings keinem aufzwängen möchteZitat von Jockel Beitrag anzeigenSelbst möchte ich mich an einen sicherheitsrelevanten Bereich nicht mal so eben nebenher heranbegeben...
Jeder könnte und soll dürfen..
Mit Verlaub, VPNs, insb. IPSec sind halt seit rund 11J unser Kerngeschäft, verglichen damit habe ich von GA/HA bis heute "garkeine Ahnung".
Das miit dem lieben IPSec ist sicher nicht trivial, es kann sich jeder mit einem WireGate oder einem beliebigen Linux aber "machen". Risiken und Nebenwirkungen gibts natürlich, diese oder die Anleitung dazu lassen sich aber nicht mit 50 Zeilen beschreiben.
Daher ist OpenVPN (prinzipiell sehr viel einfacher im Handling als IPSec) in "schön" drin und der Rest, naja, IPSec ist bestimmt das "richtigste" aber eben auch der worst-case was die Komplexität angeht (zumindest wenn man es richtig macht, so mit CA usw.)
Makki
Einen Kommentar schreiben:
-
Früher wäre das für mich keine Frage gewesen, da hätte ich das auf meinem Linux Server selbst eingerichtet. Inzwischen hab ich zwar immer noch Spaß an solchen Sachen, leider fehlt mir aber die Zeit. Genau deswegen hab ich ja auch ein Wiregate gekauft und mich nicht selbst damit beschäftigt ;-) - war die richtige Entscheidung.Da nun zum Ziel zu kommen bedarf entweder ein bisschen Eigeninitiave oder ansonsten sind wir für Sonderlocken auch käuflich
Gerade IPSec ist ja nicht wirklich trivial, hab mir das vor ein paar Jahren mal angeschaut. Daher wäre mir die Variante "Kiste kaufen und glücklich sein", selbst wenn es ein paar EUR werden, eigentlich am liebsten. OK, vierstellig sollte es dann auch nicht unbedingt werden.
Wenn ich da nichts finden sollte, komme ich aber ggf. auf das Angebot zurück! Selbst möchte ich mich an einen sicherheitsrelevanten Bereich nicht mal so eben nebenher heranbegeben...
Einen Kommentar schreiben:
-
iPhone: m.W. (sagte man mir) geht OpenVPN nur mit Jailbreak..
Mögliche Varianten:
1) Reverse-SSL-Proxy (geht natürlich nur für interne Webseiten, Visu, Kamera usw)
2) IPSec geht natürlich auf dem WireGate auch
3) PPTP o.ä. dito (IMHO nicht Mittel der Wahl weil einfach grundlegende Sicherheitsprobleme bestehen)
All das aber nicht so "Plug&Play".. Naja, IPSec auf einem Router einzurichten ist gewöhnlich auch so nicht PnP
zu 1: Haben wir schonmal Tests mit Helmut und iPhone gemacht, läuft dann mit Apache, geht. Die Einrichtung erfordert aber einiges an Details, kommt im Einzelfall drauf an..
zu 2: Gibt es sogar ein Webmin-Frontend (als root), was das Frontend taugt weiss ich nicht..
Da nun zum Ziel zu kommen bedarf entweder ein bisschen Eigeninitiave oder ansonsten sind wir für Sonderlocken auch käuflich
4) Cisco hinstellen, der kann auch IPSec (gibts natürlich noch ne Menge andere Router, kenne ich aber nicht/kaum)
Makki
Einen Kommentar schreiben:
-
Mal eine Frage: Wenn ich es richtig sehe, hab ich mit dem iPhone beim Zugriff auf einen OpenVPN Server ja schlechte Karten, oder gibt es da inzwischen eine Lösung?
Vielleicht habt Ihr ja ersatzweise eine Empfehlung für einen Router der IPSec macht den ich als eigenständiges VPN-Gateway verwenden kann (hätte das gerne von meinem Internetrouter getrennt).
Einen Kommentar schreiben:
-
Der VPN-Server startet nunmehr automatisch und es wird auch überwacht, das er läuft (ist von Haus aus so, falls aktiviert, wenn er denn mal läuft)
Makki
Einen Kommentar schreiben:
-
Danke, jetzt geht es. Startet der openvpn-server jetzt beim booten automatisch oder muss ich ihn manuell starten
Ich hatte da auch schon zwei Einträge gesehen. Sieht jetzt so aus, als wenn sich openvpn alleine beendet ?
Gruß Micha
Einen Kommentar schreiben:
-
Nee, sorry, tat er leider nicht.. Das ist nur das Wartungs-VPN, wenn beides aktiviert ist, müssen da zwei stehen.Zitat von Micha Beitrag anzeigen- openvpn Server läuft (LED ist grün)
Die Ursache hätte man im Log gesehen (Zugriffsrechte auf die Keys), ich hab das - nachdems eh an war - via Wartungs-VPN jetzt mal vorab gefixed, sollte jetzt gehen.
Da ist irgendwo noch der Wurm drin, ich sehe mal zu das mit dem nächsten Update endgültig in den Griff zu bekommen
..und die Ampel und eine Loganzeige..
Makki
Einen Kommentar schreiben:
-
- openvpn Server läuft (LED ist grün)
nobody 27899 1 0 Jun23 ? 00:00:25 /usr/sbin/openvpn --writepid /var/run/openvpn.wiregate-central.pid --daemon ovpn-wiregate-central --status /var/run/openvpn.wiregate-central.status 10 --cd /etc/openvpn --config /etc/openvpn/wiregate-central.conf
- IP 91.15.59.14 ist die aufgelöste dyndns Adresse / stimmt auch !
- Portforwarding ist eingerichtet 1194 an lokale IP Wiregate
Aber Fehlerlog bleibt so
Das WG ist über Port 10000 von außen erreichbar, ebenso putty, beides über dyndns !
Gruß Micha
Einen Kommentar schreiben:
-
Der spricht nicht..
- openvpn-Server auf dem WireGate läuft (Status)
- IP 91.15.59.14 stimmt?
- Port 1194/UDP ans WireGate weitergeleitet?
Makki
Einen Kommentar schreiben:
-
Die VPN Verbindung wird nicht vollständig aufgebaut. Habe bei meinem 2. WG eigentlich alles so gemacht, wie beim ersten ?!
Log-Datei ist im Anhang. Was muss ich ändern
Freundliche Grüße aus Wörlitz
Micha
jakob_06_log.txt
Einen Kommentar schreiben:
-
Also, Ursache war viel banaler: Bei IP-Adressen für Clients war das lokale LAN eingetragen, das muss(*) aber ein anderes IP-Subnetz als das lokale sein.
Beispiel:
- das WireGate ist im LAN mit 10.0.0.100/255.255.255.0
- Router/Default-Gateway ist 10.0.0.1
- IP-Subnet für die VPN-Clients ist 10.0.1.0 / 255.255.255.0
Dabei auch nicht vergessen: wenn man auf alle Hosts im LAN per VPN zugreifen will muss man entweder
a) im Default-Gateway (Router) eine statische Route auf 10.0.0.100 für das Subnetz 10.0.1.0/255.255.255.0 eintragen
oder
b) Das WireGate als Default-Gateway an allen Clients eintragen (ausser im WireGate selbst natürlich, dort kommt dann die 10.0.0.1 als GW rein.
-> Das einfachste ist, die Defaulteinstellungen (172.24.254.0) zu lassen und nur bei "push route ..." das eigene lokale Subnetz einzutragen.
*: zumindest in der einfachen Variante. Es gibt noch die Variante mit Bridgen der VPN-Clients ins LAN, das ist aber einigermassen komplizierter und nur manuell einzurichten.. Ausserdem gibts Risiken und Nebenwirkungen..
Makki
P.S.: Und in der nächsten Version sollte dem Anwender noch eine faire Chance eingeräumt werden die zugehörige Fehlermeldung auch zu erblicken, ich arbeite daran
Einen Kommentar schreiben:


Einen Kommentar schreiben: