[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenVPN und Routing machen mich konfus...

Hi,

Am 02.10.2010 03:45, schrieb ako:



Ich lese viel davon, dass einige ebenfalls in eine Richtung
"pingen" können und in die andere Richtung nicht. So auch hier.
Nur glaube ich fest, dass meine Rechner die richtigen Routing
Tables haben.



.. obwohl du es sicher schon getestet hast:
Ein Ping von deinem VPN Server auf die _LAN-IP_ deines VPN Clients, also auf die 192.168.10.15 bei deaktivierter Windows Firewall.
Es ist möglich, dass deine Pings korrekt geroutet werden, die Antworent aber irgendwo geblockt wird. 

Du verwendest die Windows Firewall, keine andere?
Zur weiteren Fehlerfindung wäre ein "route -n" bzw. "route print" von einem Rechner des VPN Client LAN's hilfreich. 

Gruß Dirk





Zuerst die Server-Seite ->
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
OpenVPN Server: Win2k3 (192.168.200.14)
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.200.250 192.168.200.14 100
10.8.0.0 255.255.255.252 10.8.0.1 10.8.0.1 10
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.1 1
10.8.0.1 255.255.255.255 127.0.0.1 127.0.0.1 10
10.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1 10
192.168.10.0 255.255.255.0 10.8.0.2 10.8.0.1 1
192.168.200.0 255.255.255.0 192.168.200.14 192.168.200.14 100
192.168.200.14 255.255.255.255 127.0.0.1 127.0.0.1 100
192.168.200.255 255.255.255.255 192.168.200.14 192.168.200.14 100
255.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1 1
255.255.255.255 255.255.255.255 192.168.200.14 192.168.200.14 1
Standardgateway:192.168.200.250

Firewall/Standard-Gateway(192.168.200.250):
Static routing -> 10.8.0.0/24 GW 192.168.200.14
und sicherheitshalber auch noch
192.168.10.0/24 GW 192.168.200.14
-----------------------------------------------------------------------



dann die Client-Seite ->
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
OpenVPN Client: Debian 5 (192.168.10.15)
route -n:
Ziel Router Genmask Flags Metric
10.8.0.5 0.0.0.0 255.255.255.255 UH 0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0
192.168.200.0 10.8.0.5 255.255.255.0 UG 0
192.168.10.0 0.0.0.0 255.255.255.0 U 0
0.0.0.0 192.168.10.1 0.0.0.0 UG 0

ip route:
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
10.8.0.0/24 via 10.8.0.5 dev tun0
192.168.200.0/24 via 10.8.0.5 dev tun0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.15
default via 192.168.10.1 dev eth0

Firewall/Standardgateway(192.168.10.1)
Static routing -> 192.168.200.0/24 GW 192.168.10.15

"iptables" ist hier so eingestellt:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
-----------------------------------------------------------------------



tcpdump vom Client(192.168.10.15) auf einen Rechner hinterm
Server(192.168.200.14)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
tracert 192.168.200.10:

IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 2,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 3,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 4,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 5,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 6,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 7,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 8,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 9,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 10,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 11,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 12,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 13,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 14,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 15,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 16,
IP 10.8.0.1 > 10.8.0.6: ICMP time exceeded in-transit,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 17,
IP 10.8.0.1 > 10.8.0.6: ICMP time exceeded in-transit,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 18,
IP 10.8.0.1 > 10.8.0.6: ICMP time exceeded in-transit,
IP 10.8.0.6 > 192.168.200.10: ICMP echo request, id 5146, seq 19,
IP 192.168.200.10 > 10.8.0.6: ICMP echo reply, id 5146, seq 4,
IP 192.168.200.10 > 10.8.0.6: ICMP echo reply, id 5146, seq 5,
-----------------------------------------------------------------------



Was leider nicht funktioniert ist das hier:
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Vom Server-LAN zum Client-LAN und AUCH der OpenVPN-Server selbst
kann nicht zur IP des Clients "pingen" (?), allerdings zur IP
10.8.0.6

tracert 192.168.10.15
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
1 <1 ms <1 ms * Firewall-GW [192.168.200.250]
2 <1 ms * <1 ms OpenVPN-Server [192.168.200.14]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
und beim "tcpdump" auf OpenVPN-Client tut sich nichts!?

Liegt also das Problem auf Client-Seite, sprich dem Debian
Rechner / dem LAN?

Ich blicke hier nicht mehr ganz durch und vllt. spiegelt sich das
auch in dieser Mail wieder. Ich hoffe dennoch, dass es
verständlich war. Schon mal vielen, vielen Dank für's Lesen und
die Mühe!!

Grüße
axel



-----------------------------------------------------------------------

Hier noch server.conf:
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
dev tun0
port 1194
proto udp
tun-mtu 1500
fragment 1500
mssfix
mode server
server 10.8.0.0 255.255.255.0
keepalive 10 60
ping-timer-rem
persist-key
persist-tun
push "ping-timer-rem"
connect-freq 1 sec
ifconfig-pool-persist ipp.txt

route 192.168.10.0 255.255.255.0
push "route 192.168.200.0 255.255.255.0"
push "dhcp-option DNS 192.168.200.10"
push "dhcp-option WINS 192.168.200.10"
client-config-dir ccd
client-to-client

tls-server
auth SHA1
auth-nocache
duplicate-cn
dh dh1024.pem
cipher AES-256-CBC
pkcs12 certs\\server.p12
comp-lzo
verb 3
status openvpn-status.log
management localhost 7505

-----------------------------------------------------------------------

und client.conf:
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
dev tun0
remote login.serverdomain.net
port 1194
proto udp
tun-mtu 1500
fragment 1500
mssfix
pull
tls-client
auth SHA1
auth-nocache
ns-cert-type server
cipher AES-256-CBC
pkcs12 certs/ako.p12
comp-lzo
verb 3
log /var/log/openvpn.log
status openvpn-status.log
user ead
group ead
float
persist-key
persist-tun

in "ccd" gibts noch eine Datei -> ako
iroute 192.168.10.0 255.255.255.0/24
Reply to: