Dec 21, 2017, updated at 09:38:41 (UTC)

2448

Kein Zugriff ins WWW - OpenVPN mit DD-WRT Router (Linksys WRT1900ACS)

Hallo!

Habe auf meinen DD-WRT Router (Linksys WRT1900ACS) einen OpenVPN Server nach besten Gewissen eingerichtet.
Mein Ziel wäre es den kompletten Traffic durch das VPN zu schicken. Mittelfristig möchte ich mit zwei weiteren Routern zwei Wohnungen mit dem Elternhaus wo auch der DD-WRT Router/OpenVPN Server steht verbinden. Dachte hier an zwei zusätzliche DD-WRT Router wo ich die OpenVPN Client Funktion nutze. Aktuell teste ich aber am MacBook per Tunnelblick App auf macOS 10.12.6.

VPN Verbindung steht und ich kann auch auf alle im Elternhaus eingebundenen Gerätschaften (NAS, PC,..) zugreifen.
Zwar nur via manueller Eingabe (Finder --> mit Server verbinden) und nicht wie eigentlich erhofft über Finder "Freigaben", aber das ist wieder ein anderes Thema.
Allerdings habe ich wenn ich "push "redirect-gateway def1"" nutze um eben den kompletten Client-Traffic durch das VPN zu schicken am MacBook keinen Zugang mehr ins WWW.

Router Config:

root@:~# cat /tmp/openvpn/openvpn.conf 
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
keepalive 10 120
verb 3
mute 3
syslog
writepid /var/run/openvpnd.pid
management 127.0.0.1 14
management-log-cache 100
topology subnet
script-security 2
port 1194
proto udp
cipher aes-256-cbc
auth sha512
client-connect /tmp/openvpn/clcon.sh
client-disconnect /tmp/openvpn/cldiscon.sh
client-config-dir /tmp/openvpn/ccd
comp-lzo adaptive
tls-server
duplicate-cn
client-to-client
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
fast-io
tun-mtu 1500
mtu-disc yes
server 10.21.173.0 255.255.255.0
dev tun2
tun-ipv6
tls-auth /tmp/openvpn/ta.key 0
push "dhcp-option DNS 8.8.8.8"   
push "redirect-gateway def1"  

Client Config:
client
dev tun 1500
proto udp 1300
remote ++fixeIPv4publicIP++ 1194
resolv-retry infinite
nobind
persist-key
persist-tun
float
key-direction 1
remote-cert-tls server
verb 3
comp-lzo
cipher AES-256-CBC
auth SHA512
<ca>
-----BEGIN CERTIFICATE-----
MIIGpzCCBI+...

abgesetzte Firewall Commandos:

iptables -t nat -A POSTROUTING -a 10.21.173.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.21.173.0/24 -o eth0 -j SNAT --to $++fixeIPv4publicIP++
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I INPUT 3 -i tun0 -j ACCEPT
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

Denke es könnte sich um ein DNS Problem handeln?
Was ist hier zu tun?

Danke.

LG, john

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

Content-Key: 358916

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

Printed on: April 25, 2024 at 03:04 o'clock

17 Comments

Latest comment

einen OpenVPN Server nach besten Gewissen eingerichtet.

Hier steht genau was das Gewissen dir sagen sollte:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Mein Ziel wäre es den kompletten Traffic durch das VPN zu schicken.

Kein Problem, das ist dann eine simple Konfig Zeile in der server.conf Datei:
push "redirect-gateway def1"
Guckst du auch hier:
https://openvpn.net/index.php/open-source/documentation/howto.html#redir ...

zwei Wohnungen mit dem Elternhaus wo auch der DD-WRT Router/OpenVPN Server steht verbinden.

Ist ne simple Standort Vernetzung mit OpenVPN also ein einfacher Klassiker....

Dachte hier an zwei zusätzliche DD-WRT Router wo ich die OpenVPN Client Funktion nutze.

Eins der vielen Möglichkeiten....
Ein kleiner Raspberry Pi kann das auch sollten da schon Router vorhanden sein:
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
bzw.
https://jankarres.de/2014/10/raspberry-pi-openvpn-vpn-client-installiere ...
usw. usw.

und nicht wie eigentlich erhofft über Finder "Freigaben", aber das ist wieder ein anderes Thema.

Stimmt, das kann nicht gehen, denn UDP Naming Broadcasts werden prinzipienbedingt über geroutete Verbindungen nicht übertragen bekanntlich. Dafür gibt es aber einen sehr einfachen Workaround über die hosts oder lmhosts Datei:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Oder mit einem kleinen eigenen DNS Server:
https://www.heise.de/ct/ausgabe/2017-12-Namensaufloesung-inklusive-Daten ...
Was dann wieder der RasPi miterledigen kann...

nutze um eben den kompletten Client-Traffic durch das VPN zu schicken am MacBook keinen Zugang mehr ins WWW.

Dann hast du auf der Serverseite ein Konfigurationsfehler gemacht !!
Erstmal solltest du feststellen ob du nur ein DNS Problem hast oder auch ein Routing Problem, oder beides.
Im Mac Terminal gibst du bei aktivem Client mal ein ping 8.8.8.8 ein um zu sehen ob du nackte IPs pingen kannst.
Auch ein traceroute -I 8.8.8.8 wäre hier hilfreich um ein Hop für Hop zu sehen und zu erkennen wo es kneift. (Das -I musst du machen damit Mac OS ICMP nutzt für den Ping)
Die Problematik hier ist das der Mac Client natürlich auch einen DNS bekommen muss den er über das VPN Gateway Redirect erreichen kann. Steht der DNS noch auf einer lokalen IP ists natürlich aus mit der Namensauflösung ! Klar. Die Terminalkommandos nslookup oder dig sind hier deine besten Freunde

Dem Client den Google DNS zu konfigurieren machen heutzutage nur noch weltfremde Dummies. Sorry, aber jeder weiß mittlerweile das Google detailierte Profile über diese Nutzer erstellt und die an Dritte vermarktet. Wenn dir deine Privatsphäre also was wert ist setzt du da besser immer die Proxy DNS IP des Internet Routers auf der OVPN Serverseite ein ! Die IP die auch lokale Endgeräte in dem Netzwerk haben.
Wenns unbedingt eine externe sein muss dann etwas Datenschutz freundliches:
https://www.heise.de/newsticker/meldung/Quad9-Datenschutzfreundliche-Alt ...
Besser aber immer lokale Resourcen !

Die Tücken in kaskadierten Designs beschreibt dieses Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
und auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Leider ist nicht ganz klar ob du so eine Kaskade hast oder der WRT dein einziger Hauptrouter ins Internet ist ?!
In einer Kaskade (und auch nur dann) wäre das Masquerading dann kontraproduktiv.

NAT Rules are not right. Line 3 and 4 need to be only one rule

iptables -t nat -A POSTROUTING -s 10.21.173.0/24 -j MASQUERADE

Best regards
Tom

Schaut nach nicht viel aus wenn ich die Befehle unter verbundener VPN Verbindung absetze...

user-MacBook-Pro:~ user$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
^C
--- 8.8.8.8 ping statistics ---
14 packets transmitted, 0 packets received, 100.0% packet loss
user-MacBook-Pro:~ user$ traceroute -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
 1  10.21.173.1 (10.21.173.1)  13.008 ms  17.378 ms  14.315 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * *^C
user-MacBook-Pro:~ user$

Show us the actual routing table of the mac when it's connected to the vpn, please.

Bei 10.21.173.1 endet der Traceroute, dann ist dort auch der Fehler !
Ist das das interne OVPN IP Netzwerk ??
Oder ist das die LAN IP des OVPN Servers ?
Ist der OVPN Server auch gleich der Router ins Internet oder ist das eine Kaskade.
Falls der Server separat ist oder es eine Kaskade ist benötigt der OVPN Server natürlich eine Default Router auf den Internet Router !
Genauso benötigt der Internet Router zwingend eine statische Route auf das interne OVPN Netzwerk was in der server.conf mit dem Kommando server 10.21.173.0 255.255.255.0 definiert ist sofern OVPN und Internet Router getrennte Geräte sind.
Wie Kollege SimpleCode schon sagt "Show us the actual routing table of the mac when it's connected to the vpn, please."
Allerdinsg dürfte die Routing Tabelle klar sein, denn es geht durch das Gateway Redirect ALLES in den Tunnel.
Sieht man auch daran das ja der next Hop beim 8.8.8.8er Ping schon der OVPN Server ist.
Der hat aber keine Default Route ins Internet das ist das Problem.

Weitere Fragen:

Was bzw. WO wird der DHCP Pool mit der IP 192.168.17.1 vergeben ?? Sieht doch nach einer Kaskade aus ?? Mal abgesehen davon sollte man einen dynamischen Pool niemals bei den Anfangs und Endadressen des Netzes starten lassen weil dort die große Gefahr von Adress Überschneidungen passiert. Hier solltest du den Pool besser bei der .17.100 starten lassen !! Also von .100 bis .150 !!

Der LAN Port dieses Gerätes selber hat ja schon die .17.1. Da nimmt das Unglück dann schon seinen Lauf !!!
Wenn der DHCP Server auch noch die .1 vergibt hast du Adress Chaos.
Das solltest du also DRINGENST ändern im DHCP Server !

Leider ist NICHT klar WO diese 192.168.17er Adresse vergeben ist ??
Ist das der LAN Port des DD-WRT ?
Gibt es einen Kaskade Router Internet Router zusätzlich.
Eine kleine Topologie Skizze wäre sicher hier hilfreich wenn dem so ist.

user-MacBook-Pro:~ user$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.21.173.1        UGSc            8        0   utun4
default            192.168.0.1        UGSc           31       30     en0
10.21.173/24       10.21.173.2        UGSc           10        0   utun4
10.21.173.2        10.21.173.2        UH              3        1   utun4
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              5   140247     lo0
128.0/1            10.21.173.1        UGSc            0        0   utun4
169.254            link#4             UCS             0        0     en0
185.151.22.13/32   192.168.0.1        UGSc            1        0     en0
192.168.0          link#4             UCS             3        0     en0
192.168.0.1/32     link#4             UCS             1        0     en0
192.168.0.1        6c:70:9f:d3:f8:c3  UHLWIir        13   907037     en0    868
192.168.0.2        20:c9:d0:ad:c2:2a  UHLWI           0        0     en0   1022
192.168.0.4/32     link#4             UCS             1        0     en0
192.168.0.4        b8:e8:56:3a:9d:70  UHLWIi          1       10     lo0
192.168.0.5        88:66:a5:db:79:99  UHLWI           0      133     en0
192.168.0.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        8     en0
224.0.0/4          link#4             UmCS            2        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0      885     en0
255.255.255.255/32 link#4             UCS             1        0     en0
255.255.255.255    ff:ff:ff:ff:ff:ff  UHLWbI          0        4     en0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
default                                 fe80::%utun0                    UGcI          utun0
default                                 fe80::%utun2                    UGcI          utun2
default                                 fe80::%utun3                    UGcI          utun3
::1                                     ::1                             UHL             lo0
fd43:9230:cf58:9a35::/64                fe80::a5b2:49f1:b693:1fb8%utun1 Uc            utun1
fd43:9230:cf58:9a35:a5b2:49f1:b693:1fb8 link#11                         UHL             lo0
fdb0:3c8a:d934:1094:6e70:9fff:fed3:f8c3 fd43:9230:cf58:9a35:a5b2:49f1:b693:1fb8 UGHS          utun1
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0
fe80::403:56ce:f138:f94%en0             88:66:a5:db:79:99               UHLWI           en0
fe80::10c8:2dad:ecf:63eb%en0            b8:e8:56:3a:9d:70               UHLI            lo0
fe80::%awdl0/64                         link#9                          UCI           awdl0
fe80::9cad:f5ff:fede:789d%awdl0         9e:ad:f5:de:78:9d               UHLI            lo0
fe80::%utun0/64                         fe80::5534:c323:8d45:402c%utun0 UcI           utun0
fe80::5534:c323:8d45:402c%utun0         link#10                         UHLI            lo0
fe80::%utun1/64                         fe80::a5b2:49f1:b693:1fb8%utun1 UcI           utun1
fe80::a5b2:49f1:b693:1fb8%utun1         link#11                         UHLI            lo0
fe80::%utun2/64                         fe80::ccb4:c2ea:ef31:a6b8%utun2 UcI           utun2
fe80::ccb4:c2ea:ef31:a6b8%utun2         link#12                         UHLI            lo0
fe80::%utun3/64                         fe80::d545:9a83:e94:1490%utun3  UcI           utun3
fe80::d545:9a83:e94:1490%utun3          link#13                         UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en0/32                           link#4                          UmCI            en0
ff01::%awdl0/32                         link#9                          UmCI          awdl0
ff01::%utun0/32                         fe80::5534:c323:8d45:402c%utun0 UmCI          utun0
ff01::%utun1/32                         fe80::a5b2:49f1:b693:1fb8%utun1 UmCI          utun1
ff01::%utun2/32                         fe80::ccb4:c2ea:ef31:a6b8%utun2 UmCI          utun2
ff01::%utun3/32                         fe80::d545:9a83:e94:1490%utun3  UmCI          utun3
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en0/32                           link#4                          UmCI            en0
ff02::%awdl0/32                         link#9                          UmCI          awdl0
ff02::%utun0/32                         fe80::5534:c323:8d45:402c%utun0 UmCI          utun0
ff02::%utun1/32                         fe80::a5b2:49f1:b693:1fb8%utun1 UmCI          utun1
ff02::%utun2/32                         fe80::ccb4:c2ea:ef31:a6b8%utun2 UmCI          utun2
ff02::%utun3/32                         fe80::d545:9a83:e94:1490%utun3  UmCI          utun3
user-MacBook-Pro:~ user$ 

