17
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.
Denke es könnte sich um ein DNS Problem handeln?
Was ist hier zu tun?
Danke.
LG, john
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 ACCEPTDenke es könnte sich um ein DNS Problem handeln?
Was ist hier zu tun?
Danke.
LG, john
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 358916
Url: https://administrator.de/forum/kein-zugriff-ins-www-openvpn-mit-dd-wrt-router-linksys-wrt1900acs-358916.html
Ausgedruckt am: 23.12.2024 um 07:12 Uhr
17 Kommentare
Neuester Kommentar
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
Best regards
Tom
iptables -t nat -A POSTROUTING -s 10.21.173.0/24 -j MASQUERADE 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:
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.
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 !!
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.
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 ACCEPTroot@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.
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.
...aber egalDer 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
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
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 ?!
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
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.
