Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenVPN anderes Netzwerk antwortet nicht
Hallo,
habe eine kleines Problem mit OpenVPN 2.0.
Der Client stellt, unter Windows XP, erfolgreich eine Verbindung mit dem Server her. Ich bekomme automatisch die IP 10.12.34.6 zugewiesen und erreiche den Server unter 10.12.34.1.
Nur möchte ich auch gerne das dahinterliegende 192.168.1.* Netzwerk erreichen können. Mit hilfe des Befehls "tcpdump -n -i tun0" sehe ich das der Client versucht zu Pingen aber keine Antwort bekommt.
Hier meine Konfigurationsdateien:
client:
client
dev tun
remote <SERVERIP> 1194
ca my-ca.pem
cert client1-cert.pem
key client1-key.pem
cipher AES-256-CBC
auth SHA1
comp-lzo
verb 3
server:
port 1194
proto udp
dev tun
ca /etc/openvpn/my-ca.pem
cert /etc/openvpn/servercert.pem
key /etc/openvpn/serverkey.pem
dh /etc/openvpn/dh2048.pem
server 10.12.34.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
auth SHA1
cipher AES-256-CBC
comp-lzo
verb 3
Gruß Biepon
Vielleicht hilft das?
# route -n // Vor dem Starten des OpenVPN's:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
# route -n // Nach dem Starten des OpenVPN's:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.12.34.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.12.34.0 10.12.34.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
Hallo,
ich habe auch genau die gleiche Konfiguration und bei mir klappt es taddellos. Die Routingtabelle scheint in Ordnung zu sein.
Vermutlich hast du im /proc/sys/net/ipv4/ip_forward ein "0" (deaktiviert) drinnen? ;)
Hallo Fly,
habe das IP Forwarding dort schon auf "1". :(
Irgendwo muss doch der haken sein.
Gruß Biepon
Hast du die mtu auf 1300 gesetzt? Kannst du die Ausgabe von tcpdump -n -i tun0 posten? WIe sieht dein FW aus?
Hast du die mtu auf 1300 gesetzt?
Ja gerade eben.
Kannst du die Ausgabe von tcpdump -n -i tun0 posten?
IP 10.12.34.6 > 10.12.34.1: icmp 40: echo request seq 6912
IP 10.12.34.1 > 10.12.34.6: icmp 40: echo reply seq 6912
IP 10.12.34.6 > 192.168.1.99: icmp 40: echo request seq 7936
.
.
.
WIe sieht dein FW aus?
Habe ersteinmal nur die IPTABLES angepasst.
iptables -I INPUT -p udp --dport 1194 -j ACCEPT
iptables -I OUTPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
Im Moment ist mir bei dir nur die Ausgabe der Tcpdump aufgefallen. Jedoch verstehe ich nicht warum es bei dir so ausergewöhnlich ist...
Bei mir hinter einem 172.16er Netz wenn ich den Server 172.16.1.10 anpinge bekomme ich folgendes:
12:56:30.449190 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7168
12:56:30.449527 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7168
12:56:31.449824 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7424
12:56:31.450035 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7424
12:56:32.449287 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7680
12:56:32.449501 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7680
12:56:33.450835 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7936
12:56:33.451033 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7936
Kannst du mir bitte die Ausgabe von iptables -vnxL posten?
Mir ist erst jetzt aufgefallen, dass dein Server kein default gateway hat
Den default-gateway lege ich wie fest? Mit "redirect-gateway"?
EDIT:
Hier der auszug von den iptables:
Chain INPUT (policy ACCEPT 497 packets, 64288 bytes)
pkts bytes target prot opt in out source destination
234 22354 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
11 660 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2 120 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 42 packets, 4262 bytes)
pkts bytes target prot opt in out source destination
316 30337 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
Dein Firewall ist nicht aktiv, da die Policies auf ACCEPT sind, aber das hat eher nichts mit vpn Problem zu tun.
Ich weiss nicht welches distribution du benutzt, wie man den Standardgateway einträgt.
Versuch mit route add default gw 192.168.1.1
Ich hoffe diesmal klappt es. Bezüglich iptables kannst du unter www.netfilter.org nachsehen...
Habe SuSE 9.3 als Destri.
Habe den Default-Gateway eingetragen, wie auch beim aufrufen von "route -n" zu sehen:
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Nur klappt es leider immer noch nicht. Der Client (Windows XP) hat beim Verbinden kein Gateway eingetragen, nur IP und Subnet. Weiß nicht ob es damit zusammen hängen könnte.
Nur klappt es leider immer noch nicht. Der Client (Windows XP) hat beim Verbinden kein Gateway eingetragen, nur IP und Subnet. Weiß nicht ob es damit zusammen hängen könnte.
Meinst du die virtuelle Ethernetadapter hat kein Gateway? Wenn ja, dann ist ok.
Nach jeder Änderung, die VPN-Verbindung trennen und neu aufbauen?
Versuch bei deiner Firewall folgendes, falls es sich um ein Testsystem handelt:
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
Vorsicht, dass du dich nicht aus dem Server aussperrst! Ich gehe davon aus, dass du mit ssh an deinem System anmeldest... Vorher die FW-Regeln mit iltables -F löschen, aber natürlich vorher die Policies auf ACCEPT setzen... ;)
Jap das ist Richtig :).
Habe die iptables eingetragen und konnte eine Verbindung vom Client aus herstellen.
Nur kommt der Client nicht durch, auch wenn ich nun versuche den Server (unter der VPN IP 10.12.34.1) zu erreichen bekomme ich nur ein Timeout.
:-/
Nein, die virtuelle IP vom Server kann man nicht pingen. Ich dachte du kannst das Netz hinter dem VPN Server nicht pingen? Du solltest den Router oder ein anderen Rechner hinter dem Netz pingen können oder was war dein Problem :confused:
Ja, ich möchte die Rechner hinter dem VPN-Server pingen können.
Nur war es immer so das ich auch den Server unter der VPN IP pingen konnte.
Ja, ich möchte die Rechner hinter dem VPN-Server pingen können.
Nur war es immer so das ich auch den Server unter der VPN IP pingen konnte.
Das kannst du jetzt aufgrund der neuen iptables Regeln nicht mehr. Das ist auch nicht notwendig...
Mir fällt im Moment leider nichts mehr ein...
Vielleicht postest du noch mal alles (ifconfig der VPN Server, iptables -vnxL und route -n). Bitte vorher den Openvpn neu starten. Falls die Ausgabe der tcpdump -n -i tun0 was anderes ausgibt wie zuvor, dann auch bitte Posten...
ifconfig:
eth0 Link encap:Ethernet HWaddr 00:30:84:9E:F9:4A
inet addr:192.168.1.211 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:84ff:fe9e:f94a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:210 errors:0 dropped:0 overruns:0 frame:0
TX packets:105 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:26892 (26.2 Kb) TX bytes:14339 (14.0 Kb)
Interrupt:11 Base address:0xe000
eth1 Link encap:Ethernet HWaddr 00:D0:09:FA:3F:50
inet addr:169.254.58.142 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::2d0:9ff:fefa:3f50/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:164 errors:0 dropped:0 overruns:0 frame:0
TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
collisions:4 txqueuelen:1000
RX bytes:17508 (17.0 Kb) TX bytes:15476 (15.1 Kb)
Interrupt:5
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:872 (872.0 b) TX bytes:872 (872.0 b)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.12.34.1 P-t-P:10.12.34.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:15 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:792 (792.0 b) TX bytes:0 (0.0 b)
iptables -vnxL:
Chain INPUT (policy DROP 62 packets, 6587 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
100 9836 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
Chain FORWARD (policy DROP 12 packets, 612 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 18 packets, 1668 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22
89 8747 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:1194
route -n:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.12.34.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.12.34.0 10.12.34.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Mh ... Die Firewall dropt viele packete. tcpdump -n -i tun0 zeigt nur noch requests aber es kommt kein reply von irgendeiner IP.
Wie ich es sehe versuchst du im internen Netz eine VPN Verbindung herzustellen. Das kann nicht funktionieren... Ich gehe davon aus, dass der Server im gleichen Netz ist wie der Client...
Ich schlage dir vor, wenn du weiter testen willst:
Bei eth1 die Adresse 172.16.1.1 nehmen und ein Testrechner hinter dem eth1 anhängen mit IP Adresse 172.16.1.10. Dann kannst du eine VPN Verbindung im 192er Netz herstellen und den 172.16.1.10 Rechner anpingen. Viel Spaß! :)
Danke.
Nur ist der Test-Client (169.254.58.141) mit einem HUB an eth1 (169.254.58.142) verbunden und baue auch von dort die Verbindung auf.
Das 192er Netz liegt auf eth0.
*verwirr* :D
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.