julian57
Sep 20, 2014, updated at 10:09:09 (UTC)
view8000
view25
0
Goto Top

OpenVPN Server aufsetzen Routing ins Internet klappt bisher nicht

GermanQuestionRouters, RoutingNetworks
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.
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 . . . . . . . : Aktiviert

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.
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 3

Gut 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 . . . . . . . : Aktiviert
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
 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}
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 249745

Url: https://administrator.de/contentid/249745

Printed on: April 23, 2024 at 12:04 o'clock

25 Comments
Latest comment
Goto Top
Member: colinardo
colinardo Sep 20, 2014 updated at 11:10:22 (UTC)
Goto Top
Moin,
dazu wurde in diesem Thread schon so ziemlich alles erläutert face-wink
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
Member: Julian57
Julian57 Sep 20, 2014 updated at 11:53:27 (UTC)
Goto Top
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:
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
Member: aqui
aqui Sep 20, 2014 updated at 13:12:52 (UTC)
Goto Top
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:
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 !
Member: colinardo
colinardo Sep 20, 2014 updated at 13:36:23 (UTC)
Goto Top
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:
 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 
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.
Member: Julian57
Julian57 Sep 20, 2014 updated at 13:53:04 (UTC)
Goto Top
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?
Member: aqui
aqui Sep 20, 2014 updated at 13:59:44 (UTC)
Goto Top
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
Member: Julian57
Julian57 Sep 20, 2014 at 13:59:49 (UTC)
Goto Top
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.
Member: colinardo
colinardo Sep 21, 2014 updated at 08:44:19 (UTC)
Goto Top
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 ein
route 0.0.0.0 0.0.0.0 vpn_gateway 2
und entferne das Pushing des DefaultGWs aus der Server-Config.

Halte 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
Member: orcape
orcape Sep 21, 2014 at 08:45:08 (UTC)
Goto Top
Hi,
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
Member: aqui
aqui Sep 21, 2014 updated at 09:36:46 (UTC)
Goto Top
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.
Member: Julian57
Julian57 Sep 21, 2014 at 09:47:29 (UTC)
Goto Top
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.

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
> route 0.0.0.0 0.0.0.0 vpn_gateway 2
>
und entferne das Pushing des DefaultGWs aus der Server-Config.

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"
Diese hat aber auch nicht funktioniert.

Woran genau liegt das den jetzt?
Member: colinardo
colinardo Sep 21, 2014 updated at 10:34:57 (UTC)
Goto Top
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
Member: Julian57
Julian57 Sep 21, 2014 at 10:42:23 (UTC)
Goto Top
Könnte es evtl. damit zusammenhängen, das ich IP-Forwarding eingestellt habe unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter = 1.
Member: colinardo
colinardo Sep 21, 2014 updated at 11:19:58 (UTC)
Goto Top
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 ?
Auf dem Server reicht hier der Start des RAS-Dienstes. Auf dem Client hat der Eintrag eigentlich nichts verloren.
Member: orcape
orcape Sep 21, 2014 at 11:19:42 (UTC)
Goto Top
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...face-wink
Gruß orcape
Member: Julian57
Julian57 Sep 21, 2014 at 11:29:51 (UTC)
Goto Top
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.
Member: aqui
aqui Sep 21, 2014 updated at 15:39:02 (UTC)
Goto Top
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.
Member: Julian57
Julian57 Sep 22, 2014 updated at 16:53:24 (UTC)
Goto Top
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 !!!

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.
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.
Member: colinardo
colinardo Sep 22, 2014 updated at 17:04:02 (UTC)
Goto Top
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
Member: aqui
aqui Sep 22, 2014 updated at 17:08:18 (UTC)
Goto Top
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. face-sad
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.
Member: Julian57
Julian57 Sep 22, 2014 at 18:10:43 (UTC)
Goto Top
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.
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 636L
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.
Member: aqui
aqui Sep 23, 2014 updated at 08:48:02 (UTC)
Goto Top
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.
Member: Julian57
Julian57 Sep 23, 2014 at 14:01:19 (UTC)
Goto Top
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.

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.
Member: aqui
aqui Sep 23, 2014 updated at 16:56:11 (UTC)
Goto Top
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...?!
da mein DNS Server die 192.168.3.1
Ist ja auch falsch, denn der DNS Server (Proxy) ist ja der 192.168.2.1
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...
  • IP Adresse = 192.168.2.222
  • Maske = 255.255.255.0
  • Gateway = 192.168.2.1
  • DNS Server = 192.168.2.1
gefragt und Letzteres hast du NICHT eingetragen, deshalb kann der Router 2 auch nicht als Proxy arbeiten (weil er den Upstream DNS nicht kennt !) und deshalb schlägt auch dein nslookup fehl.
So einfach ist das !
Member: Julian57
Julian57 Sep 23, 2014 at 19:45:09 (UTC)
Goto Top
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...
GermanQuestionRouters, RoutingNetworks
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 5 CommentsjstrickerWireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 CommentsAlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment