Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

OpenVPN Server aufsetzen Routing ins Internet klappt bisher nicht

Frage Netzwerke Router & Routing

Mitglied: Julian57

Julian57 (Level 1) - Jetzt verbinden

20.09.2014, aktualisiert 12:09 Uhr, 2858 Aufrufe, 25 Kommentare

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.
01.
Ethernet-Adapter MyTap: 
02.
 
03.
   Verbindungsspezifisches DNS-Suffix:  
04.
   Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9 
05.
   Physische Adresse . . . . . . . . : 00-FF-E2-D8-30-11 
06.
   DHCP aktiviert. . . . . . . . . . : Ja 
07.
   Autokonfiguration aktiviert . . . : Ja 
08.
   Verbindungslokale IPv6-Adresse  . : fe80::e1e7:ade8:b988:3b75%20(Bevorzugt)  
09.
   IPv4-Adresse  . . . . . . . . . . : 192.168.10.1(Bevorzugt)  
10.
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252 
11.
   Lease erhalten. . . . . . . . . . : Samstag, 20. September 2014 03:47:22 
12.
   Lease l„uft ab. . . . . . . . . . : Sonntag, 20. September 2015 03:47:22 
13.
   Standardgateway . . . . . . . . . :  
14.
   DHCP-Server . . . . . . . . . . . : 192.168.10.2 
15.
   DHCPv6-IAID . . . . . . . . . . . : 318832610 
16.
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-9D-06-BE-C0-3F-D5-6C-32-FC 
17.
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1 
18.
                                       fec0:0:0:ffff::2%1 
19.
                                       fec0:0:0:ffff::3%1 
20.
   NetBIOS ber TCP/IP . . . . . . . : Aktiviert 
21.
 
22.
Ethernet-Adapter Ethernet: 
23.
 
24.
   Verbindungsspezifisches DNS-Suffix:  
25.
   Beschreibung. . . . . . . . . . . : Controller der Familie Realtek PCIe GBE 
26.
   Physische Adresse . . . . . . . . : C0-3F-D5-6C-32-FC 
27.
   DHCP aktiviert. . . . . . . . . . : Nein 
28.
   Autokonfiguration aktiviert . . . : Ja 
29.
   IPv4-Adresse  . . . . . . . . . . : 192.168.2.120(Bevorzugt)  
30.
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0 
31.
   Standardgateway . . . . . . . . . : 192.168.2.1 
32.
   DNS-Server  . . . . . . . . . . . : 192.168.2.1 
33.
   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.
01.
port 443 #change to any port you see fit. The client needs to use the same port 
02.
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 
03.
dev tun 
04.
dev-node MyTap #name of your TAP interface. 
05.
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. 
06.
 
07.
ca ca.crt 
08.
cert server.crt 
09.
key server.key  # This file should be kept secret 
10.
dh dh1024.pem 
11.
ifconfig-pool-persist ipp.txt 
12.
 
13.
push "redirect-gateway def1" #tells all Internet traffic to go through the tunnel 
14.
push "dhcp-option DNS 208.67.222.222" #OpenDNS servers, makes it easy to check if the tunnel is working properly 
15.
push "dhcp-option DNS 208.67.220.220" 
16.
push "route 192.168.2.0 255.255.255.0" 
17.
keepalive 10 120 
18.
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. 
19.
persist-key 
20.
persist-tun 
21.
 
22.
user nobody 
23.
group nogroup 
24.
status openvpn-status.log 
25.
verb 3
Gut nun kommen wir zur Client-Konfiguration.
01.
client 
02.
dev tun 
03.
dev-node MyTap #Name of your TAP network interface 
04.
proto tcp #switch to tcp if you wish to use a tcp connection, needs to match server. udp gives better performance 
05.
remote meinddns.dlinkddns.com 443 #ddns wegen veröffentlichung angepasst 
06.
 
07.
resolv-retry infinite 
08.
nobind 
09.
persist-key 
10.
persist-tun 
11.
 
12.
ca ca.crt 
13.
cert client1.crt 
14.
key client1.key 
15.
ns-cert-type server 
16.
 
17.
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. 
18.
verb 3 
19.
ping 10 
20.
ping-restart 60 
21.
 
22.
route-metric 512 
23.
route 0.0.0.0 0.0.0.0 
Nach erfolgreichen Verbinden zum VPN sieht dort die IP-Konfig wie folgt aus.
01.
Ethernet-Adapter MyTap: 
02.
 
03.
   Verbindungsspezifisches DNS-Suffix:  
04.
   Beschreibung. . . . . . . . . . . : TAP-Windows Adapter V9 
05.
   Physische Adresse . . . . . . . . : 00-FF-AB-4D-5C-91 
06.
   DHCP aktiviert. . . . . . . . . . : Ja 
07.
   Autokonfiguration aktiviert . . . : Ja 
08.
   Verbindungslokale IPv6-Adresse  . : fe80::3d10:1176:3474:1496%7(Bevorzugt)  
09.
   IPv4-Adresse  . . . . . . . . . . : 192.168.10.10(Bevorzugt)  
10.
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252 
11.
   Lease erhalten. . . . . . . . . . : Samstag, 20. September 2014 11:58:16 
12.
   Lease l„uft ab. . . . . . . . . . : Sonntag, 20. September 2015 11:58:16 
13.
   Standardgateway . . . . . . . . . : 192.168.10.9 
14.
   DHCP-Server . . . . . . . . . . . : 192.168.10.9 
15.
   DHCPv6-IAID . . . . . . . . . . . : 184614827 
16.
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-2C-C2-4D-BC-EE-7B-5C-BA-F0 
17.
   DNS-Server  . . . . . . . . . . . : 192.168.10.1 
18.
   NetBIOS ber TCP/IP . . . . . . . : Aktiviert 
19.
 
20.
Ethernet-Adapter Ethernet: 
21.
 
22.
   Verbindungsspezifisches DNS-Suffix:  
23.
   Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller 
24.
   Physische Adresse . . . . . . . . : BC-EE-7B-5C-BA-F0 
25.
   DHCP aktiviert. . . . . . . . . . : Ja 
26.
   Autokonfiguration aktiviert . . . : Ja 
27.
   Verbindungslokale IPv6-Adresse  . : fe80::5439:147d:d386:7ff1%3(Bevorzugt)  
28.
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.13(Bevorzugt)  
29.
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0 
30.
   Lease erhalten. . . . . . . . . . : Samstag, 20. September 2014 11:36:42 
31.
   Lease l„uft ab. . . . . . . . . . : Sonntag, 21. September 2014 11:36:42 
32.
   Standardgateway . . . . . . . . . : 192.168.0.1 
33.
   DHCP-Server . . . . . . . . . . . : 192.168.0.1 
34.
   DHCPv6-IAID . . . . . . . . . . . : 62713467 
35.
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-2C-C2-4D-BC-EE-7B-5C-BA-F0 
36.
   DNS-Server  . . . . . . . . . . . : 8.8.4.4 
37.
   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
01.
 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 
02.
Sat Sep 20 12:08:14 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 
03.
Sat Sep 20 12:08:14 2014 Need hold release from management interface, waiting... 
04.
Sat Sep 20 12:08:14 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 
05.
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'state on' 
06.
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'log all on' 
07.
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'hold off' 
08.
Sat Sep 20 12:08:15 2014 MANAGEMENT: CMD 'hold release' 
09.
Sat Sep 20 12:08:15 2014 Socket Buffers: R=[65536->65536] S=[65536->65536] 
10.
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,RESOLVE,,, 
11.
Sat Sep 20 12:08:15 2014 Attempting to establish TCP connection with [AF_INET]88.68.172.78:443 
12.
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,TCP_CONNECT,,, 
13.
Sat Sep 20 12:08:15 2014 TCP connection established with [AF_INET]88.68.172.78:443 
14.
Sat Sep 20 12:08:15 2014 TCPv4_CLIENT link local: [undef] 
15.
Sat Sep 20 12:08:15 2014 TCPv4_CLIENT link remote: [AF_INET]88.68.172.78:443 
16.
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,WAIT,,, 
17.
Sat Sep 20 12:08:15 2014 MANAGEMENT: >STATE:1411207695,AUTH,,, 
18.
Sat Sep 20 12:08:15 2014 TLS: Initial packet from [AF_INET]88.68.172.78:443, sid=f1440dcd 665fba17 
19.
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 
20.
Sat Sep 20 12:08:15 2014 VERIFY OK: nsCertType=SERVER 
21.
Sat Sep 20 12:08:15 2014 VERIFY OK: depth=0, C=DE, ST=HE, O=SchmidtVPN, CN=server, emailAddress=mail@host.domain 
22.
Sat Sep 20 12:08:17 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 
23.
Sat Sep 20 12:08:17 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 
24.
Sat Sep 20 12:08:17 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key 
25.
Sat Sep 20 12:08:17 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 
26.
Sat Sep 20 12:08:17 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA 
27.
Sat Sep 20 12:08:17 2014 [server] Peer Connection Initiated with [AF_INET]88.68.172.78:443 
28.
Sat Sep 20 12:08:18 2014 MANAGEMENT: >STATE:1411207698,GET_CONFIG,,, 
29.
Sat Sep 20 12:08:19 2014 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) 
30.
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' 
31.
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: timers and/or timeouts modified 
32.
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: --ifconfig/up options modified 
33.
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: route options modified 
34.
Sat Sep 20 12:08:19 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified 
35.
Sat Sep 20 12:08:19 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 
36.
Sat Sep 20 12:08:19 2014 MANAGEMENT: >STATE:1411207699,ASSIGN_IP,,192.168.10.10, 
37.
Sat Sep 20 12:08:19 2014 open_tun, tt->ipv6=0 
38.
Sat Sep 20 12:08:19 2014 TAP-WIN32 device [MyTap] opened: \\.\Global\{AB4D5C91-0130-40B5-A9B7-7033E868D624}.tap 
39.
Sat Sep 20 12:08:19 2014 TAP-Windows Driver Version 9.9  
40.
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] 
41.
Sat Sep 20 12:08:19 2014 Successful ARP Flush on interface [7] {AB4D5C91-0130-40B5-A9B7-7033E868D624}
Mitglied: colinardo
20.09.2014, aktualisiert um 13:10 Uhr
Moin,
dazu wurde in diesem Thread schon so ziemlich alles erläutert
http://www.administrator.de/forum/open-vpn-server-als-internetgateway-k ...

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
Bitte warten ..
Mitglied: Julian57
20.09.2014, aktualisiert um 13:53 Uhr
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:
01.
IPv4-Routentabelle 
02.
=========================================================================== 
03.
Aktive Routen: 
04.
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik 
05.
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.13     20 
06.
          0.0.0.0        128.0.0.0     192.168.10.9    192.168.10.10     30 
07.
     88.68.172.78  255.255.255.255      192.168.0.1     192.168.0.13     20 
08.
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306 
09.
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306 
10.
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306 
11.
        128.0.0.0        128.0.0.0     192.168.10.9    192.168.10.10     30 
12.
      192.168.0.0    255.255.255.0   Auf Verbindung      192.168.0.13    276 
13.
     192.168.0.13  255.255.255.255   Auf Verbindung      192.168.0.13    276 
14.
    192.168.0.255  255.255.255.255   Auf Verbindung      192.168.0.13    276 
15.
      192.168.2.0    255.255.255.0     192.168.10.9    192.168.10.10     30 
16.
     192.168.10.1  255.255.255.255     192.168.10.9    192.168.10.10     30 
17.
     192.168.10.8  255.255.255.252   Auf Verbindung     192.168.10.10    286 
18.
    192.168.10.10  255.255.255.255   Auf Verbindung     192.168.10.10    286 
19.
    192.168.10.11  255.255.255.255   Auf Verbindung     192.168.10.10    286 
20.
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306 
21.
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.10.10    286 
22.
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.0.13    276 
23.
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306 
24.
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.10.10    286 
25.
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.0.13    276 
26.
=========================================================================== 
27.
St„ndige Routen: 
28.
  Keine
Bitte warten ..
Mitglied: aqui
20.09.2014, aktualisiert um 15:12 Uhr
Dieses Forumstutorial hast du auch gelesen ??:
http://www.administrator.de/wissen/openvpn-server-installieren-auf-dd-w ...

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 !
Bitte warten ..
Mitglied: colinardo
20.09.2014, aktualisiert um 15:36 Uhr
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.
Bitte warten ..
Mitglied: Julian57
20.09.2014, aktualisiert um 15:53 Uhr
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?
Bitte warten ..
Mitglied: aqui
20.09.2014, aktualisiert um 15:59 Uhr
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
Bitte warten ..
Mitglied: Julian57
20.09.2014 um 15:59 Uhr
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.
Bitte warten ..
Mitglied: colinardo
21.09.2014, aktualisiert um 10:44 Uhr
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
01.
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
Bitte warten ..
Mitglied: orcape
21.09.2014 um 10:45 Uhr
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
Bitte warten ..
Mitglied: aqui
21.09.2014, aktualisiert um 11:36 Uhr
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:
http://www.administrator.de/contentid/185875
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.
Bitte warten ..
Mitglied: Julian57
21.09.2014 um 11:47 Uhr
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
01.
> route 0.0.0.0 0.0.0.0 vpn_gateway 2 
02.
> 
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
01.
push "redirect-gateway" 
02.
push "route 0.0.0.0 0.0.0.0" 
03.
push "route 192.168.10.0 255.255.255.0" 
04.
push "route 192.168.2.0 255.255.255.0"
Diese hat aber auch nicht funktioniert.

Woran genau liegt das den jetzt?
Bitte warten ..
Mitglied: colinardo
21.09.2014, aktualisiert um 12:34 Uhr
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
Bitte warten ..
Mitglied: Julian57
21.09.2014 um 12:42 Uhr
Könnte es evtl. damit zusammenhängen, das ich IP-Forwarding eingestellt habe unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter = 1.
Bitte warten ..
Mitglied: colinardo
21.09.2014, aktualisiert um 13:19 Uhr
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.
Bitte warten ..
Mitglied: orcape
21.09.2014 um 13:19 Uhr
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
Bitte warten ..
Mitglied: Julian57
21.09.2014 um 13:29 Uhr
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.
Bitte warten ..
Mitglied: aqui
21.09.2014, aktualisiert um 17:39 Uhr
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.
Bitte warten ..
Mitglied: Julian57
22.09.2014, aktualisiert um 18:53 Uhr
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.
Bitte warten ..
Mitglied: colinardo
22.09.2014, aktualisiert um 19:04 Uhr
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
Bitte warten ..
Mitglied: aqui
22.09.2014, aktualisiert um 19:08 Uhr
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:
http://www.administrator.de/wissen/kopplung-von-2-routern-am-dsl-port-4 ...

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:
http://www.administrator.de/wissen/routing-mit-2-netzwerkkarten-unter-w ...
Technisch die sinnvollste Lösung. Mit einem Router als OVPN Server auch noch sparsam mit 15 Euro Strom im Jahr.
Bitte warten ..
Mitglied: Julian57
22.09.2014 um 20:10 Uhr
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.
Bitte warten ..
Mitglied: aqui
23.09.2014, aktualisiert um 10:48 Uhr
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.
Bitte warten ..
Mitglied: Julian57
23.09.2014 um 16:01 Uhr
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.
Bitte warten ..
Mitglied: aqui
23.09.2014, aktualisiert um 18:56 Uhr
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 !
Bitte warten ..
Mitglied: Julian57
23.09.2014 um 21:45 Uhr
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...
Bitte warten ..
Neuester Wissensbeitrag
Humor (lol)

Linkliste für Adventskalender

(3)

Information von nikoatit zum Thema Humor (lol) ...

Ähnliche Inhalte
Heiß diskutierte Inhalte
Windows Server
DHCP Server switchen (25)

Frage von M.Marz zum Thema Windows Server ...

SAN, NAS, DAS
gelöst HP-Proliant Microserver Betriebssystem (14)

Frage von Yannosch zum Thema SAN, NAS, DAS ...

Grafikkarten & Monitore
Win 10 Grafikkarte Crash von Software? (13)

Frage von Marabunta zum Thema Grafikkarten & Monitore ...

Windows 7
Verteillösung für IT-Raum benötigt (12)

Frage von TheM-Man zum Thema Windows 7 ...