Posted: Thu Mar 29, 2012 9:50 Post subject: (gelöst) WRT54G / LAN-to-LAN OpenVPN Problem
Hallo Leute,
ich bin neu hier und hoffe Ihr könnt mir weiterhelfen.
Nachdem ich mit etwas Hilfe einen funktionierenden OpenVPN-Tunnel
zwischen einem ALIX-Board mit pfSense (Server) und einem mit
DD-WRT(dd-wrt.v24_vpn_generic.bin) geflashten WGR54GL (Client) am laufen habe,
fehlt mir nur noch ein kleines Detail.
Ich verbinde damit 2 Netze, die unterschiedliche IP´s im 192.168.x.x er Netz haben,
über die Tunnel-IP 10.10.x.x.
Aufgaben des Tunnels, Zugriff aus dem remoten Netz auf mein NAS in der DMZ (Subnetz).
Für den Zugriff aus dem remoten Netz habe ich für mein NAS ein Portforwarding auf dem pfSense eingerichtet.
Dies funktioniert problemlos.
Weiterhin will ich aus meinem LAN einen Zugriff auf das remote Netz um dort einen Debian-PC
zu administrieren.
Hier habe ich folgendes Problem.
Ein Zugriff per ssh Port22 auf das remote Netz kann nur über das Tunnelende 10.10.x.x erfolgen.
Das heißt, ich muß mich per ssh 10.10.x.x erst auf dem Router (WRT54GL/DD-WRT)einloggen, bevor ich dann per
ssh 192.168.x.x im remoten Netz auf dem Linux-PC lande.
Das sollte ja nicht so ganz der Sinn einer LAN-to-LAN Kopplung sein.
Ich habe die Firewall probeweise abgeschaltet, das Tunnelende per zusätzlicher IPTABLES-Rules freigegeben
und ein Portforwarding für ssh geschaltet.
Alles ohne Erfolg.
Hier die zusätzlichen Rules meines DD-WRT OpenVPN WRT54GL....
Die Rules erlauben es überhaupt erst die Firewall aktiviert zu lassen
und gleichzeitig einen funktionierenden Tunnel zu haben.
Zusätzlich hatte ich unter NAT eine Portweiterleitung für Port22 eingetragen, hat aber nicht funktioniert.
Der Versuch ein Tutorial von DD-WRT zu nutzen ging auch nicht, da die Kopplung von pfSense zu DD-WRT seitens der Zertifikate schon ein paar Probleme machte.
Die anschließende Suche im Netz hat mich auf folgende Seite gebracht...
wozu portfreigaben ? das geht doch alles ueber routing und nat ist ueberflüssig.
"Zusätzlich hatte ich unter NAT eine Portweiterleitung für Port22 eingetragen, hat aber nicht funktioniert."
Das habe ich mittlerweile auch begriffen, das NAT für den Tunnel nicht benötigt wird.
Hier mal meine Routing-Tabelle.....
Code:
root@winnie:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.8.1 10.10.8.5 255.255.255.255 UGH 0 0 0 tun0
10.10.8.5 * 255.255.255.255 UH 0 0 0 tun0
213.191.64.177 * 255.255.255.255 UH 0 0 0 ppp0
172.16.7.0 10.10.8.5 255.255.255.0 UG 0 0 0 tun0
192.168.55.0 * 255.255.255.0 U 0 0 0 br0
192.168.155.0 10.10.8.5 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 * 255.255.0.0 U 0 0 0 br0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default lo1.br52.asham. 0.0.0.0 UG 0 0 0 ppp0
Hier sieht man die Zielnetzwerke 172.16.7.0 + 192.168.155.0 meines pfSense-Routers die über 10.10.8.5 (Tunnel) erreichbar sind. Das ist so OK.
192.168.55.0 ist das LAN (br0) des remoten DD-WRT VPN-Clients.
Hier ist der Tunnel nicht als Gateway eingetragen.
Wohl in Ordnung so, sonst hätte ich wohl keine Verbindung zum Internet mehr.
Wie aber erhalte ich direkten Zugriff auf das
192.168.55.0...er Netz.
Statische Route eintragen ? ...oder wie ?
Gruß orcape
naja, dafuer bräuchte man auch mal die andere routen tabelle ;D
mein szenario ist ein wenig anders, ich habe 2 DD-WRT clients und ein root server spielt den Server. aber vom prinzip her das selbe. womöglich musst du in deiner konfiguration auch mit "iroute" arbeiten.
poste doch mal ein traceroute von beiden seiten zusätzlich zu der 2ten routen tabelle und guck, wo es hängen bleibt. _________________ RT-N66U @ Build 25697M K3.10.63
TL-WR842ND v1 @ BS-build 23919 WDS AP
TL-WR841ND @ BS-build 23919 WDS Client
TL-WR841ND @ BS-build 23919 Client Bridge ( Routed )
ich glaub Du hast recht.
Es liegt nicht an der Config des WRT54GL.
Traceroute von WRT54GL (LAN) auf das NAS hinter meinem
pfSense-Router sagt...
Code:
traceroute 172.16.7.10
traceroute to 172.16.7.10 (172.16.7.10), 30 hops max, 38 byte packets
1 10.10.8.1 (10.10.8.1) 72.619 ms 71.592 ms 72.052 ms
2 172.16.7.10 (172.16.7.10) 81.496 ms 72.449 ms 72.408 ms
...also Tunnelserver-NAS.
Auf der Routing-Tabelle meines pfSense-Routers ist kein Eintrag zum remoten Netz, nur zum remoten Router über den Tunnel mit der Tunnel-IP.
Das remote Netz habe ich beim OpenVPN-Server zwar schon eingetragen, aber aus irgendeinem Grund nimmt er das nicht in die Routingtabelle auf.
Jetzt habe ich auf dem VPN-Server noch eine zusätzliche Route eingetragen, mal sehen ob das klappt.
Funktioniert immer noch nicht.
Code:
192.168.55.0/24 10.10.8.2 UGS 0 6 1500 ovpns1
...so sieh der Eintrag in der Routing Tabelle jetzt aus.
über die ferne is das natuerlich alles immer etwas schwer zu gucken, wo da der fehler ist, zumal ich mich mit pfsense auch nicht auskenne. ausserdem habe ich noich nicht recht n überblick über die konfig, ein bild mit ip adressen wäre vll nicht schlecht.
vom GL auf den NAS kommse?
von clients hinterm GL kommse auch nicht aufs NAS ? _________________ RT-N66U @ Build 25697M K3.10.63
TL-WR842ND v1 @ BS-build 23919 WDS AP
TL-WR841ND @ BS-build 23919 WDS Client
TL-WR841ND @ BS-build 23919 Client Bridge ( Routed )
Also, hab mich mal "creativ" betätigt, sieht zwar bescheiden aus....
...tut aber seinen Zweck.
Vom WRT54 und den dahinter liegenden Clients komme ich auf das NAS, den Rest habe ich bewußt nicht freigegeben.
Wie gesagt, ich glaube jetzt das es an der Konfiguration des
pfSense VPN-Servers liegt.
ah ja. und was geht jetzt nochmal nicht? das .55 netz zu erreichen ? oder wo soll der debian stehen ?
.55 client zu .155 geht ?
.55 client zu nas geht !
.155 client zu nas geht ?
.155 client zu .55 geht nicht ? _________________ RT-N66U @ Build 25697M K3.10.63
TL-WR842ND v1 @ BS-build 23919 WDS AP
TL-WR841ND @ BS-build 23919 WDS Client
TL-WR841ND @ BS-build 23919 Client Bridge ( Routed )
die ssh-Verbindung vom PC 192.168.155.2 zum Netz 192.168.55.0/24 läßt sich nur herstellen, wenn ich in der Konsole (oder auch Putty) die Tunnel-IP (10.10.8.6) des remoten Routers eingebe. Damit komme ich auf den WRT54 (ssh), anschließend gebe ich die IP des Linux-PC´s im 192.168.55.0/24
Netz ein und kann z.B. ein Update des Rechners machen.
Die direkte Eingabe der Rechner-IP im 55. er Netz ist nicht möglich.
Übrigens alles Debian, bis auf einen Vista-Laptop im 55. er Netz.
Also...
.55 client zu .155 geht ? funktioniert, aber nicht
freigegeben von mir
.55 client zu nas geht ! funktioniert
.155 client zu nas geht ? funktioniert
.155 client zu .55 geht nicht ? Da liegt das Problem !!!
...zumindest nicht direkt, sondern nur über "Umweg".
also wenns in die eine richtung geht, aber in die andere nicht, kanns eigentlich nicht ein routing problem sein. schliesslich würde sonst der rückweg von .55 zu .155 nicht funktionieren.
von dir nicht freigegeben heisst: durch iptables blockiert ? liegt hier ein config fehler vor ?
benutzt du die option client config dir ?
was sagt das openvpn server log / cliet log
...komme ich nur bis zu meinem Router.
Gebe ich Traceroute für den remoten Router (Tunnel-IP) ein...
Code:
traceroute 10.10.8.6
traceroute to 10.10.8.6 (10.10.8.6), 30 hops max, 60 byte packets
1 skydive (192.168.155.1) 0.250 ms 0.271 ms 0.331 ms
2 10.10.8.6 (10.10.8.6) 83.311 ms 88.603 ms 90.043 ms
...komme ich zumindest bis zum remoten Router.
Seltsamerweise sieht das log der Firewall so aus...
Code:
pass
Apr 1 09:34:59 LAN 192.168.155.2:39463 192.168.55.2:22 TCP:S
Quote:
benutzt du die option client config dir ?
...sag mir mal was das ist.
Quote:
was sagt das openvpn server log / cliet log
Code:
Apr 1 08:24:28 openvpn: Found certificate /C=DE/ST=xxxxxx/L=zzzzzzzz/O=xxxx-privat/emailAddress=xxxx@yyyy.de/CN=xxxxx-ca with depth 1
Apr 1 08:24:29 openvpn: Found certificate /C=DE/ST=xxxxxx/L=zzzzzzzzzzz/O=xxxx-privat/emailAddress=cccc@yyyyyy.de/CN=xxxxx-ca with depth 0
Apr 1 08:49:56 openvpn[57704]: event_wait : Interrupted system call (code=4)
Apr 1 08:49:56 openvpn[57704]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1542 10.10.8.1 10.10.8.2 init
Apr 1 08:49:56 openvpn[57704]: SIGTERM[hard,] received, process exiting
Apr 1 08:49:56 openvpn[54282]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 11 2011
Apr 1 08:49:56 openvpn[54282]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 1 08:49:56 openvpn[54282]: Initializing OpenSSL support for engine 'cryptodev'
Apr 1 08:49:56 openvpn[54282]: TUN/TAP device /dev/tun1 opened
Apr 1 08:49:56 openvpn[54282]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Apr 1 08:49:56 openvpn[54282]: /sbin/ifconfig ovpns1 10.10.8.1 10.10.8.2 mtu 1500 netmask 255.255.255.255 up
Apr 1 08:49:56 openvpn[54282]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1542 10.10.8.1 10.10.8.2 init
Apr 1 08:49:56 openvpn[56433]: UDPv4 link local (bound): [AF_INET]78.50.128.143:1194
Apr 1 08:49:56 openvpn[56433]: UDPv4 link remote: [undef]
Apr 1 08:49:56 openvpn[56433]: Initialization Sequence Completed
Der Client (DD-WRT)logt nicht, obwohl bei syslogd als remoter Server 10.10.8.1:22 eingetragen ist.
Zumindest finde ich unter /tmp/var/log/messages keine Einträge.
Quote:
benutzt du push optionen in der ovpn server cfg ?
Ja, um dem VPN-Server mitzuteilen, das das NAS auf 172.16.7.x zu finden ist.
Quote:
eigentlich bräuchte man ja mal alles. komplette routing tables beider geräte, openvpn configs usw usw. iptables config
...das wäre die Routingtabelle meines Routers. (pfSense)
Client siehe oben....
Mit den Configs ist das so eine Sache.
Habe bei pfSense noch nicht gefunden wo man sich die Rules anzeigen lassen kann. Ist alles wunderschön grafisch dargestellt, die eigentlichen Rules bleiben im Hintergrund.
opencpn client loggt nicht in var/messages sonder erstellt ein eigenes logfile.
mit ccd über gibt der server dem client zusätzliche parameter z.b. nen iroute befehl, was allerdings normal nur fuer multiclient benötigt wird. so lernt openvpn, hinter welchem client welches subnetz sitzt. das wird dann aber nciht in die kernel routing tabelle eingetragen.
sieht dann z.b. so aus:
Code:
Tue Mar 6 12:37:19 2012 WRT320N/93.213.69.170:32783 MULTI: Learn: 192.168.254.3 -> WRT320N/93.213.69.170:32783
Tue Mar 6 12:37:19 2012 WRT320N/93.213.69.170:32783 MULTI: primary virtual IP for WRT320N/93.213.69.170:32783: 192.168.254.3
Tue Mar 6 12:37:19 2012 WRT320N/93.213.69.170:32783 MULTI: internal route 192.168.0.0/24 -> WRT320N/93.213.69.170:32783
Tue Mar 6 12:37:19 2012 WRT320N/93.213.69.170:32783 MULTI: Learn: 192.168.0.0/24 -> WRT320N/93.213.69.170:32783
so hat openvpn "gelernt"
gleiches fuer client 2:
Tue Mar 6 12:37:25 2012 BELKIN/93.192.115.222:32786 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/BELKIN
Tue Mar 6 12:37:25 2012 BELKIN/93.192.115.222:32786 MULTI: Learn: 192.168.254.4 -> BELKIN/93.192.115.222:32786
Tue Mar 6 12:37:25 2012 BELKIN/93.192.115.222:32786 MULTI: primary virtual IP for BELKIN/93.192.115.222:32786: 192.168.254.4
Tue Mar 6 12:37:25 2012 BELKIN/93.192.115.222:32786 MULTI: internal route 192.168.178.0/24 -> BELKIN/93.192.115.222:32786
Tue Mar 6 12:37:25 2012 BELKIN/93.192.115.222:32786 MULTI: Learn: 192.168.178.0/24 -> BELKIN/93.192.115.222:32786
vorher hats bei mir mitm routing auch nicht geklappt gehabt.
pfsense mit tzelnet einloggen ( sofern möglich )
und iptables -L -vvv eingeben.
übrigens schreibst du immer von den ip´s 10.10.8.1 10.10.8.2 10.10.8.5 und 10.10.8.6
is doch irgendwie eine zuviel nech ?
laut routing tabelle hat dein wrt 10.10.8.5, du schreibs aber das der 10.10.8.6 hat. _________________ RT-N66U @ Build 25697M K3.10.63
TL-WR842ND v1 @ BS-build 23919 WDS AP
TL-WR841ND @ BS-build 23919 WDS Client
TL-WR841ND @ BS-build 23919 Client Bridge ( Routed )
...so nun komme ich der Sache schon näher.
Ich habe mal auf einer pfSense-Seite im Netz eine Routing-Tabelle eines Clients mit meiner DD-WRT verglichen.
Es fehlt folgender Eintrag....