Danke für eure Unterstützung!

10.21.173.1 ist wie auch im Screenshot zu sehen das OVPN IP Netzwerk.
Ja der DD-WRT Router ist auch der Router der ins Internet geht, dahinter hängt nur mehr ein Glasfaser Teilnehmerendgerät.
Ok, habe jetzt den DHCP Pool auf 192.168.17.100 geändert.

Habe vorhin mit einem Backup zurückgesichert, jetzt wurden nur mehr diese vier Regeln abgesetzt. Leider nach wie vor im VPN-Netz kein Zugriff ins WWW.

iptables -t nat -A POSTROUTING -a 10.21.173.0/24 -j MASQUERADE
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I INPUT 3 -i tun0 -j ACCEPT
iptables -I FORWARD 1 --source 10.21.173.0/24 -j ACCEPT

root@WRT:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere            udp dpt:1194 
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     0    --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             anywhere            udp spt:bootps dpt:bootpc 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:1194 
ACCEPT     0    --  anywhere             anywhere            
DROP       udp  --  anywhere             anywhere            udp dpt:route 
DROP       udp  --  anywhere             anywhere            udp dpt:route 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:route 
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     igmp --  anywhere             anywhere            
ACCEPT     0    --  anywhere             anywhere            state NEW 
ACCEPT     0    --  anywhere             anywhere            state NEW 
DROP       0    --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     0    --  10.21.173.0/24       anywhere            
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     gre  --  192.168.17.0/24      anywhere            
ACCEPT     tcp  --  192.168.17.0/24      anywhere            tcp dpt:1723 
ACCEPT     0    --  anywhere             anywhere            
ACCEPT     0    --  anywhere             anywhere            
lan2wan    0    --  anywhere             anywhere            
REJECT     tcp  --  anywhere             anywhere            WEBSTR match content 15 reject-with tcp-reset 
ACCEPT     0    --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             base-address.mcast.net/4 
ACCEPT     udp  --  anywhere             192.168.17.34       udp dpt:5353 
ACCEPT     udp  --  anywhere             192.168.17.34       udp dpt:4500 
TRIGGER    0    --  anywhere             anywhere            TRIGGER type:in match:0 relate:0 
trigger_out  0    --  anywhere             anywhere            
ACCEPT     0    --  anywhere             anywhere            state NEW 
DROP       0    --  anywhere             anywhere            

On this screenshot "Redirect Gateway" is "disabled" ??
And for the MASQUERADE rules see my first post above.

The routing table on the Mac is OK. If you post the RT of the router als that would be good.

Gut, leider ja ein kurzes Gastspiel vom Kollegen SimpleCode jetzt abgemeldet

...aber egal

Der DD-WRT blockiert vermutlich irgendwie Pakete aus dem 10.21.173.0/24 indem er sie entweder nicht routet oder nicht richtig NATet ins Internet.
Die iptables Regel ist in so fern auch irgendwie komisch das das FORWARDING Statement für 10.21.173.0/24 nach dem NAT für dieses netz kommt.
Ich bin jetzt kein iptables Guru aber in anderen Regelwerken ist es so das in der Firewall erstmal das Forwarding kommt und dann das NAT. Das mag aber bei iptables anders sein.
Normal bräuchte man da auch nicht fummeln, denn OpenWRT macht sowas eigentlich von sich aus wenn der OVPN Server konfiguriert ist.
Es kann m.E. nur noch an diesen vermutlich falschem iptables Regelwerk liegen.
Route Table vom Client ist OK, das sieht man ja eh auch daran das alles in den Tunnel geht. Vermutlich NATet aber der OpenWRT den 10er VPN Tunneltraffic nicht und deshalb ist dann da Schluss.

Regarding "Redirect Gateway", see the "Additional Config" in the router tab on the screenshot above.

What do you mean with "NAT Rules are not right. Line 3 and 4 need to be only one rule" exactly?
After the restore yesterday, i set only this iptables rule --> iptables -t nat -A POSTROUTING -a 10.21.173.0/24 -j MASQUERADE

root@WRT:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere            udp dpt:1194 
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     0    --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             anywhere            udp spt:bootps dpt:bootpc 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:1194 
ACCEPT     0    --  anywhere             anywhere            
DROP       udp  --  anywhere             anywhere            udp dpt:route 
DROP       udp  --  anywhere             anywhere            udp dpt:route 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:route 
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     igmp --  anywhere             anywhere            
ACCEPT     0    --  anywhere             anywhere            state NEW 
ACCEPT     0    --  anywhere             anywhere            state NEW 
DROP       0    --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             Thomas-MBP          udp dpt:5353 
ACCEPT     udp  --  anywhere             Thomas-MBP          udp dpt:4500 
ACCEPT     0    --  10.21.173.0/24       anywhere            
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     gre  --  192.168.17.0/24      anywhere            
ACCEPT     tcp  --  192.168.17.0/24      anywhere            tcp dpt:1723 
ACCEPT     0    --  anywhere             anywhere            
ACCEPT     0    --  anywhere             anywhere            
lan2wan    0    --  anywhere             anywhere            
REJECT     tcp  --  anywhere             anywhere            WEBSTR match content 15 reject-with tcp-reset 
ACCEPT     0    --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             base-address.mcast.net/4 
ACCEPT     udp  --  anywhere             192.168.17.34       udp dpt:5353 
ACCEPT     udp  --  anywhere             192.168.17.34       udp dpt:4500 
TRIGGER    0    --  anywhere             anywhere            TRIGGER type:in match:0 relate:0 
trigger_out  0    --  anywhere             anywhere            
ACCEPT     0    --  anywhere             anywhere            state NEW 
DROP       0    --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain advgrp_1 (0 references)
target     prot opt source               destination         

Chain advgrp_10 (0 references)
target     prot opt source               destination         

Chain advgrp_2 (0 references)
target     prot opt source               destination         

Chain advgrp_3 (0 references)
target     prot opt source               destination         

Chain advgrp_4 (0 references)
target     prot opt source               destination         

Chain advgrp_5 (0 references)
target     prot opt source               destination         

Chain advgrp_6 (0 references)
target     prot opt source               destination         

Chain advgrp_7 (0 references)
target     prot opt source               destination         

Chain advgrp_8 (0 references)
target     prot opt source               destination         

Chain advgrp_9 (0 references)
target     prot opt source               destination         

Chain grp_1 (0 references)
target     prot opt source               destination         

Chain grp_10 (0 references)
target     prot opt source               destination         

Chain grp_2 (0 references)
target     prot opt source               destination         

Chain grp_3 (0 references)
target     prot opt source               destination         

Chain grp_4 (0 references)
target     prot opt source               destination         

Chain grp_5 (0 references)
target     prot opt source               destination         

Chain grp_6 (0 references)
target     prot opt source               destination         

Chain grp_7 (0 references)
target     prot opt source               destination         

Chain grp_8 (0 references)
target     prot opt source               destination         

Chain grp_9 (0 references)
target     prot opt source               destination         

Chain lan2wan (1 references)
target     prot opt source               destination         

Chain logaccept (0 references)
target     prot opt source               destination         
ACCEPT     0    --  anywhere             anywhere            

Chain logdrop (0 references)
target     prot opt source               destination         
DROP       0    --  anywhere             anywhere            

Chain logreject (0 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset 

Chain trigger_out (1 references)
target     prot opt source               destination         
root@WRT:~# 

Du brauchst nicht mehr in Englisch zu antworten. Kollege SimpleCode hat sich am 21.12. aus diesem Forum wieder abgemeldet und wird deinen Frage also nicht mehr lesen ! Deshalb hat er jetzt ne Dummy UserID 134998.

Ok, danke für die Aufklärung.

Welche FW Regeln und in welcher Reihenfolge sollten deiner Meinung nach abgesetzt werden? Ganz ohne gehts wohl nicht.
Überlege den Router inkl. Open VPN Server nochmals komplett neu zu flashen und einzurichten.

Handelt sich hier nicht um das gleiche Problem?
DD WRT OpenVPN keine Internetverbindung

Ganz ohne gehts wohl nicht.

Eigentlich sollte es das. Bei einem DD-WRT hier auf einem ollen WRT54 musste man nichts extra konfigurieren, das rannte out of the Box mit dieser Konfig:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Neu zu flashen brauchst du ja nicht. Es reicht wenn du DD-WRT auf die Factory Defaults zurücksetzt.

Leider kein Erfolg! Hat hier noch irgendjemand Ideen dazu?

Wie gesagt...hier auf einem alten DD-WRT geflashten Linksys WRT54 mit OpenVPN kein Problem...klappt auf Anhieb ohne zusätzliches "Finetuning".
Folglich kann also nur was an deiner Konfig falsch sein.
Vielleicht alles nochmal jungfräulich aufsetzen und neu konfigurieren ?!

Hallo!

1) Konnte das Problem mit “gesamten traffic durch das vpn routen” noch nicht lösen. Wobei ich auch etwas davon abgekommen bin. Für die Nutzung öffentlicher Wifi’s wäre es vorteilhaft, sonst eigentlich nicht.

2) Hätte gestern versucht mein am OSX mit Tunnelblick und unter iOS mit der mobilen OpenVPN App verwendetes Client-Konfiguration.ovpn unter Windows mit dem OpenVPN Client zum laufen zu bekommen. Aber er schreibt mir ins Log er kann Teile/Zeichen der Konfigurations-Datei nicht interpretieren. Habe die Datei dann nochmals unter OS x gegengeprüft und lief sofort. Es kommt nicht mal zur Passwort-Abfrage meines Keys.

Jemand dazu eine Idee?

Gruß, john

er schreibt mir ins Log er kann Teile/Zeichen der Konfigurations-Datei nicht interpretieren.

Dann hast du da ja vermutlich Syntax Fehler in der Konfig begangen. Im Grunde ist das ein Kinderspiel. Die Grudnlagen sind in diesem Forums Tutorial erklärt:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die OpenVPN Konfig Syntax ist auf allen Betriebssystemen immer gleich.

Es kommt nicht mal zur Passwort-Abfrage meines Keys.

Dazu kann es auch niemals kommen wenn du (hoffentlich !) mit Zertifikaten arbeitest wie es sich gehört ! Da jibbet nix Passwörter !!
Wie gesagt lies dir das obige Tutorial genau durch. Da steht alles was du wissen musst damit es sofort auf Anhieb klappt

Hilfreiche Infos auch hier:
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
und
https://blog.doenselmann.com/raspberry-pi-als-openvpn-server/
Hilfreich und zielführend wären auch mal diese Logs zu posten um die Fehler zu sehen, denn die geben einen genauen Hinweis auf das was du falsch gemacht hast in deiner OVPN Konfig.

German solved Question Routers, Routing Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments