PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenVPN - LAN nicht erreichbar



WingMan81
11.10.07, 18:27
Hallo,

ich habe dieses mal ein Problem mit OpenVPN. Während der Einrichtung bin ich nach dem HowTo aus diesem Forum vorgegangen.
Die Verbindung zwischen Client und Server kommt zwar zustande, allerdings ist das hinter dem Server liegende Netz nicht erreichbar.
Hier mal das Szenario:


192.168.99.50
_______ Client 1
|
DynDNS | 192.168.99.51
Client -------------Router ----------|---------Client 2
192.168.178.22 192.168.99.254 |
10.8.0.6 10.8.0.1 |_______Client x
192.168.99.70


Server (Debian - etch):

port 1194

proto udp

dev tun

ca zertifikate/ca.crt
cert zertifikate/server.crt
key zertifikate/server.key # This file should be kept secret
dh zertifikate/dh1024.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.99.0 255.255.255.0"

client-to-client

keepalive 10 120

comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log


verb 3



Client (WinXP):



client
pull

dev tun

proto udp

resolv-retry infinite

nobind

persist-key
persist-tun

ca ca.crt
cert client_holger.crt
key client_holger.key

comp-lzo

verb 3



/proc/sys/net/ipv4/ip_forward (auf Server)

1

route -n (auf Server)


10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0


Pings vom Client aus:
ping 10.8.0.1 --> OK
ping 192.168.99.200 (interne IP des Servers) --> OK
ping beliebige andere Adresse im LAN des Servers (192.168.99.xxx) --> NICHT OK!

Könnte mir jemand da mal einen Tip geben? Wäre sehr dankbar!

Viele Grüße
WingMan81

override
11.10.07, 20:33
Wie sind die Gateways auf den anderen Client-PCs im Server-LAN?
Diese müssen entweder auf den OVPN-Server (192.168.99.254) sein oder der entsprechende Standardgateway muss eine statische Route für 10.8.0.0/24 nach 192.168.99.254 haben.
Falls diese so eingerichtet sind, gibt es Firewall-Regeln a la iptables? was sagt "iptables -L -nv" bzw. "iptables -t nat -L -nv"?

WingMan81
11.10.07, 21:16
Hallo,

auf dem Router habe ich bereits eine statische Route auf den VPN-Server (192.168.99.200) gesetzt gehabt.
Von iptables verstehe ich ehrlich gesagt nicht sonderlich viel, daher poste ich sie einfach mal. Euch sagen die mit Sicherheit mehr :ugly:
Über die "vif" Schnittstellen nicht wundern, die stammen von XEN.

iptables -L -nv


Chain INPUT (policy ACCEPT 34329 packets, 3308K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tap0 * 0.0.0.0/0 0.0.0.0/0
8 480 ACCEPT 0 -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tap+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tap0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 153K packets, 79M bytes)
pkts bytes target prot opt in out source destination
44 2640 ACCEPT 0 -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0
42885 2319K ACCEPT 0 -- * * 192.168.99.226 0.0.0.0/0 PHYSDEV match --physdev-in vif1.0
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif1.0 udp spt:68 dpt:67
0 0 ACCEPT 0 -- * * 192.168.99.222 0.0.0.0/0 PHYSDEV match --physdev-in vif3.1
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif3.1 udp spt:68 dpt:67
6645 955K ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif3.0
2098 433K ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif4.0
0 0 ACCEPT 0 -- * * 192.168.99.220 0.0.0.0/0 PHYSDEV match --physdev-in vif4.1
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif4.1 udp spt:68 dpt:67
645 78130 ACCEPT 0 -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tun0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- eth0 tun0 10.8.0.0/24 0.0.0.0/0
0 0 ACCEPT udp -- eth0 tun0 10.8.0.0/24 0.0.0.0/0
0 0 ACCEPT 0 -- tun0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- tap+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 36666 packets, 3977K bytes)
pkts bytes target prot opt in out source destination


iptables -t nat -L -nv


Chain PREROUTING (policy ACCEPT 6 packets, 724 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 9 packets, 1112 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 3 packets, 388 bytes)
pkts bytes target prot opt in out source destination


Danke und viele Grüße
WingMan81

WingMan81
11.10.07, 22:10
Mir ist gerade noch etwas aufgefallen. Vom Client aus funktioniert der Ping nicht nur auf die LAN-Adresse des Servers (192.168.99.200) sondern auch auf das entfernte Gateway (192.168.99.254).
Nur sämtliche anderen Clients sind nicht erreichbar. Nicht einmal die anderen virtuelle Gäste die auf dem XEN-Server laufen, auf denen auch der OpenVPN Server läuft. Din etwas ratlos....
Denke allerdings das es evtl. am Gateway des entferneten LANs liegt. Aber auf diesem liegt die statische Route auf den OpenVPN Server!

Viele Grüße
WingMan81

override
13.10.07, 13:17
Also am IPTables liegt es nicht, da wird alles akzeptiert. Die Regeln verlangsamen nur den Prozess, da es nur Accept-Regeln gibt, und alles was nicht von der Regel betroffen ist auch Akzeptiert wird.
Probiere mal von einem Client im LAN, z.B. 192.168.99.50, einen PING auf 10.8.0.1, also der Server-Adresse des OVPN-Servers. Wenn die nicht durchkommt ist es ein Routing-Problem Serverseitig.
Alternativ könnte es auch noch ein Firewall-Problem auf den Clients im Servernetz geben. Wenn das WinXP Clients sind und eine Firewall haben (SP2 oder 3rd Party) lassen diese vielleicht nur Zugriffe aus dem eigenen Subnetz zu.

WingMan81
14.10.07, 16:50
Ich denke das kann ich bereits ausschließen, da ja auch die DomU dex XEN Servers nicht erreichbar sind. Auf der gleichen Maschine läuft auch der OVPN Server.
Hat evtl. sonst noch jemand Ideen?

WingMan81
15.10.07, 19:58
Also: Das Problem besteht leider weiterhin. Nur konnte ich heute mal einen Ping aus dem entfernten Netz (hinter OpenVPN Server) auf einen verbundenen Client absetzen und siehe da: Es funtkioniert. Leider halt nur in eine Richtung, denn vom (per VPN verbundenen) Client ist das entfernte Netz weiterhin nicht vollständig erreichbar.

Ich finde das alles recht wunderlich, da ja einige Pings ins entfernte Netz funktionieren.

Hier noch einmal alles was mir so einfällt zu posten, hoffe dabei fällt einem von euch etwas seltsames ein!

ifconfig tun-Device:


tun0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:57 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX bytes:3836 (3.7 KiB) TX bytes:1488 (1.4 KiB)


Hierbei verstehe ich den Punkt P-z-P nicht! Was soll das für eine IP sein? Anzu pingen ist sie nicht und die Clients bedienen sich aus dem Pool 10.8.0.50 - 10.8.0.60

route -n auf Server


10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0



route print auf Client: (verkürzt auf die wichtigen Passagen)


10.8.0.0 255.255.255.0 10.8.0.49 10.8.0.50 1
10.8.0.48 255.255.255.252 10.8.0.50 10.8.0.50 30
10.8.0.50 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.99.0 255.255.255.0 10.8.0.49 10.8.0.50 1



Alle Konfig-Files etc. sind unverändert!

Wäre wirklich schön, wenn sich nochmal jemand diesem Problme annhemen könnte :o:o:o

Viele Grüße
WingMan81

bla!zilla
15.10.07, 21:36
Ich blicke nicht ganz durch deine Konfiguration, aber 99% dieser Probleme werden durch ein falsches Gateway, oder eine falsche / fehlende Netzroute am Client verursacht. Die Clients kennen einfach den Weg zum Client, am anderen Ende des VPN Tunnels, nicht.

WingMan81
16.10.07, 18:49
Aber die Routen habe ich doch gepostet. MEiner Meinung nach sind sie doch korrekt, oder? Außerdem funktioniert doch auch der Ping vom VPN Client auf das Standardgateway im entfernten VPN Netz und aus dem entfernten Netz sind ja auch die verbundenen Clients über die 10.8.0.X Adresse erreichbar?!?!? Kann doch dannkein Routing Problem sein, oder?

bla!zilla
16.10.07, 19:43
Setz doch auf dem Gateway oder dem OpenVPN Server mal einen Packetsniffer auf und guck dir den Verkehr auf.

Ganz ehrlich? Ich blicke bei deinem Routing nicht durch.... Du kommst also mit einem Ping bis zur 192.168.99.254, aber die Clients aus dem Range 192.168.99.xx erreichst du nicht? Welches Defaultgateway haben die Clients eingetragen?

WingMan81
16.10.07, 20:12
Du kommst also mit einem Ping bis zur 192.168.99.254, aber die Clients aus dem Range 192.168.99.xx erreichst du nicht?

Genauso sieht es aus! Die Clients im LAN hinter dem VPN haben 192.168.99.254. Auf diesem Gateway ist wiederum eine static Route 10.8.0.0/24 --> OpenVPN-Server.

bla!zilla
17.10.07, 08:10
Dann schau dir den Verkehr bitte mal per tcpdump oder Wireshark an.

WingMan81
19.10.07, 17:36
So, hat leider etwas gedauert, da der Server im Ausland steht und dort öfter mal die DSL Verbindung zusamenbricht.
Heute konnte ich jedoch wieder auf den Server zugreifen und habe tcpdump laufen lassen während ich die Pings der Reihe nach durchprobiert habe.
Als erstes der Ping mit reply auf die lokale IP des Servers. Anschließend ein Ping auf das Gateway des entfernten Netzes samt Reply und im Anschluss zwei Pings auf zwei Hosts des Netzes, welche jedoch nicht antworten! Das bringt mich jetzt leider immer noch nicht weiter. Allerdings weiss ich nun zumindest das das Routing funktioniert. Jetzt bräuchte ich allerdings noch ein paar Anregungen wo ich das Problem noch suchen könnte.
Wie gesagt: Alle FW sind down. Bei einem Client handelt es sich um einen Win XP Rechner bei einem anderen um ein virtuelles (XEN) Debian System. Beides Clients können im lokalen Netz angepingt werden.
Ach ja: und die Route 10.8.0.0 ist im Gateway eingetragen!



19:17:39.262956 IP (tos 0x0, ttl 128, id 28011, offset 0, flags [none], proto: ICMP (1), length: 60) 10.8.0.6 > 192.168.99.200: ICMP echo request, id 1536, seq 4352, length 40
19:17:39.262970 IP (tos 0x0, ttl 64, id 16845, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.99.200 > 10.8.0.6: ICMP echo reply, id 1536, seq 4352, length 40
19:17:43.837150 IP (tos 0x0, ttl 128, id 28073, offset 0, flags [none], proto: ICMP (1), length: 60) 10.8.0.6 > 192.168.99.254: ICMP echo request, id 1536, seq 4608, length 40
19:17:43.837718 IP (tos 0x0, ttl 254, id 24418, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.99.254 > 10.8.0.6: ICMP echo reply, id 1536, seq 4608, length 40
19:18:02.024381 IP (tos 0x0, ttl 128, id 28305, offset 0, flags [none], proto: ICMP (1), length: 60) 10.8.0.6 > 192.168.99.220: ICMP echo request, id 1536, seq 4864, length 40
19:18:07.284273 IP (tos 0x0, ttl 128, id 28375, offset 0, flags [none], proto: ICMP (1), length: 60) 10.8.0.6 > 192.168.99.220: ICMP echo request, id 1536, seq 5120, length 40
19:19:32.821166 IP (tos 0x0, ttl 128, id 26205, offset 0, flags [none], proto: ICMP (1), length: 60) 10.8.0.6 > 192.168.99.65: ICMP echo request, id 1536, seq 4925, length 40
19:19:37.284273 IP (tos 0x0, ttl 128, id 26275, offset 0, flags [none], proto: ICMP (1), length: 60) 10.8.0.6 > 192.168.99.65: ICMP echo request, id 1536, seq 5360, length 40


Verstehe das alles nicht... HILFE :ugly:

Viele Grüße
WingMan81

WingMan81
22.10.07, 21:40
sorry, aber bin echt ratlos, daher *push*:mad:

bla!zilla
22.10.07, 22:20
Pushen wird hier nicht gerne gesehen.

WingMan81
23.10.07, 07:20
Hatte ich mir schon gedacht :o

Bin nur wirklich langsam am durchdrehen. Komme einfach nicht dahinter wo der Hase im Pfeffer liegt!

WingMan81
23.10.07, 23:18
So, bin mir mittlerweilen ziemlich sicher, dass es am routing auf dem Server liegt!
Wie bereits geschrieben setze ich ja XEN ein.
Meine Vermutung ist:

XEN funktioniert so:

LAN ----- eth0 ----veth0 ---- vif0 ----> xenbr0 <--- vif1
^
|------- vif2

Also ich denke, dass beim Routing etwas schief läuft, denn es ist ja nur die interne IP des Servers sowie des Gateways erreichbar.
Interne IP erkläre ich mir dadurch, dass das forwarding auf dem Server ja noch funktioniert, nur irgendwie an die falsche Adresse oder so? Das weiss ich leider nicht so genau. Hoffe einer von euch könnte mir da evtl. weiter helfen.

Gateway ist erreichbar da es ja nunmal die default Route ist.

So, wie kriege ich nun das Routing in den Griff? Wo steht auf welches Interface das ganze läuft? Denn das tun0 Device steht ja ziemlich für sich alleine, da alles andere ja über die xenbr0 läuft.

Mmmh, befürchte das ist nicht so ganz einfach zu verstehen was ich geschrieben habe. Aber ist halt schwer etwas zu beschreiben, wo man nicht genau weiss wo der Fehler liegt.

Also falls Fragen offen geblieben sind, fragt bitte nach!
Über Antworten bzgl. des Problems freue ich mich natürlich noch viel mehr :D

Gruß
WingMan81

bla!zilla
24.10.07, 07:38
Und noch mal mein Hinweis: Guck dir an verschiedenen Stellen den Verkehr an und schau nach wo welcher Verkehr ankommt. Du musst erstmal die Stelle isolieren, an der die Daten nicht mehr weiterkommen.

WingMan81
27.10.07, 14:05
Nur für den Fall das es irgendjemanden interessiert: ES LÄUFT!!!

Am Router funkt. anscheinend die statischen Routen nicht korrekt (sch... tunesische billig Ware...)

Statische Routen in Clients eingetragen --> OK, funktioniert :D:D:D (Wobei ich schwören könnte, dass ich das bereits zuvor einige Male ausprobiert habe....)

Trotzdem an dieser Stelle vielen DANK für eure Bemühungen!!!

Gruß
WingMan81