Apr 15, 2017

2065

Openvpn Server auf DD-WRT Router hinter Cisco Modem, Client kommt nicht auf Geräte,Services im LAN - Sicherheitsbedenken, aktuelle Konstellation

Hallo Leute,

nach etwas Suchen wie ich einen Openvpn Server auf meinem Router betreibe, bin ich auf dieses Thema hier gestoßen:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Ist auch alles sehr verständlich und gut beschrieben. Von außerhalb kann ich mich auch auf den Vpn Server verbinden, allerdings erreiche ich die lokalen IP's/Geräte/Services nicht.
Meine erste Frage ist also wie ich dies bewerkstellige?

Die 2. Frage betrifft Zugriffe von außen bei meinem aktuellen Setup, besser gesagt, wie ich diese blockieren kann (außer natürlich den eigenen Zugriff via Vpn).

Ich stelle deshalb gleich beide, weil sie sich eventuell überschneiden und dementsprechend auch vllt. andere Einstellungen gewählt werden müssen.

Aber erstmal zum aktuellen Setup:
Mein ISP heißt Kabelplus, von diesem wurde ein Cisco EPC 3212 Modem bereitgestellt.
Daran hängt mein Linksys WRT-1200ac v2 Router auf welchem DD-WRT (BS Build v3.0-r31791 std 03/30/17) läuft.
Auf diesem Router habe ich lt. Tutorial den Openvpn Server eingerichtet. Im Anhang sind meine Einstellungen.

Beim Absatz: "OpenVPN hinter einem bestehenden NAT Router betreiben" habe ich gelesen:
"Im vorliegenden Router muss eine Port Weiterleitung des UDP Ports 1194.....eingetragen werden."
Gut, unwissend wie ich bin denk ich mir: Naja, ich habe zwar ein Modem welches am Inet hängt aber den Port werd ich doch trotzdem weiterleiten müssen.
Hab auch gedacht: Gut, selbst kannst du das nicht machen, da das Modem von Kabelplus ist.
Also hab ich bei meinem Provider angerufen und gebeten den Port weiterzuleiten. Nachdem ich ihm gesagt habe, dass ich das Modem von denen gewähtl hab, (gäbe auch einen Wlan Router, und neuerdings gegen monatliche Gebühr auch eine Fritzbox) sagt mir der Techniker: "Das Modem macht kein NAT und von uns aus sind alle Ports offen, nur irgendwelche Email Ports sind gesperrt, aber sicher nichts im 1000er Bereich."
Die Tragweite dieser Aussage wurde mir erst bewusst, als mir ein Freund, der sich besser mit der Thematik auskennt, sagte: "Na dann wird auch zb. das Webinterface deines Routers von außen einfach so erreichbar sein!"
Und so war es auch! Natürlich hab ich hier ein PW hinterlegt aber ich musste weiters erfahren, dass dieses in Klartext übertragen wird, da ich nicht über https zugreife(hab ich bereits geändert).
Für mich, der sich lange Zeit aus Sicherheitsbedenken geziert hat, irgendwelche Ports nach außen hin aufzumachen oder irgendwie von außen auf mein Lan zuzugreifen, war es schon ein kleiner Schock. Sagte mir immer: "Ich kenn mich da zu wenig aus, also mach ich nix in die Richtung"
Dass standardmäßig alle Ports von seiten des Providers offen sind, überraschte meinen Freund auch etwas.
Auf meine Frage, warum da der Router dann "von Haus aus" nicht alle Zugriffe von außerhalb blockiert sagte mein Freund, dass dieser ja nicht wissen kann, woher das Inet kommt/ wo es ist..
Hier schließt sich auch meine 2. Frage: Wie kann ich solche Zugriffe verhindern? Welche Einstellungen muss ich am DD-WRT Router treffen, damit dieser "weiß wo draußen/das Inet ist" und dementsprechend solche Zugriffe blockiert?

Wäre super wenn mir wer helfen könnte. Dies ist mein 1. Post hier, sollte ich etwas gravierend falsch gemacht haben, oder solltet ihr noch weitere Details benötigen lasst es mich wissen.

Please also mark the comments that contributed to the solution of the article

Content-Key: 335326

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

Printed on: April 27, 2024 at 02:04 o'clock

32 Comments

Latest comment

Hallo,

Zitat von @trohn-javolta:
Meine erste Frage ist also wie ich dies bewerkstellige?

Hast du auch der Firewall es gesagt was du willst?
NAT ist eingeschaltet?
Welches Netz wird bei dir intern verwendet? Du verwendest doch hinter dein Cisco noch ein Router der NAT macht, oder? Das ist doch dieser hier, oder?

Die 2. Frage betrifft Zugriffe von außen bei meinem aktuellen Setup, besser gesagt, wie ich diese blockieren kann (außer natürlich den eigenen Zugriff via Vpn).

Alles was du nicht explicit erlaubst ist Verboten.

Mein ISP heißt Kabelplus, von diesem wurde ein Cisco EPC 3212 Modem bereitgestellt.

Also ein sogenanntes Kabelmodem. Macht der auch VOIP oder gibt es kein VOIP?

Daran hängt mein Linksys WRT-1200ac v2 Router auf welchem DD-WRT (BS Build v3.0-r31791 std 03/30/17) läuft.

Und der ist soweit erstmal korrekt eingerichtet damit der das pöse Internet draussen hält (siehe dein Webzugriff auf dessen Webserver vom Internet aus)?

"Im vorliegenden Router muss eine Port Weiterleitung des UDP Ports 1194.....eingetragen werden."

Jo, fdas ist so wenn dein Cisco als Router arbeiten tät, aber der ist evtl. als Bridge eingerichtet und noch zusätzlich VOIP an dessen ausgänge, oder? Hier ist der Betriebsmodus entscheidend.

Gut, unwissend wie ich bin denk ich mir: Naja, ich habe zwar ein Modem welches am Inet hängt aber den Port werd ich doch trotzdem weiterleiten müssen.

Nur wenn der als Router arbeitet.

mir der Techniker: "Das Modem macht kein NAT und von uns aus sind alle Ports offen, nur irgendwelche Email Ports sind gesperrt, aber sicher nichts im 1000er Bereich."

Also eher Bridge - kein Portforwarding nötig. Aber warum sperren die als ISP diverse E-Mail Ports? Darfst du laut dennen keine mails...

"Na dann wird auch zb. das Webinterface deines Routers von außen einfach so erreichbar sein!"

Aber nur wenn du es so eingerichtet bzw. Konfiguriert hast das eben auch aus dem Internet auf dessen Webserver zugegriffen werden darf. Warum hast du das getan?

Sagte mir immer: "Ich kenn mich da zu wenig aus, also mach ich nix in die Richtung"

Nix machen kann aber das falsche sein wenn in Default solche sachen aktiv sind. Immer Kontrollieren...

Dass standardmäßig alle Ports von seiten des Providers offen sind, überraschte meinen Freund auch etwas.

Nö, warum. Wenn dein Kabelmodem tatsächlich als Modem (Bridge) fungiert ist das selbstverständlich. Ein Modem weis nichts von IPs und / oder Ports, kann daher auch keine Sperren.

sagte mein Freund, dass dieser ja nicht wissen kann, woher das Inet kommt/ wo es ist..

Eher falsch denn dein WRT1200AC hat doch einen dedizierten WAN Port und somit ist dem Blech bekannt was aussen und was innen ist (einfachst gesagt).

Hier schließt sich auch meine 2. Frage: Wie kann ich solche Zugriffe verhindern?

Alles was von ausen kommt und rein möchte wird geblockt. Punkt. Datenverkehr der von innen initiiert wurde hat einen sogenannten passierschein wenn die andefordete Antwort aus dem Internet eintrifft. Dein Blech schaut dann nach ob es jemand gab der etwas aus dem Intent wollte und lässt das rein und schreibt dazu wer es denn war damit der richtige IP/MAC zugeordnet werden kann, ansonsten wir gedroppt.

Welche Einstellungen muss ich am DD-WRT Router treffen, damit dieser "weiß wo draußen/das Inet ist" und dementsprechend solche Zugriffe blockiert?

Beim Einrichten sagtst du deinem Blech doch wer wo was finden kann und somit auch was aussen und was innen ist.

Mal dein Netz mal auf ein Blatt paier, gebe die LAN Ports an und dessen IP sowie dessen GW und dessen Subnetzmaske an und stelle das hier rein. dann sehen wir was du tatsächlich hast.

Auch dein GW (Eintrag) sollte dir sagen wo es nach draussen geht...

Gruß,
Peter

allerdings erreiche ich die lokalen IP's/Geräte/Services nicht.

Zuerst mal die allerwichtigste Frage: Arbeite der Cisco wirklich als reines Modem, sprich also hast du die offentliche Provider IP an deinem DD-WRT WAN Port ?
Oder arbeitet der Disco als Router. Also das du DD-WRT in einer Router Kaskade mit dem Cosco betreibst ?
Bei letzterem ist dann vollkommen klar, denn deine lokalen Geräte haben dann vermutlich den Router als Default Gateway und der dann vermutlich eine fehlende statische Route in des interne OVPN IP Netzwerk.

Wenn nicht dann kann es nur die lokale Firewall der lokalen Maschinen sein die du nicht entsprechend eingestellt hast. Aus dem VPN Tunnel kommst du ja mit einer fremden Adsender IP die die lokale (Windows) Firewall dann sofort blockt. Sie lässt nur Traffic aus dem lokalen Netz passieren.
Ebenso blockt sie ab Win 7 ICMP (Ping) das verhindert dann das du diese Geräte anpingen kannst:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Hast du das beachtet ??

aber den Port werd ich doch trotzdem weiterleiten müssen.

Nein, das wäre völliger Quatsch wenn es wirklich ein reines Modem von Docsis auf Ethernet ist, also ein passiver Medienwandler der NICHT aktiv am IP Paket Forwarding beteiligt ist kann man das da gar nicht konfigurieren.
Kein IP Traffic bedeutet dann natürlich auch keinerlei IP asierte Konfig Einstellungen wie Port Forwarding.
Vergiss den Blödsinn also wenn es denn wirklich ein reines Modem ist.
Du kannst das daran sehen das du am DD-WRT dann am Übersichtsmenü dir oben recht eine öffentliche IP Adresse angezeigt wird !
Dort darf KEINE private RFC 1918 IP Adresse ala 10.0.0.0 /8, 172.16.0.0 /12 oder 192.168.0.0 /16 !
Steht dort eine solche Adresse macht dein Kabelprovider DS-Lite und damit ist ein VPN dann eh unmöglich.

"Na dann wird auch zb. das Webinterface deines Routers von außen einfach so erreichbar sein!"

Das kannst du logischerweise abschlaten im DD-WRT Setup. Ansonsten blockierst du TCP 80 und 443 in der Firewall.

Auf meine Frage, warum da der Router dann "von Haus aus" nicht alle Zugriffe von außerhalb blockiert sagte mein Freund, dass dieser ja nicht wissen kann, woher das Inet kommt/ wo es ist..

Auch das ist natürlich Quatsch. Dein Freund ist vermutlich genau so ein blutiger Laie wie du auch.
Erstmal kann der Router ja nur auf Ports, sprich Dienste antworten die er selber hat. Web GUi usw.
Das kannst du aber alles abschlaten. Evenso den Telnet und den SSH Zugriif.
Vielmehr andere Dienste bedinte der Router gar nicht.
In dein internes Netz kommt keiner, denn das verhindert die NAT Firewall des Routers.

Tip: Mal ein bischen Wikipedia über Ostern lesen und sich mal nur mit den einfachsten Grundlagen von Routern und NAT (IP Adresstranslation) vertraut machen, damit du wenigstens mal weisst um was es eigentlich grindlegend geht statt in einem Administrator Forum im freien Fall rumzuraten !

sollte ich etwas gravierend falsch gemacht haben

Hört sich erstmal nicht so an.
2 Kardinalsfragen hast du zu beantworten:

1.) Ist der VPN Tunnel wirklich aktiv ?? Hast du das hier mal gemacht um das wasserdicht zu verifizieren: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router Auszug deines Server oder Client Logs was das zeigt ("Initialization Sequence Completed" oder "tunnel established" Meldung) wäre sehr hilfreich.
2.) Macht dein Provider DS-Lite ?? RFC 1918 IP am WAN Port ?
3.) Ist es bei 2. eine öffentliche IP, dann macht dein Provider KEIN DS-Lite, was gut wäre. Andernfalls nicht.

Eine vllt. wichtige Info hab ich auch noch vergessen: Auf dem Router läuft auch ein Openvpn Client, also gibts jz tun1 (client) und tun2 (server).

Diese SPI Firewall hab ich vorerst mal deaktiviert, sollte also nicht hineinpfuschen.
Hatte vor diese ganz zum Schluss zu aktivieren und dann die folgenden Regeln vom Tutorial hinzuzufügen:

# Akzeptiert eingehende Anfragen am Port UDP 1194.
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT

# Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfläche, SSH etc)
iptables -I INPUT 3 -i tun0 -j ACCEPT

# Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist. 
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT

# Erlaubt Verbindungen vom lokalen Netz ins VPN Netz und umgekehrt (br0 steht für LAN und WLAN).
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT 

Inwiefern kann ich kontrollieren ob NAT eingeschaltet ist? Im Routermenü unter NAT/QoS ist nichts eingetragen.
Brauche ich hier unter Port Weiterleitung Einträge?
Wenn ja in welcher Form? Es gibt diese Überschriften, die für mich als Laien nicht selbsterklärend sind:
Anwendung Protokoll Von Netz Von Port IP-Adresse Nach Port Einschalten

Genau, hinter dem Cisco Modem ist der Linksys Router mit dd-wrt. Welches Netz...hmm.. Ich denke du meinst den Bereich in dieser DHCP Server IP's vergibt. Start IP ist hier 192.168.1.9 u. Max. DHCP Nutzerzahl ist 50.

Also ein sogenanntes Kabelmodem. Macht der auch VOIP oder gibt es kein VOIP?

Ja genau. Puh, wie könnte ich das eruieren, ob der Voice over IP "macht"? Also im Vertrag hab ich keinen Festnetz-Telefonanschluss dabei, falls du das meinst..

Jo, fdas ist so wenn dein Cisco als Router arbeiten tät, aber der ist evtl. als Bridge eingerichtet und noch zusätzlich VOIP an dessen ausgänge, oder? Hier ist der Betriebsmodus entscheidend.

Auch da bin ich ziemlich überfragt, tut mir leid. Am Modem ist das "Koaxialkabel mit Internet" angeschlossen, vom Modem Port mit Beschriftung "Internet" geht ein LAN-Kabel weg zum Router in den Port mit Beschriftung "Internet".
Wie das Modem eingerichtet ist weiß ich nicht, mit Eingabe von 192.168.100.1 komme ich auf das Webinterface des Modems, hier kriege ich aber nicht viele Infos. Benutzer und Pw kann man eingeben, die Daten weiß ich leider nicht. "Standard Logins" wie Admin Admin funktionieren mal nicht.

Also eher Bridge - kein Portforwarding nötig. Aber warum sperren die als ISP diverse E-Mail Ports? Darfst du laut dennen keine mails...

Ja das denke ich auch. Warum irgendwelche E-Mail Ports gesperrt sind weiß ich nicht, ist mir aber auch egal....Glaube man hat standardmäßig eine Mailadresse u. kann mehrere dazukaufen?...Keine Ahnung..

Aber nur wenn du es so eingerichtet bzw. Konfiguriert hast das eben auch aus dem Internet auf dessen Webserver zugegriffen werden darf. Warum hast du das getan?

Ich wüsste echt nicht, wo ich das gemacht hätte....Im Webinterface gibt's z.B. unter Administration -> Management den Punkt Fernzugriff. Hier sind Web-GUI-Management und SSH-Management abgeschaltet...Trotzdem komm ich über die öffentliche IP hin.

Nö, warum. Wenn dein Kabelmodem tatsächlich als Modem (Bridge) fungiert ist das selbstverständlich. Ein Modem weis nichts von IPs und / oder Ports, kann daher auch keine Sperren.

Hmm... Ja, im Nachhinein leuchtets mir auch ein, dachte nur, dass der ISP solche Ports wie 22 einfach standardmäßig sperrt.

Eher falsch denn dein WRT1200AC hat doch einen dedizierten WAN Port und somit ist dem Blech bekannt was aussen und was innen ist (einfachst gesagt).

Ja genau, der Port wo "Internet" draufsteht, da ist auch das Lankabel, welches vom Inet Port am Modem weggeht, verbunden.
Dachte ich mir also auch so, dass der Router es wissen sollte.

:O tatsächlich....Wenn ich mit dem Handy ins LTE Netz gehe und dann im Browser die öffentliche IP eingebe krieg ich ein Connection Timeout...Vom LAN aus gehts aber...ok, verstehe....Wie dumm von mir... :D Bild mir aber ein, wir haben das ursprünglich auch außerhalb des Lans versucht und es klappte...Naja, vllt. waren da noch die beiden Fernzugriff Einstellungen die ich oben beschrieben hab, eingeschaltet.. Gut, das beruhigt mich schon etwas

Mal dein Netz mal auf ein Blatt paier, gebe die LAN Ports an und dessen IP sowie dessen GW und dessen Subnetzmaske an und stelle das hier rein. dann sehen wir was du tatsächlich hast.
Auch dein GW (Eintrag) sollte dir sagen wo es nach draussen geht...

Hab ein paar Infos gefunden, sollte dies nicht reichen, werf ich Paint an

Also im Webinterface des Routers steht unter Status -> WAN mal folgendes:

Konfigurationstyp
Verbindungstyp Automatische Konfiguration - DHCP
Verbindungszeit 6:17:30
IP-Adresse 81.217.144.191
Netzmaske 255.255.255.0
Gateway 81.217.144.1
DNS 1 77.88.8.7
DNS 2 77.88.8.3
DNS 3 195.202.138.3

Unter Status -> LAN folgendes:

LAN-Status
MAC-Adresse <sollte ich lieber nicht hier rausschreiben oder?>
IP-Adresse 192.168.1.1
Netzmaske 255.255.255.0
Gateway 0.0.0.0
Lokaler DNS 0.0.0.0

Gruß,
Peter

Unter WAN IP steht die öffentliche IP, die mir z.B. auch auf der Webseite: wieismeineip.at angezeigt wird: 81.217.144.191
Also arbeitet das Cisco Gerät rein als Modem.

Wenn nicht dann kann es nur die lokale Firewall der lokalen Maschinen sein die du nicht entsprechend eingestellt hast. Aus dem VPN Tunnel kommst du ja mit einer fremden Adsender IP die die lokale (Windows) Firewall dann sofort blockt. Sie lässt nur Traffic aus dem lokalen Netz passieren.
Ebenso blockt sie ab Win 7 ICMP (Ping) das verhindert dann das du diese Geräte anpingen kannst:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Hast du das beachtet ??

Nein, hab ich beachtet. Puh, hier wird's noch komplizierter für mich.. Es geht auch um einen Einplatinencomputer, der als home-server fungiert. Darauf läuft Armbian, eine Distribution auf Debian Basis. Ob und welche Firewall da drauf läuft weiß ich nicht.
Ich hab allerdings auch probiert, von außen über den Vpn Tunnel auf das Webinterface meines Vu+ Satreceivers zu kommen, was auch nicht funktionierte. Keine Ahnung, ob der auch eine Firewall hat die dies vllt verhindert.

Tip: Mal ein bischen Wikipedia über Ostern lesen und sich mal nur mit den einfachsten Grundlagen von Routern und NAT (IP Adresstranslation) vertraut machen, damit du wenigstens mal weisst um was es eigentlich grindlegend geht statt in einem Administrator Forum im freien Fall rumzuraten !

Ich wollte hier nicht rumraten und hier auch keinen nerven, sorry. Danke für den Tipp, ich hab gerade bei dieser Thematik immer das Gefühl, dass man sich damit gut auskennt und sich dementsprechend viel Wissen angeeignet hat. Oder aber sich nicht auskennt, so wie ich. Viel dazwischen gibt's nicht, dieses Gefühl hab ich halt.
Ich dachte halt, ich frage hier mal um Hilfe, weil ich eben auf stundenlanges Einlesen in die Thematik keine Lust hatte. (ja, ich bin faul).

2 Kardinalsfragen hast du zu beantworten:

1.) Ist der VPN Tunnel wirklich aktiv ?? Hast du das hier mal gemacht um das wasserdicht zu verifizieren: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router Auszug deines Server oder Client Logs was das zeigt ("Initialization Sequence Completed" oder "tunnel established" Meldung) wäre sehr hilfreich.

Ja, habe ich. Hier der Auszug:

Serverlog: 
20170415 13:52:31 I OpenVPN 2.4.0 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 30 2017 
20170415 13:52:31 I library versions: OpenSSL 1.0.2k 26 Jan 2017 LZO 2.09 
20170415 13:52:31 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:14 
20170415 13:52:31 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 
20170415 13:52:31 Diffie-Hellman initialized with 1024 bit key 
20170415 13:52:31 I TUN/TAP device tun2 opened 
20170415 13:52:31 TUN/TAP TX queue length set to 100 
20170415 13:52:31 D do_ifconfig tt->did_ifconfig_ipv6_setup=0 
20170415 13:52:31 I /sbin/ifconfig tun2 192.168.1.193 netmask 255.255.255.224 mtu 1500 broadcast 192.168.1.223 
20170415 13:52:31 Socket Buffers: R=[180224->180224] S=[180224->180224] 
20170415 13:52:31 I UDPv4 link local (bound): [AF_INET][undef]:1194 
20170415 13:52:31 I UDPv4 link remote: [AF_UNSPEC] 
20170415 13:52:31 MULTI: multi_init called r=256 v=256 
20170415 13:52:31 IFCONFIG POOL: base=192.168.1.194 size=28 ipv6=0 
20170415 13:52:31 IFCONFIG POOL LIST 
20170415 13:52:31 I Initialization Sequence Completed 
20170415 20:42:43 212.95.7.26:56952 TLS: Initial packet from [AF_INET]212.95.7.26:56952 sid=055c5867 f0d1ee10 
20170415 20:42:43 212.95.7.26:56952 VERIFY OK: depth=1 C=AT ST=Niederoesterreich L=Sankt Poelten O=Privat OU=changeme CN=OpenVPN name=changeme emailAddress=mail@host.domain 
20170415 20:42:43 212.95.7.26:56952 VERIFY OK: depth=0 C=AT ST=Niederoesterreich L=Sankt Poelten O=Privat OU=changeme CN=client1 name=changeme emailAddress=mail@host.domain 
20170415 20:42:43 I 212.95.7.26:56952 peer info: IV_GUI_VER=net.openvpn.connect.android_1.1.17-76 
20170415 20:42:43 I 212.95.7.26:56952 peer info: IV_VER=3.0.12 
20170415 20:42:43 I 212.95.7.26:56952 peer info: IV_PLAT=android 
20170415 20:42:43 I 212.95.7.26:56952 peer info: IV_NCP=2 
20170415 20:42:43 I 212.95.7.26:56952 peer info: IV_TCPNL=1 
20170415 20:42:43 I 212.95.7.26:56952 peer info: IV_PROTO=2 
20170415 20:42:43 I 212.95.7.26:56952 peer info: IV_LZO=1 
20170415 20:42:43 W 212.95.7.26:56952 WARNING: 'link-mtu' is used inconsistently local='link-mtu 1570' remote='link-mtu 1542'   
20170415 20:42:43 W 212.95.7.26:56952 WARNING: 'cipher' is used inconsistently local='cipher AES-128-CBC' remote='cipher BF-CBC'   
20170415 20:42:43 W 212.95.7.26:56952 WARNING: 'auth' is used inconsistently local='auth SHA256' remote='auth SHA1'   
20170415 20:42:43 212.95.7.26:56952 Control Channel: TLSv1.2 cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384 1024 bit RSA 
20170415 20:42:43 I 212.95.7.26:56952 [client1] Peer Connection Initiated with [AF_INET]212.95.7.26:56952 
20170415 20:42:43 I client1/212.95.7.26:56952 MULTI_sva: pool returned IPv4=192.168.1.194 IPv6=(Not enabled) 
20170415 20:42:43 client1/212.95.7.26:56952 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_67ccabefd64353d6eefd30fdd29d8462.tmp 
20170415 20:42:43 client1/212.95.7.26:56952 MULTI: Learn: 192.168.1.194 -> client1/212.95.7.26:56952 
20170415 20:42:43 client1/212.95.7.26:56952 MULTI: primary virtual IP for client1/212.95.7.26:56952: 192.168.1.194 
20170415 20:42:43 client1/212.95.7.26:56952 PUSH: Received control message: 'PUSH_REQUEST'   
20170415 20:42:43 client1/212.95.7.26:56952 SENT CONTROL [client1]: 'PUSH_REPLY route 192.168.1.0 255.255.255.0 redirect-gateway def1 dhcp-options DNS 77.88.8.7 dhcp-options DNS 77.88.8.3 route-gateway 192.168.1.193 topology subnet ping 10 ping-restart 120 ifconfig 192.168.1.194 255.255.255.224 peer-id 0 cipher AES-256-GCM' (status=1)   
20170415 20:42:43 client1/212.95.7.26:56952 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key   
20170415 20:42:43 client1/212.95.7.26:56952 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key   
20170415 20:51:09 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14 
20170415 20:51:09 D MANAGEMENT: CMD 'state'   
20170415 20:51:09 MANAGEMENT: Client disconnected 
20170415 20:51:09 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14 
20170415 20:51:09 D MANAGEMENT: CMD 'state'   
20170415 20:51:09 MANAGEMENT: Client disconnected 
20170415 20:51:09 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14 
20170415 20:51:09 D MANAGEMENT: CMD 'state'   
20170415 20:51:09 MANAGEMENT: Client disconnected 
20170415 20:51:09 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14 
20170415 20:51:09 MANAGEMENT: Client disconnected 
20170415 20:51:09 NOTE: --mute triggered... 
20170415 20:51:09 1 variation(s) on previous 3 message(s) suppressed by --mute 
20170415 20:51:09 D MANAGEMENT: CMD 'status 2'   
20170415 20:51:09 MANAGEMENT: Client disconnected 
20170415 20:51:09 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14 
20170415 20:51:09 D MANAGEMENT: CMD 'status 2'   
20170415 20:51:09 MANAGEMENT: Client disconnected 
20170415 20:51:09 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14 
20170415 20:51:09 D MANAGEMENT: CMD 'log 500'   
19700101 01:00:00 

* 2.) Macht dein Provider DS-Lite ?? RFC 1918 IP am WAN Port ?

3.) Ist es bei 2. eine öffentliche IP, dann macht dein Provider KEIN DS-Lite, was gut wäre. Andernfalls nicht.

Wie meinst du bei 2.? Also bei WAN IP steht im Router : 81.217.144.191

So, habe nun noch eine stümperhafte Netzwerkkarte angefertigt.
Den Switch habe ich euch nämlich auch vorenthalten^^

Wieso stümperhaft ? Ist doch wunderbar gelungen und übersichtlich. Alles gut. Ein einfaches simples flaches Netzwerk ohne Segmentierung. Das reduziuert schon mal mögliche Fehler.
Der Server fährt fehlerfrei hoch das belegt das "Initialization Sequence Completed "
Du hast ein MTU Problem im VPN:
"WARNING: 'link-mtu' is used inconsistently local='link-mtu 1570' remote='link-mtu 1542"
Niemals darfst du hier MTUs verwenden die größer als max. 1452. Wenn du PPPoE am Router nutzt muss es sogar noch dadrunter liegen.
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Zudem haben Server und Client inkonsistente MTU Werte. Das solltest du dringenst korrigieren !
Auch dein Schlüsselprotokoll ist inkonsistent eingestellt zwischen Client und Server (Blowfish und AES) ! Das ist natürlich fatal...!
"WARNING: 'cipher' is used inconsistently local='cipher AES-128-CBC' remote='cipher BF-CBC' "
Hier musst du zwingend auf beiden Seiten gleiche Protokolle nutzen ! Gleiches gilt fürs Hashing. Auch das ist unterschiedlich. Auch hier gilt anpassen !
Lass deine Konfig erstam nur mit dem nötigstens laufen und belasse alle OVPN Einstellungen im Default.
Das hiesige OVPN Tutorial gint dir ein Beispiel:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Wenn du dein o.a. Log liest kannst du diese Probleme und Fehler ja auch alle selbst sehen und mit deinen Settings vergleichen.

Hach....Komm nicht wirklich weiter..Wenn der Server nach Änderung von Einstellungen nicht mehr startet, tu ich mir schwer irgendwie draufzukommen warum.
Wie im ersten Bild zu sehen, hab ich ja ursprünglich auf Server gestellt nicht auf Daemon. Dachte mir, als Laie ist dies besser, da man weitere Configmöglichkeiten schon bereitgestellt bekommt und vllt. weniger Spielraum für Fehler ist.
Nach deinem Tipp, mal alles mit Default Einstellungen laufen zu lassen, hab ich auf Daemon umgestellt. Die Einstellmöglichkeiten fallen weg u. ich denke man pastet nun eben die ganze Config ins Feld "Openvpn Configuration".
Hier die Config:

port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
server 192.168.1.192 255.255.255.224
push "route 192.168.1.0 255.255.255.0"  
push "redirect-gateway def1"  
push "dhcp-options DNS 77.88.8.7"  
push "dhcp-options DNS 77.88.8.3"  
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

So startet der Server mal nicht.
Zum Thema MTU:
So wie ichs verstanden hab, gibt man mit link-mtu die Größe an, welche nach Zurechnung des Overheads verwendet werden soll.
Ich geh mal davon aus, dass der von client zu client u. auch zw. client u. server unterschiedlich ist, weshalb man link-mtu setzen sollte.
Bleib ich bei "Server" und schalte die erweiterten Einstellungen ein gibts nur die Möglichkeit einen tun-mtu Wert festzulegen:

Setze ich hier 1400 ein, stimmt das Ganze wieder nicht zusammen.
Schalte ich die erweiterten Einstellungen wieder aus und klatsche ins Feld "Openvpn Configuration" die Zeile: link-mtu 1400 started mir der Server wiederum nicht.

Du machst einen Kardinalsfehler !!
server 192.168.1.192 255.255.255.224
push "route 192.168.1.0 255.255.255.0"
Wie soll das denn bitte routingtechnisch funktionieren ??
Du definierst das lokale LAN was der VPN Server dem Client annoucen soll mit exakt dem gleichen IP Netzwerk was OpenVPN intern verwendet.
Damit hast du dann doppelte IP Adressen bzw. Netze und nichts geht mehr. Klar das das in die Hose geht !! Dein /27er Subnetz ist ja Teil des im Client injizierten /24er Prefixes. Damit hast du einen Subnetz Mismatch
Das interne OVPN Netzwerk muss wie alle IP Netze in einem Verbund einzigartig sein und darf niemals doppelt verwendet werden sonst ist eine eindeutige Wegefindung im IP nicht mehr möglich. Solche IP Binsenweisheiten lernt man in der ersten Klasse IP Routing

Fazit: Konfiguriere das interne OVPN Netzwerk bzw. die Subnetzmakse richtig, dann klappt das auch.

Beispiel:
server 192.168.1.192 255.255.255.224 --> Netzwerk: .1.192, Hosts: .1.193 - .1.222
push "route 192.168.1.0 255.255.255.128" --> Netzwerk: .1.0, Hosts: .1.1 - .1.126

Das bedeutet dann aber auch das dein lokales LAN und dessen Endgeräte zwingend eine Subnetzmaske 255.255.255.128 hat ( /25 Prefix) !!
Damit ist das Routing dann sauber.

Oder wenn du dir das Subnetting gleich ersparen willst und mit Standard /24 Maske arbeitest:
server 172.16.1.0 255.255.255.224 --> Netzwerk: .1.192, Hosts: .1.193 - .1.222
push "route 192.168.1.0 255.255.255.0" --> Netzwerk: .1.0, Hosts: .1.1 - .1.253

oder noch einfacher:
server 172.16.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

P.S.: Die DNS Server IPs sind Platzhalter, oder nutzt du russische DNS Server von Yandex LLC ???

Erstmal danke für die Aufklärung. Bei dem Bekannten ist es so, dass Clients die sich zum Server verbinden von seiner Fritzbox IP Adressen ab 192.168.1.200 zugewiesen bekommen. Das Lan ist bei ihm auch 192.168.1.0 255.255.255.0 angegeben. Deshalb haben wir das so angegeben.
Er meinte da ist nicht viel dabei so einen vpn server aufzusetzen. Naja, es stellte sich allgemein heraus, dass es bei so einer Fritzbox allgemein einfacher ist..
Also meine Config sieht nun so aus:
server config:

push "route 192.168.1.0 255.255.255.0"  
push "redirect-gateway def1"  
push "dhcp-options DNS 77.88.8.7"  
push "dhcp-options DNS 77.88.8.3"  
verb 3

client:

client
dev tun
proto udp
remote dah4m.ddns.net 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
remote-cert-tls server
cipher AES-128-CBC
auth SHA256
comp-lzo
verb 3 

Der Log lest sich auch schon viel besser:

20170421 08:15:41 212.236.20.147:65302 TLS: Initial packet from [AF_INET]212.236.20.147:65302 sid=2060be9f 0faf5371 
20170421 08:15:41 212.236.20.147:65302 VERIFY OK: depth=1 C=AT ST=Niederoesterreich L=Sankt Poelten O=Privat OU=changeme CN=OpenVPN name=changeme emailAddress=mail@host.domain 
20170421 08:15:41 212.236.20.147:65302 VERIFY OK: depth=0 C=AT ST=Niederoesterreich L=Sankt Poelten O=Privat OU=changeme CN=client1 name=changeme emailAddress=mail@host.domain 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_VER=2.4.1 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_PLAT=win 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_PROTO=2 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_NCP=2 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_LZ4=1 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_LZ4v2=1 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_LZO=1 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_COMP_STUB=1 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_COMP_STUBv2=1 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_TCPNL=1 
20170421 08:15:41 I 212.236.20.147:65302 peer info: IV_GUI_VER=OpenVPN_GUI_11 
20170421 08:15:41 212.236.20.147:65302 Control Channel: TLSv1.2 cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384 1024 bit RSA 
20170421 08:15:41 I 212.236.20.147:65302 [client1] Peer Connection Initiated with [AF_INET]212.236.20.147:65302 
20170421 08:15:41 I client1/212.236.20.147:65302 MULTI_sva: pool returned IPv4=172.16.1.2 IPv6=(Not enabled)
20170421 08:15:41 client1/212.236.20.147:65302 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_ba52d9ccd11158d2f4d133de931fdfe5.tmp 
20170421 08:15:41 client1/212.236.20.147:65302 MULTI: Learn: 172.16.1.2 -> client1/212.236.20.147:65302 
20170421 08:15:41 client1/212.236.20.147:65302 MULTI: primary virtual IP for client1/212.236.20.147:65302: 172.16.1.2 
20170421 08:15:42 client1/212.236.20.147:65302 PUSH: Received control message: 'PUSH_REQUEST'   
20170421 08:15:42 client1/212.236.20.147:65302 SENT CONTROL [client1]: 'PUSH_REPLY route 192.168.1.0 255.255.255.0 redirect-gateway def1 dhcp-options DNS 77.88.8.7 dhcp-options DNS 77.88.8.3 route-gateway 172.16.1.1 topology subnet ping 10 ping-restart 120 ifconfig 172.16.1.2 255.255.255.0 peer-id 0 cipher AES-256-GCM' (status=1)   
20170421 08:15:42 client1/212.236.20.147:65302 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key   
20170421 08:15:42 client1/212.236.20.147:65302 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key   
20170421 08:17:11 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14 

Allerdings komme ich nun wie gehabt nicht auf die Lokalen IP's und seit neuestem auch nicht mehr ins Internet über die vpn Verbindung.

P.S.: Die DNS Server IPs sind Platzhalter, oder nutzt du russische DNS Server von Yandex LLC ???

Hatte mal gelesen, dass man die default DNS nicht nutzen soll wenn man eine Vpn Verbindung als Client zu einem Provider nutzt da so die Annonymität wieder flöten geht, da der Inetverkehr irgenwie wieder nachvollzogen werden kann.
Die Yandex DNS Server haben auch noch so einen Familienfilter dabei, daher hab ich die genommen.
Deiner Frage nach interpretiere ich einfach mal rein, dass dies keine gute Idee war. Kannst du andere DNS empfehlen?

Du hast schon wieder einen Riesenfehler gemacht

push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway def1"
Das zusammen zu konfigurieren ist natürlich Blödsinn !!!
Auf der einen Seite pushst du eine dedizierte Route und danach dann so oder so die Default Route. Das ist natürlich Unsinn.
Wenn du push "redirect-gateway def1" machst inkludiert das natürlich auch das 192.168.0.0er Netz und das kannst du dir dann natürlich sparen !
Vermutlich ist das auch ein Grund.
Ansonsten sehen die Log Messages gut aus und kein Fehler.

Das du die lokalen IPs nicht erreichen kannst ist die lokale Windows Firewall wenn es Windows ist. Die musst du entsprechend anpassen !!
Du hast ja nun eine Absender IP aus dem internen OpenVPN Netzwerk also einem anderen IP Netz. Die Windows Firewall blockiert diese aber gnadenlos, da sie nur Zugriffe aus dem eigenen lokalen Netzwerk erlaubt !
Hast du das beachtet ??
Ebenso blockiert sie generell Ping Packete (ICMP Protokoll) auch das musst du anpassen solltest du Windows Geräte pingen ! (Siehe Hinweis oben im Thread !)

Sinnvoll ist es daher erstmal Geräte zu pingen die keine lokale Firewall haben wie Drucker, NAS, Staubsaugerroboter, AV-Receiver, Xbox usw. Ideal ist das LAN Interface des Linksys/DDWRT Routers wo der OVPN Server läuft.
Achtung hier: Diese angepingten Geräte im LAN müssen alle zwingend ein Default Gateway definiert haben ! Da deine Pings ja von einem Fremdnetz kommen braucht das angepingte Gerät ein Gateway um erfolgreich eine Antwort senden zu können !
Diese Gateway IP ist ja dann vermutlich dein Linksys/DD-WRT Router der auch das OpenVPN realisiert bzw. sollte es zwingend sein.
Auch hier ist Traceroute oder Pathping wie immer dein bester Freund

Sinnvoll ist es daher erstmal Geräte zu pingen die keine lokale Firewall haben wie Drucker, NAS, Staubsaugerroboter, AV-Receiver, Xbox usw. Ideal ist das LAN Interface des Linksys/DDWRT Routers wo der OVPN Server läuft.

Sehr geil, danke für die Hilfe. War ganz auf den htpc/home server fixiert.
Komme nun aufs Webinterface meines Staubsaugers, meines Sat Receivers und auch auf das Kodi-Interface meines Media Players.
Das ist schon mal sehr geil

Wenn du push "redirect-gateway def1" machst inkludiert das natürlich auch das 192.168.0.0er Netz und das kannst du dir dann natürlich sparen !

Hab nur push "redirect-gateway def1" , jz komm ich trotzdem nicht ins Inet. Chrome schreibt der Verb.aufbau hat zu lange gedauert.

Das du die lokalen IPs nicht erreichen kannst ist die lokale Windows Firewall wenn es Windows ist. Die musst du entsprechend anpassen !!
Du hast ja nun eine Absender IP aus dem internen OpenVPN Netzwerk also einem anderen IP Netz. Die Windows Firewall blockiert diese aber gnadenlos, da sie nur Zugriffe aus dem eigenen lokalen Netzwerk erlaubt !
Hast du das beachtet ??

Auf den Windows PC zu kommen ist mir vorerst nicht so wichtig, genauso wie ins Inet über den Vpn-Tunnel zu kommen. Danke für den Link, das schau ich mir noch an.

Achtung hier: Diese angepingten Geräte im LAN müssen alle zwingend ein Default Gateway definiert haben ! Da deine Pings ja von einem Fremdnetz kommen braucht das angepingte Gerät ein Gateway um erfolgreich eine Antwort senden zu können !
Diese Gateway IP ist ja dann vermutlich dein Linksys/DD-WRT Router der auch das OpenVPN realisiert bzw. sollte es zwingend sein.
Auch hier ist Traceroute oder Pathping wie immer dein bester Freund

Also kann ich schon mal eingrenzen warum ich den home server nicht erreiche:
Eventuell verhindert es die lokale Firewall, oder es ist kein Default Gateway definiert. Richtig?
Auf dem Homeserver läuft Armbian, eine Debian Distribution.

Komme nun aufs Webinterface meines Staubsaugers,

Tadaaa!!

Zeigt das dein VPN Tunnel funktioniert !

komm ich trotzdem nicht ins Inet.

Mmmhh... Wählst du dich aus einem remoten Netzwerk ein ? Also NICHT dein lokales Netzwerk.
Was heisst auch Internet geht nicht bedeutet das jetzt du kannst keine DNS Auflösung machen oder kannst auch direkt IP Adressen nicht erreichen ??
Kannst du z.B. ping 8.8.8.8 eingeben und bekommst auch keine Antwort ??

Sollte der Ping auf die 8.8.8.8 klappen, ist es sehr gut möglich das das mit deinen russischen DNS zu tun hat.
Da du ja allen Traffic redirectest solltest du testweise erstmal den lokalen DNS nutzen nur um zu sehen das es daran liegt oder eben nicht.
Lösche das also mal und teste einen stinknormale Standardkonfig.
Wenn dein VPN Client eine Winblows Kiste ist hilt auch mal ein ipconfig -all und ein route print bei aktiviertem VPN Cient.

Also kann ich schon mal eingrenzen warum ich den home server nicht erreiche:

Ja, wenn die Ambian Distro auch eine Firewall installiert gleiche Problematik wie bei Winblows.
Der Server sollte ja eine feste statische IP haben wie es sich für Server gehört und dann müsstest du auch ein Gateway eintragen wenn du remote zugreifen willst.
Die IP Konfig bei Debian geht so:
Netzwerk Management Server mit Raspberry Pi

Nein, bekomme keine Antwort, im Lan funktionierts dann wieder.

Lösche das also mal und teste einen stinknormale Standardkonfig.

Hab die beiden Zeilen:
push "dhcp-options DNS 77.88.8.7"
push "dhcp-options DNS 77.88.8.3"
..mal rausgenommen, kommt trotzdem nix zurück.

Der Server sollte ja eine feste statische IP haben wie es sich für Server gehört und dann müsstest du auch ein Gateway eintragen wenn du remote zugreifen willst.
Die IP Konfig bei Debian geht so:
Netzwerk Management Server mit Raspberry Pi

Hab nun eine statische IP eingerichtet, nur nicht gecheckt was rein muss in resolv.conf.
domain netz.intern
search netz.intern
nameserver 192.168.1.1
letzeres steht schon drinnen, welche domain soll bei domain und search eingetragen werden?
Nur mit nameserver funktioniert es auch schon, ein ping vom homeserver aus auf eine webseite klappt.
Auch den homeserver selbst zu pingen klappt, aber eben nur im Lan und nicht über den vpn tunnel.
Hinweise auf eine aktive Firewall am homeserver hab ich bislang keine gefunden.

..mal rausgenommen, kommt trotzdem nix zurück.

Du kannst ja bei aktivem VPN Client dann immer mit ipconfig -all sehen WELCHE IP Adressen er aktiv für DNS nutzt !
Was meinst du genau mit...

Nein, bekomme keine Antwort, im Lan funktionierts dann wieder.

??? Das heisst wenn du von einem LAN Client die 8.8.8.8 pingst dann geht es über den Tunnel ??
Hast du diese IP mal getraceroutet um zu sehen über welche Hops die geht ?? (tracert 8.8.8.8)

nur nicht gecheckt was rein muss in resolv.conf.

Das hier reicht:

root@raspi:/home/pi# cat /etc/resolv.conf
# Generated by resolvconf
domain netz.intern
nameserver 192.168.1.1 

Du kannst ja bei aktivem VPN Client dann immer mit ipconfig -all sehen WELCHE IP Adressen er aktiv für DNS nutzt !
Was meinst du genau mit...

Hab mich nun mit dem Work PC mit dem Vpn Server verbunden...Will den output nicht unbedingt posten, was sollte ich denn schwäzen, abgesehen von der Mac Adresse?
..Es muss in dem Fall der Ethernet-Adapter Ethernet 3 sein, da dort unter IPv4-Adresse: 172.16.1.2 steht.
Da ist mir nur aufgefallen, dass bei Standardgateway nichts steht...Kann hier das Problem liegen?

??? Das heisst wenn du von einem LAN Client die 8.8.8.8 pingst dann geht es über den Tunnel ??

Nein, ganz normal im Lan meinte ich, was ja eh klar ist, dass es funktioniert.
Wenn ich via vpn tunnel verbunden bin und ping 8.8.8.8 eingebe kommt nichts zurück.

Hast du diese IP mal getraceroutet um zu sehen über welche Hops die geht ?? (tracert 8.8.8.8)

Meinst du eh, wenn ich via vpn verbunden bin?
Dann erhalte ich diesen output:

Hallo,

Zitat von @trohn-javolta:
schwäzen, abgesehen von der Mac Adresse?

Damit würden wir den Hersteller dieser NIC wissen, mehr nicht.

..Es muss in dem Fall der Ethernet-Adapter Ethernet 3 sein, da dort unter IPv4-Adresse: 172.16.1.2 steht. Da ist mir nur aufgefallen, dass bei Standardgateway nichts steht...Kann hier das Problem liegen?

Mach ein Route Print und schau dir an wie deine Routen gestezt sind mit und ohne VPN. Dann sollte klar sein arum dort kein Gateway eingetragen ist. Und ein Standardgateway kann es nur einmal geben. Es können aber durchaus mehrere Gateways geben.

Wenn ich via vpn tunnel verbunden bin und ping 8.8.8.8 eingebe kommt nichts zurück.

Deinn Traffic soll wenn VPN verbunden ist eben alles über VPN laufen und dein VPN Client darf eben nicht ins Internet? Einstellung des Clients...

Meinst du eh, wenn ich via vpn verbunden bin?

Mal mit, mal ohne.

Gruß,
Peter

Ok, bin leicht verwirrt..hab ma folgende Befehle auf meinem Windows PC laufen lassen, mit dieser config:

push "redirect-gateway def1"  
push "dhcp-options DNS 77.88.8.7"  
push "dhcp-options DNS 77.88.8.3"  
verb 3

In der client.ovpn datei hab ich bei server 192.168.1.1 1194 angegeben.

ipconfig -all:

tracert 8.8.8.8:

route print:

Und jz nochmal alles ganz normal im Lan ohne vpn Verbindung:

ipconfig -all:

tracert 8.8.8.8:

route print:

Hilft euch das irgendwie weiter?

Das hier reicht:

root@raspi:/home/pi# cat /etc/resolv.conf
> # Generated by resolvconf
> domain netz.intern
> nameserver 192.168.1.1 

Hmm.. komisch, nun hab ich keine internet verbindung mehr am homeserver. :/
So siehts jz aus:

Und so gings auch zuerst.
Zwischenzeitlich hab ich
domain netz.intern
Hinzugefügt und es ging nicht mehr.
Nun wieder weggenommen trotzdem kein inet.

Eins fällt mir noch ein: Ich hab am Router mal static leases/ statische Zuweisungen eingerichtet für alle Geräte/IP's.
Ich fand dies sehr praktisch, da wenn man noch dazu dnsmasq aktiviert, die Geräte mit dem vergebenen Hostnamen ansprechbar sind.
Meint ihr das könnte irgendwie reinpfuschen?

Ich weiß nicht, in wieweit der Thread hier noch anderen weiterhilft, glaub das Ganze wird schon recht speziell.
Gibt's auch die Möglichkeit jemanden hier zb. via Irc zu erreichen? Praktischer wäre dies auf jeden Fall.

Wenn ich via vpn tunnel verbunden bin und ping 8.8.8.8 eingebe kommt nichts zurück.

Hast du dann mal ein route print eingegeben ob dein Default Gateway dann wenigstens in den Tunnel redirectet ist bei aktivem VPN Client ?
Ist das der Fall, dann hast du ein Routing Problem an der Server Seite, das dort kein Default Gateway auf den Router eingetragen ist.
Wie weit kommt denn ein traceroute 8.8.8.8 ?? (tracert bei Winblows)

Ja, wie beschrieben hab ich die obigen Befehle einmal bei aktivem VPN Client u. einmal im "normalen" Lan eingegeben.
Aber eben vom PC daheim, wo ich in der client.ovpn bei server 192.168.1.1 eingegeben hab.
Am Android Smartphone könnt ichs noch probiern, wisst ihr wie die Befehle dort lauten?

Ok, nach einem Reboot des Routers hab ich wieder eine Inet Verbindung am homeserver.
Aber zugreifen drauf kann ich über vpn nach wie vor nicht.

Hat jemand noch Ideen warum gerade der Debian Server nicht über Vpn erreichbar ist?
Firewall ist keine drauf, static Ip ist eingerichtet...Ich komm selbst nicht weiter.
Die Ausgaben von route print, ipconfig -all u. tracert sind für mich nur Bahnhof.
Ob der Vpn client nun über den Tunnel ins Inet geht oder nicht ist mir relativ egal, ich möchte einfach meinen Debian Server erreichen.
Bei anderen Geräten im Lan funktioniert das, wie schon gesagt, bereits tadellos.

Das kann nur die lokale Firewall des Servers sein. Das du generell nichts falsch gemacht hast zeigt ja eindeutig die Tatsache das alle anderen Geräte via VPN erreichbar sind.
Das ist in der Regel dann immer die lokale Firewall.
Deaktiviere die doch einfach mal dann bist du doch schlauer...
Im Zweifel lass immer mal einen tcpdump auf dem Port laufen um mal zu sehen WAS genau beim Debian ankommt.

Über den Openvpn Irc Helpchannel hab ich mal dieses Flowchart erhalten um alles auf Fehler zu prüfen:
http://www.ircpimps.org/serverlan.png
Hier scheitert es schon beim 1. Punkt.
Ich soll über den verbundenen vpn client die vpn server ip pingen, also 172.16.1.1.
Da erhalte ich keine Antwort

Ideen warum?

Da kann es wie bereits gesagt nur 3 mögliche Antworten geben:

1.Möglichkeit = Fehlende oder falsche Firewall Regel auf dem virtuellen OVPN Interface
2. Möglichkeit = Der Server hat selber eine lokale Firewall die inbound Traffic blockt also auch hier anpassen.
3. Möglichkeit = Eine Kombination von 1. und 2.

Du hast es ja leider bis hierhin nicht geschafft uns mal einen Screenshot deiner Client FW Regeln auf dem OVPN Interface zu posten.
Wichtig ist auch das du den Ping vom VPN Client direkt ausführst.

Nur nochmal doof nachgefragt....
Dein OVPN Client ist ein DD-WRT Router hinter einem Internet Router, richtig ?
Was ist der OVPN Server für ein Gerät und wo ist das plaziert. Sorryggf. für die mehrfach Frage aber durch das Hin- und Her ist das hier untergegangen.

Danke erstmal, dass du hier noch antwortest und dranbleibst.

* 1.Möglichkeit = Fehlende oder falsche Firewall Regel auf dem virtuellen OVPN Interface

Ich habe vorerst die SPI Firewall deaktiviert und keine der Iptables Regeln vom Tutorial gesetzt.
Auch weil ich nicht weiß, wie die Regeln bei mir aussehen müssen.
Das sind ja die Regeln:

# Akzeptiert eingehende Anfragen am Port UDP 1194.
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT

# Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfläche, SSH etc)
iptables -I INPUT 3 -i tun0 -j ACCEPT

# Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist. 
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT

# Erlaubt Verbindungen vom lokalen Netz ins VPN Netz und umgekehrt (br0 steht für LAN und WLAN).
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT 

Auf meinem Router läuft ja neben dem ovpn server auch ein ovpn client. Client tun1, Server tun2.
Muss ich denn überall in den Regeln nun tun0 durch tun2 ersetzen?

Nur damit ichs richtig verstanden hab: Solange die SPI Firewall deaktiviert ist, sind diese iptables Regeln sowieso noch nicht relevant, oder?

* 2. Möglichkeit = Der Server hat selber eine lokale Firewall die inbound Traffic blockt also auch hier anpassen.

Von welchem Server ist nun die Rede? Du meinst den debian homeserver? Da hab ich schon geschaut.

Du hast es ja leider bis hierhin nicht geschafft uns mal einen Screenshot deiner Client FW Regeln auf dem OVPN Interface zu posten.

Firewall Regeln, am Router?

Nur nochmal doof nachgefragt....
Dein OVPN Client ist ein DD-WRT Router hinter einem Internet Router, richtig ?
Was ist der OVPN Server für ein Gerät und wo ist das plaziert. Sorryggf. für die mehrfach Frage aber durch das Hin- und Her ist das hier untergegangen.

Auf meinem Linksys Router mit DD-Wrt läuft zum einen ein Ovpn Client der sich zu einem Vpn Provider verbindet (tun1) und zum anderen eben der Ovpn Server.
Der DD-WRT Router ist hinter einem Modem, welches kein NAT betreibt.
Verbinde ich mich von außerhalb zum Ovpn Server, kann ich sowohl das Router Webinterface mit 192.168.1.1. erreichen, als auch alle Ip's im Lan bis auf die Ip meines Debian Homeservers. Der hat eine statische Ip bekommen (wie im von dir verlinkten Tutorial) und auch der Befehl sudo iptables -L am Homeserver liefert:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Also, dass die Firewall deaktiviert ist.

Versuche ich nun aber von außerhalb über vpn: ping 172.16.1.1 erhalte ich keine Antwort.

Ovpn Client der sich zu einem Vpn Provider verbindet (tun1) und zum anderen eben der Ovpn Server.

Du hast einen Server und einen Client Prozess auf ein- und derselben Hardware laufen ???
Das geht so oder so gar nicht !
Der OVPN kann entweder nur im Server Mode oder nur im Client Mode arbeiten. Beises parallel geht nicht.
Oder arbeítest du da mit irgendeiner Art von Virtualisierung, sprich mit mehreren Hosts ?
Das kann ja schon deshalb nicht gehen weil du mit der OVPN Konfig Datei ja bestimmst in welchem Mode der OpenVPN arbeiten soll und da geht logischerweise imme rnur entweder oder.
Vermutlich ist das die Wurzel allen Übels..?!

Wie schon einaml weiter oben erwähnt, ja hab ich.
Dd-wrt bietet die Einstellmöglichkeiten, daher nehme ich an, dass es geht.

Das kann ja schon deshalb nicht gehen weil du mit der OVPN Konfig Datei ja bestimmst in welchem Mode der OpenVPN arbeiten soll und da geht logischerweise imme rnur entweder oder.

Es gibt dann natürlich 2 versch. Config dateien.
Beim vpn client gibts das Feld policy basiertes Routing, dort ist die ip des homeservers eingetragen. Dies hat den effekt, dass nur der homeserver über vpn raus geht. Der vpn provider meinte. Dass dies keine Auswirkungen auf einen zusätzlichen eigenen vpn server haben sollte, glaub allerdings mittlerweile, dass es daran liegt, dass ich den homeserver nicht erreiche.

daher nehme ich an, dass es geht.

Nein, das geht de facto nicht !
Lies dir die Grundlagen von Open VPN durch:
https://openvpn.net/index.php/open-source/documentation/howto.html
Bei DD-WRT ist es auch so das wenn man den Client Mode aktiviert, der Server Mode ausgegraut ist und umgekehrt.
Passiert das bei dir nicht ist das ein Bug in der Firmware.
Ein Paralellbetrieb beider Modi auf einer Hardware bzw. in einem OS ist nicht möglich und nebenbei auch unsinnig.

Ok, aktuell geht ja alles außer eben den homeserver zu erreichen.
Warum ist das unsinnig?
Ich will eben, dass mein homeserver über einen vpn tunnel ins inet geht.
Und ich will mich eben über einen vpn Tunnel von außerhalb verbinden um auf meine Geräte von unterwegs zugreifen zu können.
Hab hier jz was dazu gefunden:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=998690#top

So wies aussieht, muss ich den ovpn client auf dem homeserver direct laufen lassen

Dabei hatte ich mir extra den Router gekauft, weil der genug Leistung für den ovpn client bringt.
Der Homeserver wird mit zusätzlichem ovpn client wohl eher in die Knie gehn..

German Question Routers, Routing Networks