25
OpenVPN Server aufsetzen Routing ins Internet klappt bisher nicht
Hallo,
ich versuche gerade einen OpenVPN-Server aufzubauen. Inzwischen funktioniert das soweit das mein Client auch die Verbindung herstellt. Allerdings wird bisher leider nicht aller Internettraffic über die VPN geroutet. Ich hoffe ich könnt mir dabei weiterhelfen.
Erstmal die IP-Konfiguration des Servers. Der Server hat die IP 192.168.2.120 und kommt per 192.168.2.1 ins Internet.
Das VPN läuft dann über das Interface 192.168.10.1.
So nun die OpenVPN Server konfig. Der Server läuft über den Port 443 TCP. Entsprechende Portweiterleitung auf Routern/Firewalls sind gemacht. Und OpenPortCheck-Tools werfen positive Ergebnisse zurück. Zugreifen tue ich DDNS-Service, das funktioniert ebenfalls. Mitrouten möchte hier mein lokales Netz auf der 192.168.2.0. Dies funktioniert auch bereits, außer der Ping wird noch iwie blockiert.
Gut nun kommen wir zur Client-Konfiguration.
Nach erfolgreichen Verbinden zum VPN sieht dort die IP-Konfig wie folgt aus.
Hier bekommt der Client immer die Subnetzmaske 255.255.255.252 und nicht die wie in der Konfiguration angegebene 255.255.255.0.
Ist das womöglich schon die Fehler-Quelle?
Ich hoffe auf eure Hilfestellung.
LG
Julian
Nachtrag: Hier noch das Client Log
ich versuche gerade einen OpenVPN-Server aufzubauen. Inzwischen funktioniert das soweit das mein Client auch die Verbindung herstellt. Allerdings wird bisher leider nicht aller Internettraffic über die VPN geroutet. Ich hoffe ich könnt mir dabei weiterhelfen.
Erstmal die IP-Konfiguration des Servers. Der Server hat die IP 192.168.2.120 und kommt per 192.168.2.1 ins Internet.
Das VPN läuft dann über das Interface 192.168.10.1.
Ethernet-Adapter MyTap:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9
Physische Adresse . . . . . . . . : 00-FF-E2-D8-30-11
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::e1e7:ade8:b988:3b75%20(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.10.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.252
Lease erhalten. . . . . . . . . . : Samstag, 20. September 2014 03:47:22
Lease l„uft ab. . . . . . . . . . : Sonntag, 20. September 2015 03:47:22
Standardgateway . . . . . . . . . :
DHCP-Server . . . . . . . . . . . : 192.168.10.2
DHCPv6-IAID . . . . . . . . . . . : 318832610
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-9D-06-BE-C0-3F-D5-6C-32-FC
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS ber TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Controller der Familie Realtek PCIe GBE
Physische Adresse . . . . . . . . : C0-3F-D5-6C-32-FC
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.2.120(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.2.1
DNS-Server . . . . . . . . . . . : 192.168.2.1
NetBIOS ber TCP/IP . . . . . . . : AktiviertSo nun die OpenVPN Server konfig. Der Server läuft über den Port 443 TCP. Entsprechende Portweiterleitung auf Routern/Firewalls sind gemacht. Und OpenPortCheck-Tools werfen positive Ergebnisse zurück. Zugreifen tue ich DDNS-Service, das funktioniert ebenfalls. Mitrouten möchte hier mein lokales Netz auf der 192.168.2.0. Dies funktioniert auch bereits, außer der Ping wird noch iwie blockiert.
port 443 #change to any port you see fit. The client needs to use the same port
proto tcp #switch to tcp if you wish to use a tcp connection, the client needs to use the same protocol. udp gives better performance
dev tun
dev-node MyTap #name of your TAP interface.
server 192.168.10.0 255.255.255.0 #This may need modification as dictated by Internet Connection Settings. This is the default for ICS on Windows 7.
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1" #tells all Internet traffic to go through the tunnel
push "dhcp-option DNS 208.67.222.222" #OpenDNS servers, makes it easy to check if the tunnel is working properly
push "dhcp-option DNS 208.67.220.220"
push "route 192.168.2.0 255.255.255.0"
keepalive 10 120
comp-lzo #compression for better network performance. Disable if your server isn't powerful enough. Needs to be included in both server and client configs if you use it.
persist-key
persist-tun
user nobody
group nogroup
status openvpn-status.log
verb 3Gut nun kommen wir zur Client-Konfiguration.
client
dev tun
dev-node MyTap #Name of your TAP network interface
proto tcp #switch to tcp if you wish to use a tcp connection, needs to match server. udp gives better performance
remote meinddns.dlinkddns.com 443 #ddns wegen veröffentlichung angepasst
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
comp-lzo yes #compression for better performance. Disable if your server isn't powerful enough. Needs to be included in both server and client configs if you use it.
verb 3
ping 10
ping-restart 60
route-metric 512
route 0.0.0.0 0.0.0.0 Nach erfolgreichen Verbinden zum VPN sieht dort die IP-Konfig wie folgt aus.
Ethernet-Adapter MyTap:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : TAP-Windows Adapter V9
Physische Adresse . . . . . . . . : 00-FF-AB-4D-5C-91
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::3d10:1176:3474:1496%7(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.10.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.252
Lease erhalten. . . . . . . . . . : Samstag, 20. September 2014 11:58:16
Lease l„uft ab. . . . . . . . . . : Sonntag, 20. September 2015 11:58:16
Standardgateway . . . . . . . . . : 192.168.10.9
DHCP-Server . . . . . . . . . . . : 192.168.10.9
DHCPv6-IAID . . . . . . . . . . . : 184614827
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-2C-C2-4D-BC-EE-7B-5C-BA-F0
DNS-Server . . . . . . . . . . . : 192.168.10.1
NetBIOS ber TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physische Adresse . . . . . . . . : BC-EE-7B-5C-BA-F0
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::5439:147d:d386:7ff1%3(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.0.13(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Samstag, 20. September 2014 11:36:42
Lease l„uft ab. . . . . . . . . . : Sonntag, 21. September 2014 11:36:42
Standardgateway . . . . . . . . . : 192.168.0.1
DHCP-Server . . . . . . . . . . . : 192.168.0.1
DHCPv6-IAID . . . . . . . . . . . : 62713467
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-2C-C2-4D-BC-EE-7B-5C-BA-F0
DNS-Server . . . . . . . . . . . : 8.8.4.4
NetBIOS ber TCP/IP . . . . . . . : AktiviertIst das womöglich schon die Fehler-Quelle?
Ich hoffe auf eure Hilfestellung.
LG
Julian
Nachtrag: Hier noch das Client Log
Sat Sep 20 12:08:14 2014 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 7 2014
Sat Sep 20 12:08:14 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sat Sep 20 12:08:14 2014 Need hold release from management interface, waiting...
Sat Sep 20 12:08:14 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'state on'
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'log all on'
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'hold off'
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'hold release'
Sat Sep 20 12:08:15 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,RESOLVE,,,
Sat Sep 20 12:08:15 2014 Attempting to establish TCP connection with [AF_INET]88.68.172.78:443
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,TCP_CONNECT,,,
Sat Sep 20 12:08:15 2014 TCP connection established with [AF_INET]88.68.172.78:443
Sat Sep 20 12:08:15 2014 TCPv4_CLIENT link local: [undef]
Sat Sep 20 12:08:15 2014 TCPv4_CLIENT link remote: [AF_INET]88.68.172.78:443
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,WAIT,,,
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,AUTH,,,
Sat Sep 20 12:08:15 2014 TLS: Initial packet from [AF_INET]88.68.172.78:443, sid=f1440dcd 665fba17
Sat Sep 20 12:08:15 2014 VERIFY OK: depth=1, C=DE, ST=HE, L=Fulda, O=SchmidtVPN, CN=server, emailAddress=mail@host.domain
Sat Sep 20 12:08:15 2014 VERIFY OK: nsCertType=SERVER
Sat Sep 20 12:08:15 2014 VERIFY OK: depth=0, C=DE, ST=HE, O=SchmidtVPN, CN=server, emailAddress=mail@host.domain
Sat Sep 20 12:08:17 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Sep 20 12:08:17 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Sep 20 12:08:17 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Sep 20 12:08:17 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Sep 20 12:08:17 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Sep 20 12:08:17 2014 [server] Peer Connection Initiated with [AF_INET]88.68.172.78:443
Sat Sep 20 12:08:18 2014 MANAGEMENT: >STATE:1411207698,GET_CONFIG,,,
Sat Sep 20 12:08:19 2014 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sat Sep 20 12:08:19 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 192.168.2.0 255.255.255.0,route 192.168.10.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.10.10 192.168.10.9'
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: route options modified
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Sep 20 12:08:19 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Sep 20 12:08:19 2014 MANAGEMENT: >STATE:1411207699,ASSIGN_IP,,192.168.10.10,
Sat Sep 20 12:08:19 2014 open_tun, tt->ipv6=0
Sat Sep 20 12:08:19 2014 TAP-WIN32 device [MyTap] opened: \\.\Global\{AB4D5C91-0130-40B5-A9B7-7033E868D624}.tap
Sat Sep 20 12:08:19 2014 TAP-Windows Driver Version 9.9
Sat Sep 20 12:08:19 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.10.10/255.255.255.252 on interface {AB4D5C91-0130-40B5-A9B7-7033E868D624} [DHCP-serv: 192.168.10.9, lease-time: 31536000]
Sat Sep 20 12:08:19 2014 Successful ARP Flush on interface [7] {AB4D5C91-0130-40B5-A9B7-7033E868D624}
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 249745
Url: https://administrator.de/contentid/249745
Ausgedruckt am: 23.11.2024 um 02:11 Uhr
25 Kommentare
Neuester Kommentar
Moin,
dazu wurde in diesem Thread schon so ziemlich alles erläutert
OPEN-VPN Server als Internetgateway konfigurieren!
Die Subnetzmaske ist so in Ordnung, das
Grüße Uwe
dazu wurde in diesem Thread schon so ziemlich alles erläutert
OPEN-VPN Server als Internetgateway konfigurieren!
Die Subnetzmaske ist so in Ordnung, das
route 0.0.0.0 0.0.0.0 in der Clientconfig aber nicht, wie das in der Clientconfig auszusehen hat siehe obiger Link, ist aber nicht nötig da du das defautgw ja schon mit dem Server pushst..- Worauf läuft der OpenVPN-Server ?
- Ist auf diesem IP-Routing aktiviert ?
- Sind alle Firewallregeln angepasst?
- Wenn ein Router dem VPN-Server vorgeschaltet ist, ist dort eine Route auf den IP-Bereich des OpenVPN Server eingetragen ? oder macht der VPN-Server NAT ?
- Wegen fehlschlagenden Pings: Sind die Firewalls der Clients entsprechend konfiguriert auch aus einem anderen Subnetz ICMP Pakete anzunehmen ?
- Ein tracert liefert dir die Info ob Pakete defaultmäßig über das VPN laufen oder nicht. Wenn nicht checke auch die Metriken der DefaultGWs auf dem Client (route print)
Grüße Uwe
Das route 0.0.0.0 0.0.0.0 habe ich aus der Clientkonfig entfernt, dennoch funktioniert es noch nicht.
1. Der OpenVPN-Server läuft auf einer Intel NUC.
2. Auf den Server ist IP-Routing in Form von Routing und Ras aktiviert.
3. Alle Firewallregeln sollten angepasst sein. Port 443 TCP ist zumindest offen.
Zu 4. keine Ahnung.
Zu 5. Wie geht das?
Zu 6. Der Tracert auf den Client z.B. Auf die 192.168.10.1 liefert nur eine Zeitüberschreitung
Die routen auf den Client sehen wie folgt aus:
1. Der OpenVPN-Server läuft auf einer Intel NUC.
2. Auf den Server ist IP-Routing in Form von Routing und Ras aktiviert.
3. Alle Firewallregeln sollten angepasst sein. Port 443 TCP ist zumindest offen.
Zu 4. keine Ahnung.
Zu 5. Wie geht das?
Zu 6. Der Tracert auf den Client z.B. Auf die 192.168.10.1 liefert nur eine Zeitüberschreitung
Die routen auf den Client sehen wie folgt aus:
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.13 20
0.0.0.0 128.0.0.0 192.168.10.9 192.168.10.10 30
88.68.172.78 255.255.255.255 192.168.0.1 192.168.0.13 20
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
128.0.0.0 128.0.0.0 192.168.10.9 192.168.10.10 30
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.13 276
192.168.0.13 255.255.255.255 Auf Verbindung 192.168.0.13 276
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.13 276
192.168.2.0 255.255.255.0 192.168.10.9 192.168.10.10 30
192.168.10.1 255.255.255.255 192.168.10.9 192.168.10.10 30
192.168.10.8 255.255.255.252 Auf Verbindung 192.168.10.10 286
192.168.10.10 255.255.255.255 Auf Verbindung 192.168.10.10 286
192.168.10.11 255.255.255.255 Auf Verbindung 192.168.10.10 286
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.10.10 286
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.13 276
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.10.10 286
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.13 276
===========================================================================
St„ndige Routen:
Keine
Dieses Forumstutorial hast du auch gelesen ??:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Für dich gelten die gleichen Schritte zur Installation !!
Nur so viel:
Du musst, sollte der NUC hinter einem NAT Firewall Router stehen zwingend eine statische Route auf das interne OVPN Netzwerk dort einrichten alos ala:
Zielnetz: <interne_Netzwerk_IP Adresse_OVPN> <Maske> <lokale_OVPN_Server_IP>
Die interne Server IP ist die in der OVPN Server Konfig Datei mit server 172.16.2.0 255.255.255.0 angegeben ist !
So würde dann die Route im DSL NAT Router lauten:
Zielnetz: 172.16.2.0 255.255.255.0 192.168.0.13 ** (wenn die .0.13 der OVPN Server ist)
Lies das o.a. Tutorial und die Folgethreads dort ist alles explizit erklärt !
Nochwas:
OVPN rät dringenst davon ab TCP als Tunnel Encapsulation zu benutzen und zwar aus Performance Gründen. Besser du belässt es dann bei UDP !
Das obige Port Forwarding im Router usw. mit UDP 1194 (Default Port OVPN) würde für dich dann UDP 443 lauten. Oder TCP wenn du es dennoch damit machen willst !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Für dich gelten die gleichen Schritte zur Installation !!
Nur so viel:
Das route 0.0.0.0 0.0.0.0 habe ich aus der Clientkonfig entfernt, dennoch funktioniert es noch nicht.
Ist überflüssig und auch falsch diese Route ! Siehe Tutorial !1. Der OpenVPN-Server läuft auf einer Intel NUC.
Achtung wenn das NUC hinter einem NAT Firewall Router rennt ! Dort MUSST du ein Port Forwarding von UDP 1194 auf die lokale IP des OVPN Servers eintragen. Tunlichst sollte der OVPN Server auf dem NUC damit dann eine statische lokale IP haben, damit das PFW nicht ins Nirwana geht sollte sich die lokale IP mal ändern mit DHCP !2. Auf den Server ist IP-Routing in Form von Routing und Ras aktiviert.
Ist OK aber auch hier ACHTUNG:Du musst, sollte der NUC hinter einem NAT Firewall Router stehen zwingend eine statische Route auf das interne OVPN Netzwerk dort einrichten alos ala:
Zielnetz: <interne_Netzwerk_IP Adresse_OVPN> <Maske> <lokale_OVPN_Server_IP>
Die interne Server IP ist die in der OVPN Server Konfig Datei mit server 172.16.2.0 255.255.255.0 angegeben ist !
So würde dann die Route im DSL NAT Router lauten:
Zielnetz: 172.16.2.0 255.255.255.0 192.168.0.13 ** (wenn die .0.13 der OVPN Server ist)
3. Alle Firewallregeln sollten angepasst sein. Port 443 TCP ist zumindest offen.
Sollten ??? Vertrauen ist gut Kontrolle besser !! 443 ist auch irrelevant, wichtig ist der OVPN Tunnelport UDP 1194 der in der Port Forwarding Regel eingetragen sein muss. (Siehe Tutorial "OVPN hinter NAT Router" !)Zu 4. keine Ahnung.
Ist in 2.) erklärt also checken !! Traceroute (tracert) ist hier wie immer dein bester Freund !!Zu 5. Wie geht das?
Indem man die Windows internen Firewall überprüft das die überhaupt Pakete aus dem internen OVPN Netzwerk zulässt ! Tut sie das nicht is nix mit VPN ! Entsprechend musst du das WIN Firewall Profil checken auf dem virtuellen VPN Netzadapter !Zu 6. Der Tracert auf den Client z.B. Auf die 192.168.10.1 liefert nur eine Zeitüberschreitung
Ist klar und auch zu erwarten wenn die Route auf dem Router fehlt und/oder die lokale Firewall nicht customized wurde !Lies das o.a. Tutorial und die Folgethreads dort ist alles explizit erklärt !
Nochwas:
OVPN rät dringenst davon ab TCP als Tunnel Encapsulation zu benutzen und zwar aus Performance Gründen. Besser du belässt es dann bei UDP !
Das obige Port Forwarding im Router usw. mit UDP 1194 (Default Port OVPN) würde für dich dann UDP 443 lauten. Oder TCP wenn du es dennoch damit machen willst !
noch als Ergänzung zu @aqui 's Angaben
An deiner Routing-Tabelle auf dem Client siehst du warum dein Traffic nicht über das VPN läuft:
der zweite DefaultGW für das VPN hat eine größere Metrik (30) als die deines lokalen Routers(20), deswegen wird der lokale Router bevorzugt und der Traffic läuft nicht übers VPN...
btw. die Maske ist auch nicht ganz koscher.
An deiner Routing-Tabelle auf dem Client siehst du warum dein Traffic nicht über das VPN läuft:
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.13 20
0.0.0.0 128.0.0.0 192.168.10.9 192.168.10.10 30
btw. die Maske ist auch nicht ganz koscher.
An den Portforwarding liegt es nicht. Ich kann auch ohne Probleme von meinem Server auf den Client pingen. Nur der umgekehrte Weg funktioniert nicht, obwohl ich jetzt auch die Ports für das ICMP geöffnet habe.
Mein Tunnelport ist auch wie schon erwähnt 443 TCP.
Kann ich in meiner Serverkonfig eine Metrik angegeben?
Mein Tunnelport ist auch wie schon erwähnt 443 TCP.
Kann ich in meiner Serverkonfig eine Metrik angegeben?
Nur der umgekehrte Weg funktioniert nicht, obwohl ich jetzt auch die Ports für das ICMP geöffnet habe.
Zu 98% ein Problem der lokalen Windows Firewall auf dem Client:http://social.technet.microsoft.com/Forums/windows/en-US/b9cd4de4-274e- ...
Die lokale Client Firewall blockt dennoch ICMP Traffic. Vermutlich weil das Profil nicht stimmt ?!
Beachte auch den Einwand vom Kollegen colinardo. Irgendwas stimmt in deiner Server Konfig diesbezüglich auch nicht, denn es sollte nur eine Default Route geben !
Kann ich in meiner Serverkonfig eine Metrik angegeben?
Die braucht es nicht ! Alles was in deiner Server Konfig Datei stehen muss ist das: port 443
proto udp
dev tun0 (oder tap bei Windows !)
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
server 172.16.2.0 255.255.255.0(Internes OVPN IP Netz, Muss unterschiedlich zum lokalen Netz sein !!)
push "route 192.168.0.0 255.255.255.0" (Lokales LAN IP Netz)
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
Ok habe die Virutelle VPN Schnittstelle für Client und Server wie in deinen Link von der Firewall ausgeschlossen. Ping vom Client auf Server funktioniert dennoch nicht
Muss unter Windows der dev tap modus genutzt werden? Vlt liegt hier der Hunde begraben. Client und Server sind bei Win8 PC's und verwenden beide dev tun.
Muss unter Windows der dev tap modus genutzt werden? Vlt liegt hier der Hunde begraben. Client und Server sind bei Win8 PC's und verwenden beide dev tun.
Zitat von @Julian57:
Muss unter Windows der dev tap modus genutzt werden? Vlt liegt hier der Hunde begraben. Client und Server sind bei Win8 PC's und verwenden beide dev tun.
Nein das ist kein Muss. Ich vermute eher das du den OpenVPN Client nicht als Admin gestartet hast, dann sind solche Probleme vorprogrammiert, und Windows kann hier das Gateway und das virtuelle Tunnelinterface nicht korrekt setzen !! Sollte wieder erwarten das Gateway des VPN keine niedrigere Metrik als des des lokalen LANs erhalten bzw. die bestehende DefaultRoute nicht ersetzt werden (die Fälle gibt's), dann trage folgendes in die Client-Config einMuss unter Windows der dev tap modus genutzt werden? Vlt liegt hier der Hunde begraben. Client und Server sind bei Win8 PC's und verwenden beide dev tun.
route 0.0.0.0 0.0.0.0 vpn_gateway 2Halte dich ansonsten an die Anleitung unter Windows: http://www.tecchannel.de/netzwerk/lan/2027706/workshop_openvpn_auf_eine ...
Dann läuft das wie geschmiert.
Grüße Uwe
Hi,
Da ist nicht zufällige ein UMTS im Spiel ?
Gruß orcape
Ping vom Client auf Server funktioniert dennoch nicht
..dann erzähle uns doch mal, wie Dein Client ins Internet gelangt.Da ist nicht zufällige ein UMTS im Spiel ?
Gruß orcape
Zum Thema OpenVPN Client und Adminrechte:
http://www.heise.de/ct/hotline/OpenVPN-ohne-Admin-Rechte-320656.html
Besser also den immer mit Adminrechten starten !
Wenns wirklich UMTS ist droht das hier bei einem billigen "nur Surf Account" mit privaten RFC 1918 IP Adressen auf Providerseite:
VPN über webn walk Stick IV nicht mehr möglich
Auch das musst du beachten !
Ist das der Fall kann der Client aber generel keinerlei Verbindung zum Server aufnehmen. Das kannst du im Client Log ja auch problemlos sehen wenn der Client sich einwählt.
http://www.heise.de/ct/hotline/OpenVPN-ohne-Admin-Rechte-320656.html
Besser also den immer mit Adminrechten starten !
Wenns wirklich UMTS ist droht das hier bei einem billigen "nur Surf Account" mit privaten RFC 1918 IP Adressen auf Providerseite:
VPN über webn walk Stick IV nicht mehr möglich
Auch das musst du beachten !
Ist das der Fall kann der Client aber generel keinerlei Verbindung zum Server aufnehmen. Das kannst du im Client Log ja auch problemlos sehen wenn der Client sich einwählt.
So zuerstmal habe ich am Client Adminrechte und führe das OpenVPNGUI auch mit Adminrechten aus. Das gleiche gilt für den Server.
Der Client steht hinter einer normalen DSL-Leitung, kein UMTS.
Das funktioniert zwar, allerdings komme ich nach den Trennen der VPN-Verbindung ohne neusetzen der Routen bzw. einen Neustart nicht mehr ins Internet. Außerdem habe ich kein Zugriff auf meinen Lokales Netz hinter dem VPN im 192.168.2.0 Netz.
Ich hab noch mal ne andere Serverconfig eingestellt
Diese hat aber auch nicht funktioniert.
Woran genau liegt das den jetzt?
Der Client steht hinter einer normalen DSL-Leitung, kein UMTS.
Sollte wieder erwarten das Gateway des VPN keine niedrigere Metrik als des des lokalen LANs erhalten bzw. die bestehende DefaultRoute nicht
ersetzt werden (die Fälle gibt's), dann trage folgendes in die Client-Config ein
und entferne das Pushing des DefaultGWs aus der Server-Config.
ersetzt werden (die Fälle gibt's), dann trage folgendes in die Client-Config ein
> route 0.0.0.0 0.0.0.0 vpn_gateway 2
> Das funktioniert zwar, allerdings komme ich nach den Trennen der VPN-Verbindung ohne neusetzen der Routen bzw. einen Neustart nicht mehr ins Internet. Außerdem habe ich kein Zugriff auf meinen Lokales Netz hinter dem VPN im 192.168.2.0 Netz.
Ich hab noch mal ne andere Serverconfig eingestellt
push "redirect-gateway"
push "route 0.0.0.0 0.0.0.0"
push "route 192.168.10.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0" Woran genau liegt das den jetzt?
push "route 192.168.10.0 255.255.255.0"
die ist ja auch Überflüssig, denn dieses Netz kennt der Client ja schon durch die Verbindung.Keine Ahnung woran es jetzt noch liegen könnte. Läuft hier so einwandfrei auch mit WIN8.1 Clients. Vermutlich hast du schon zu viel verkonfiguriert. Starte nochmal neu und halte dich an oben gelistete Anleitungen. Ansonsten stimmt etwas mit deinem OS nicht, evt. Netzwerkkartentreiber etc. pp
Könnte es evtl. damit zusammenhängen, das ich IP-Forwarding eingestellt habe unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter = 1.
Zitat von @Julian57:
Könnte es evtl. damit zusammenhängen, das ich IP-Forwarding eingestellt habe unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter = 1.
wo...auf dem Server oder auf dem Client ?Könnte es evtl. damit zusammenhängen, das ich IP-Forwarding eingestellt habe unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter = 1.
Auf dem Server reicht hier der Start des RAS-Dienstes. Auf dem Client hat der Eintrag eigentlich nichts verloren.
Wenn Du 192.168.10.0/24 als OVPN-Netz verwendest und Du kein Multiclientnetz betreibst, sollte normalerweise die 192.168.10.1 für den VPN-Server und die 192.168.10.2 für den Client in der Routing-Tabelle erscheinen.
Dann sollte sich auch der Server vom einzelnen Client aus pingen lassen.
Das gleiche gilt für das ServerLAN 192.168.2.0/24, auch dieses sollte sich vom Client aus pingen lassen.
Es gibt übrigens noch andere private Netzbereiche, die man für den Tunnel einsetzen kann, dies sollte das ganze etwas übersichtlicher gestalten...
Gruß orcape
Dann sollte sich auch der Server vom einzelnen Client aus pingen lassen.
Das gleiche gilt für das ServerLAN 192.168.2.0/24, auch dieses sollte sich vom Client aus pingen lassen.
Es gibt übrigens noch andere private Netzbereiche, die man für den Tunnel einsetzen kann, dies sollte das ganze etwas übersichtlicher gestalten...
Gruß orcape
Auf den Server. Hab das aber wieder umgestellt und neugestartet. Das brachte keine Änderung.
Ich habe nun mal das Tunneln komplett rausgenommen. Und pushe nur noch die Route in mein Lan per push "route 192.168.2.0 255.255.255.0".
Leider bekomme ich so immernoch keinen Zugriff auf mein lokales Netz.
Ich habe nun mal das Tunneln komplett rausgenommen. Und pushe nur noch die Route in mein Lan per push "route 192.168.2.0 255.255.255.0".
Leider bekomme ich so immernoch keinen Zugriff auf mein lokales Netz.
Leider bekomme ich so immernoch keinen Zugriff auf mein lokales Netz.
Bekommst du denn Zugriff auf den OVPN Server ?? Bzw. kannst du dessen interne OVPN IP Adresse anpingen und auch dessen LAN IP Adresse in deinem lokalen Netz ??Das muss in jedem Falle funktionieren !!!
Das du keinen Zugriff auf andere Komponenten im lokalen LAN bekommst ist klar und kann 2 Gründe haben die immer und immer wieder falsch gemacht werden bei solchen Threads hier:
1.)
Alle anderen Komponenten im lokalen Netzwerk haben den dortigen Internet Router als Default Gateway eingetragen !
Kommt jetzt ein Ping oder ein Datenpaket von deinem OVPN Client an einem solchen lokalen Endgerät an, dann ist die Absender IP Adresse die aus dem internen OVPN Netz (also die IP die in der Server Konfig Datei z.B. mit "server 172.16.2.0 255.255.255.0" definiert ist !).
Das lokale Endgerät will Antworten natürlich an diese IP senden und da das ja keine lokale IP ist sendet es diese dann an sein Default Gateway, sprich den Internet Router !
Hat dieser jetzt aber keine zusätzliche statische Route auf den OVPN Server wie oben schon bemerkt wurde, dann landet dieses Paket beim Internet Provider und der schmeisst es in den lokalen Daten Mülleimer. Fazit: VPN klappt nicht !
2.)
Dadurch das alle Client VPN Pakete eben mit einer fremden IP im lokalen LAN ankommen blockt diese die lokale Firewall der Endgeräte sofern diese vorhanden ist. Alle lokalen Firewalls müssen also angepasst werden entweder im Profil (privates Profil) oder in den Regeln.
Passiert das nicht bleiben die Pakete in der Firewall hängen. Das kann, sofern man Winblows als OS auf dem OVPN Server einsetzt, auch dort passieren ! Ebenso wenn man externe Firewall SW ala Kaspersky oder Norton und anderen solchen Müll installiert hat. Zu 98% ist das hier immer die Ursache.
Sinnvoll wäre mal wenn dein Client sich verbunden hat das du mal das OVPN Client Log hier postest, damit wir überhaupt erstmal sehen können ob es tatsächlich eine korrekte Verbindung auf den Server gibt oder du das nur glaubst ?!
Dann wäre ein route print bei aktiv eingewähltem OVPN Client mal hilfreich um mal zusehen ob die Route sauber auf den Client gepusht wird und wie die interne IP Adresse des Servers lautet.
Diese MUSS immer pingbar sein vom Client wenn die VPN Verbindung wirklich erfolgreich ist !!
Die OVPN Server Konfig deines Servers wäre auch mal hilfreich !
Hast du auf dem Client das entsprechende Client GUI installiert ??
http://openvpn.se/download.html
In den dortigen HowTos findest du auch entsprechende Tips zum Betrieb.
Bekommst du denn Zugriff auf den OVPN Server ?? Bzw. kannst du dessen interne OVPN IP Adresse anpingen und auch dessen LAN IP
Adresse in deinem lokalen Netz ??
Das muss in jedem Falle funktionieren !!!
Adresse in deinem lokalen Netz ??
Das muss in jedem Falle funktionieren !!!
Bislang funktioniert nur der Ping vom Server auf den Clienten, wenn die VPN Verbindung aufgebaut ist. Andersherum prüfe ich sobald ich wieder einen Rechner außerhalb meines Netzwerkes zufassen bekomme mit komplett deaktivierten Firewall. Dann poste ich auch mal das Client und Serverlog. Serverkonfig ist ja oben. Route print folgt ebenfalls.
Das du keinen Zugriff auf andere Komponenten im lokalen LAN bekommst ist klar und kann 2 Gründe haben die immer und immer
wieder falsch gemacht werden bei solchen Threads hier:
1.)
Alle anderen Komponenten im lokalen Netzwerk haben den dortigen Internet Router als Default Gateway eingetragen !
Kommt jetzt ein Ping oder ein Datenpaket von deinem OVPN Client an einem solchen lokalen Endgerät an, dann ist die Absender
IP Adresse die aus dem internen OVPN Netz (also die IP die in der Server Konfig Datei z.B. mit "server 172.16.2.0
255.255.255.0" definiert ist !).
Das lokale Endgerät will Antworten natürlich an diese IP senden und da das ja keine lokale IP ist sendet es diese dann
an sein Default Gateway, sprich den Internet Router !
Hat dieser jetzt aber keine zusätzliche statische Route auf den OVPN Server wie oben schon bemerkt wurde, dann landet
dieses Paket beim Internet Provider und der schmeisst es in den lokalen Daten Mülleimer. Fazit: VPN klappt nicht !
Klingt logisch. Leider kann mein Hauptrouter keine manuellen statische Routen.wieder falsch gemacht werden bei solchen Threads hier:
1.)
Alle anderen Komponenten im lokalen Netzwerk haben den dortigen Internet Router als Default Gateway eingetragen !
Kommt jetzt ein Ping oder ein Datenpaket von deinem OVPN Client an einem solchen lokalen Endgerät an, dann ist die Absender
IP Adresse die aus dem internen OVPN Netz (also die IP die in der Server Konfig Datei z.B. mit "server 172.16.2.0
255.255.255.0" definiert ist !).
Das lokale Endgerät will Antworten natürlich an diese IP senden und da das ja keine lokale IP ist sendet es diese dann
an sein Default Gateway, sprich den Internet Router !
Hat dieser jetzt aber keine zusätzliche statische Route auf den OVPN Server wie oben schon bemerkt wurde, dann landet
dieses Paket beim Internet Provider und der schmeisst es in den lokalen Daten Mülleimer. Fazit: VPN klappt nicht !
Allerdings betreibe ich noch einen zweiten Router im Access-Point Modus, dieser könnte die statische Routen. Allerdings bekommt dieser, wenn ich den AP-Modus deaktivierte und diesen in ein neues Subnetz auslagere das NAT nicht auf die Reihe. Ich komme zwar auf den Router drauf die eingestellte Route für das VPN sollte auch funktionieren allerdings komme ich nicht auf meinen Hauptrouter und ins Internet, bzw. das DNS mag überhaupt nicht funktionieren.
Nochmal übersichtlicher
Internet --> Hauptrouter 1 --> Router 2 (kann stat. Routen)----------------------------------> VPN Server
WAN IP --> 192.168.2.1/24 --> WAN-IP 192.168.2.222/24 LAN-IP192.168.3.1/24 --> 192.168.3.10/24
DNS 192.168.2.1-----------------------------------------------------192.168.3.1
Woherher war der Router 2 im AP-Modus natürlich nicht über den WAN Port sondern über den normalen LAN Port verbunden.
Auf der VPN gibt der Nslookup immer einen Timeout. Ping auf den Router 2 funktioniert allerdings.
Vom Router 2 funktioniert der Ping auf Router 1.
Ich bin hier gerade im Moment ratlos wieso Router 2 meine Anfragen nicht an Router 1 weiterleitet.
Hast du auf dem Client das entsprechende Client GUI installiert ??
Jop.Ich bin hier gerade im Moment ratlos wieso Router 2 meine Anfragen nicht an Router 1 weiterleitet.
ist doch klar wenn du auf dem zweiten Router kein NAT machst, is Ende Gelände, da dein 1-Router keine st. Routen kann.Btw. ein Router der keine statischen Routen erstellen kann solltest du in die Tonne kloppen, der hat die Bezeichnung Router absolut nicht verdient!
Es wird so langsam mal Zeit für die Routing-Grundlagen: http://openbook.galileocomputing.de/linux/linux_kap15_003.html
Leider kann mein Hauptrouter keine manuellen statische Routen.
Uhhh ein billiger Schrott Speedport vermutlich. Kollege colinardo hat alles Wesentlich oben schon dazu gesagt. Dem ist nichts hinzuzufügen !Das ist per se schlecht und damit wirds dann nix mit deinem VPN wenn du den Router nicht tauschst.
Es gibt dann nur einen umstaändlichen Workaround das du auf jedem Endgerät was du per VPN erreichen musst einzeln eine statische Route eintragen musst !
Bei Winblows ist das z.B.:
route add <Zielnetzwerk> <Maske_Zielnetz> <Next_Hop_Gateway_IP> -p
Megaumständlich....
Besser du tauschst deinen Router. Statische Routen kann jeder 30 Euro Baumarktrouter heutzutage.
Allerdings betreibe ich noch einen zweiten Router im Access-Point Modus
Das nützt natürlich rein gar nix, denn der routet ja so nicht mehr !Fragt sich allerdings WIE du ihn konfiguriert hast.
Er sollte als reiner AP so wie hier in der Alternative 3 beschrieben konfiguriert sein:
Kopplung von 2 Routern am DSL Port
Bei dir sieht das etwas nach einer Router Kaskade aus (Alternative 2) im o.a. Tutorial. Damit könnte es dann gehen wenn der 2te Router NAT macht.
Gravierender Nachteil: Du musst 2mal ein Port Forwarding machen, damit dein externer VPN Tunnel aufgebaut wird zum Server.
Manche Router mögen diese 2 Stufen nicht...musst du probieren.
Das Beste wäre wenn der 2te AP Router eine Plattform wäre wo DD-WRT oder OpenWRT drauf laufen würde, dann könnte man den ganzen Murks vergessen und auf diesem 2ten Router den OVPN Server installieren wie im o.a. Tutorial beschrieben.
Alternativ kann das ein 30 Euro Mikrotik oder ein 20 Euro TP-Link 841N mit OpenWRT. Da ist dann schon alles drauf und man spart erheblich Energie (Strom) und kann sich die Port Forwarding Fricklei und den separaten OVPN Server sparen.
Oder du steckst in deinen OVPN Server eine 2te Netzwerkkarte und lässt ihn zusätzlich Router spielen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Technisch die sinnvollste Lösung. Mit einem Router als OVPN Server auch noch sparsam mit 15 Euro Strom im Jahr.
Es gibt dann nur einen umstaändlichen Workaround das du auf jedem Endgerät was du per VPN erreichen musst
einzeln eine statische Route eintragen musst !
Wäre das auch nötig, wenn ich wie in Alternative 2 wie du beschrieben hast konfiguriere.einzeln eine statische Route eintragen musst !
Er sollte als reiner AP so wie hier in der Alternative 3 beschrieben konfiguriert sein:
genauso sah es vor aus, bzw jetzt nachdem ich es wieder zurück konfiguriert habe.Bei dir sieht das etwas nach einer Router Kaskade aus (Alternative 2) im o.a. Tutorial. Damit könnte es dann gehen wenn
der 2te Router NAT macht.
Werd ich mal ausprobieren.NAT sollte er eigentlich können. Es handelt sich um einen DLink 636Lder 2te Router NAT macht.
Gravierender Nachteil: Du musst 2mal ein Port Forwarding machen, damit dein externer VPN Tunnel aufgebaut wird zum Server.
Manche Router mögen diese 2 Stufen nicht...musst du probieren.
War mir vorhin schon klar, als ich den Versuch unternommen habe den AP als Gateway einzurichten.Manche Router mögen diese 2 Stufen nicht...musst du probieren.
Wäre das auch nötig, wenn ich wie in Alternative 2 wie du beschrieben hast konfiguriere.
Nein, denn dann kann der kaskadierte 2te Router ja dann hoffentlich statische Routen und dein Problem ist gelöst !NAT sollte er eigentlich können. Es handelt sich um einen DLink 636L
Das D-Link Billigteil kann nur NAT am WAN Port ! Das NAT ist nicht abschaltbar dort, deshalb kannst du da per se nichts falsch machen.Den dann so anschliessen:
(Internet)===(Router1:LAN-Port,192.168.2.1/24)===Patchkabel===(WAN-Port,192.168.2.222/24:Router-2:LAN-Port,192.168.3.1/24)===
===(Lokales LAN 192.168.3.0 /24)
Die 636 Gurke supportet kein DD-WRT oder OpenWRT, das kann nur der 615 und 6120. Du musst also mit der D-Link Firmware leben die aber ja nicht unbedingt schlecht ist.
Aktuellstes Firmware Image solltest du aber besser flashen bei D-Link.
Den dann so anschliessen:
(Internet)===(Router1:LAN-Port,192.168.2.1/24)===Patchkabel===(WAN-Port,192.168.2.222/24:Router-2:LAN-Port,192.168.3.1/24)===
===(Lokales LAN 192.168.3.0 /24)
ist dann das DMZ auf Router 1 nötig.(Internet)===(Router1:LAN-Port,192.168.2.1/24)===Patchkabel===(WAN-Port,192.168.2.222/24:Router-2:LAN-Port,192.168.3.1/24)===
===(Lokales LAN 192.168.3.0 /24)
Ich habs ja wie oben aufgebaut schon probiert und hatte dann Probleme im Netz 192.168.3.0 einen Nslookup zu machen, da mein DNS Server die 192.168.3.1 einen Timeout lieferte.
Wie meinst du das "nötig". Ist ja nur ein Verbindungskabel. Die IP Adressierung ist schon nötig.
Die Frage ist jetzt irgendwie unverständlich...?!
Das es fehlschlägt zeigt das du einen Fehler in der Konfig des Routers 2 gemacht hast und zwar im Setting der statischen IP am WAN Port von Router 2.
Dort wirst du nach...
So einfach ist das !
Die Frage ist jetzt irgendwie unverständlich...?!
da mein DNS Server die 192.168.3.1
Ist ja auch falsch, denn der DNS Server (Proxy) ist ja der 192.168.2.1Das es fehlschlägt zeigt das du einen Fehler in der Konfig des Routers 2 gemacht hast und zwar im Setting der statischen IP am WAN Port von Router 2.
Dort wirst du nach...
- IP Adresse = 192.168.2.222
- Maske = 255.255.255.0
- Gateway = 192.168.2.1
- DNS Server = 192.168.2.1
So einfach ist das !
So einfach ist das !
Offentsichtlich nicht, da ich den DNS am WAN auch gesetzt habe.Die Verbindung zwischen Router 1 und 2 hab ich per Ping getestet. Ebenso die Verbindung Client und Router 2. Die Namensauflösung auf den Client durch Router 2 mittels nslookup lieferte aber immer einen Timeout. Das hab ich nun schon 3x beschrieben...
