ComputerBase Menü
Aktuelles

Kein Internet über OpenVPN / PiVPN

Nilson

Nilson

Grand Admiral
Registriert
Dez. 2008
Beiträge
25.065
Hallo zusammen,

ich versuche gerade ein VPN über OpenVPN / PiVPN einzurichten. Der Tunnel wird auch erfolgreich aufgebaut und ich kann auf meinen Pi zugreifen. Aber von dort geht es nicht weiter. Weder andere Geräte im Netz noch das Internet sind erreichbar.

Vorgegangen bin ich nach dieser Anleitung

Meine PiHole unter 10.10.10.110 kann ich erreichen (Weboberfläche über 10.10.10.110:8080/admin ist erreichbar) Das zeigt ja eigentlich, dass das Routing vom 10.8.0.0/24 ins 10.10.10.0/24 Subnetz funktioniert

Hier die entsprechenden (Log-)files. Das "offensichtliche" wie die Iptables hab ich schon überprüft. Jemand noch ne Idee wo ich schauen könnte?

793718

Bash: 
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server_6xPfM3yuz6kN41ng.crt
key /etc/openvpn/easy-rsa/pki/private/server_6xPfM3yuz6kN41ng.key
dh none
topology subnet
server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 10.10.10.110"
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
keepalive 1800 3600
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io

Bash: 
client
dev tun
proto udp
remote domain.tld 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_6xPfM3yuz6kN41ng name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-crypt>

Bash: 
Jun 22 10:17:32 raspberrypi ovpn-server[394]: 109.42.3.20:3053 TLS: Initial packet from [AF_INET]109.42.3.20:3053, sid=d0012333 5aead5f4
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 VERIFY OK: depth=1, CN=ChangeMe
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 Validating certificate key usage
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 ++ Certificate has key usage  0080, expects 0080
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 VERIFY KU OK
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 Validating certificate extended key usage
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 VERIFY EKU OK
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 VERIFY OK: depth=0, CN=OnePlus3
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 peer info: IV_GUI_VER=OC30Android
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 peer info: IV_VER=3.2
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 peer info: IV_PLAT=android
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 peer info: IV_NCP=2
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 peer info: IV_TCPNL=1
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 peer info: IV_PROTO=2
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 peer info: IV_AUTO_SESS=1
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384
Jun 22 10:17:33 raspberrypi ovpn-server[394]: 109.42.3.20:3053 [OnePlus3] Peer Connection Initiated with [AF_INET]109.42.3.20:3053
Jun 22 10:17:33 raspberrypi ovpn-server[394]: OnePlus3/109.42.3.20:3053 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Jun 22 10:17:33 raspberrypi ovpn-server[394]: OnePlus3/109.42.3.20:3053 MULTI: Learn: 10.8.0.2 -> OnePlus3/109.42.3.20:3053
Jun 22 10:17:33 raspberrypi ovpn-server[394]: OnePlus3/109.42.3.20:3053 MULTI: primary virtual IP for OnePlus3/109.42.3.20:3053: 10.8.0.2
Jun 22 10:17:33 raspberrypi ovpn-server[394]: OnePlus3/109.42.3.20:3053 PUSH: Received control message: 'PUSH_REQUEST'
Jun 22 10:17:33 raspberrypi ovpn-server[394]: OnePlus3/109.42.3.20:3053 SENT CONTROL [OnePlus3]: 'PUSH_REPLY,dhcp-option DNS 10.10.10.110,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 1800,ping-restart 3600,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Jun 22 10:17:33 raspberrypi ovpn-server[394]: OnePlus3/109.42.3.20:3053 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun 22 10:17:33 raspberrypi ovpn-server[394]: OnePlus3/109.42.3.20:3053 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key

Bash: 
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:2f:0d:e5:9d  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enxb827eb610193: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.110  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 fe80::678:5adc:e172:835d  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:61:01:93  txqueuelen 1000  (Ethernet)
        RX packets 222550  bytes 58083905 (55.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 209237  bytes 31416667 (29.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16293  bytes 1250583 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16293  bytes 1250583 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
        inet6 fe80::661c:3779:5ada:6679  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 314  bytes 24043 (23.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15098  bytes 1076803 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:34:54:c6  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Bash: 
Chain PREROUTING (policy ACCEPT)                 
target     prot opt source               destination                                       
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL
                    
Chain INPUT (policy ACCEPT)                               
target     prot opt source               destination
          
Chain OUTPUT (policy ACCEPT)                                   
target     prot opt source               destination               
DOCKER     all  --  anywhere            !loopback/8           ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)                                                               
target     prot opt source               destination                                                 
MASQUERADE  all  --  172.17.0.0/16        anywhere                                                 
MASQUERADE  all  --  10.8.0.0/24          anywhere   
                                          
Chain DOCKER (2 references)                                                                     
target     prot opt source               destination                                             
RETURN     all  --  anywhere             anywhere

Bash: 
1
 
Hatte ich geprüft (letzter Spoiler ;)) Ist aktiviert
 
Route im Router hinterlegt? Änderungen von 3.19 in der Anleitung berücksichtigt? Achtung: Ein pihole-Update macht diese rückgängig hatte das Problem auch mal
 
Meist du so?
793725

Hilft aber nicht.

Welche Änderung mit 3.19 meinst du?
 
Wie sieht denn die FORWARD chain aus? Du hast jetzt nur iptables -t nat -L gezeigt, aber nicht iptables -L bzw. genau genommen iptables -t filter -L

Am besten ist es, wenn man jetzt mittels WireShark bzw. tcpdump prüft ob Traffic durchgeht bzw. wo er hängen bleibt. Beispielsweise mit tcpdump icmp

So wie es aussieht hast du außerdem den VPN-Traffic geNATtet. Dann brauchst du sogesehen keine Rückroute im Router. Besser wäre es jedoch ganz ohne NAT, aber das erfordert dann eben ggfs höheren Konfigurationsaufwand, weil dann eben auch das Routing stimmen muss sowie der nächste Punkt: Die Firewall des jeweiligen Ziels im LAN.

Ohne NAT am VPN-Gateway benötigt jedes Ziel im LAN nicht nur eine Rückroute ins VPN-Subnetz (in der Regel über das Standard-Gateway und von dort dann über die oben gezeigte statische Route ins VPN-Subnetz), sondern auch eine Firewall-Regel, die eingehenden Traffic aus dem fremden VPN-Subnetz überhaupt erlaubt. So blockt Windows beispielsweise standardmäßig so ziemlich alles was außerhalb des eigenen Subnetzes liegt. Dann muss man in den erweiterten Einstellungen der Windows-Firewall bei den eingehenden Regeln entsprechend den IP-Bereich der Regeln so erweitern, dass auch Verbindungen von jenseits des eigenen Subnetzes erlaubt werden.
 
Hier die Ausgabe von iptables -t filter -L
Code: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere           
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (1 references)
target     prot opt source               destination         

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere           
RETURN     all  --  anywhere             anywhere           

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere           
RETURN     all  --  anywhere             anywhere           

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

In tcpdump muss ich mich erst einarbeiten.
 
Wenn ich das richtig sehe, wird alles was weitergeleitet werden soll (=FORWARD) in die DOCKER-USER -Chain geschickt und dann in die beiden DOCKER-ISOLATION chains. In der letzten wird dann alles geDROPped.

Ich bin nicht so firm mit Docker, aber dem Namen nach vermute ich mal, dass es so gedacht ist, dass man in der DOCKER-USER manuelle Einträge machen soll. Dort müsste dann eine ACCEPT-Regel für den gewünschten Traffic stehen.
 
Das da jetzt Docker mit reinspuckt ist natürlich ungünstig. Danke für den Hinweis.
 
Ich vermute mal, dass Docker dafür ein config-file hat, aber prinzipiell müsste die Regel so aussehen:


iptables -I DOCKER-USER -s vpnsubnetz -d lansubnetz -t ACCEPT

bzw andersherum natürlich analog

iptables -I DOCKER-USER -s lansubnetz -d vpnsubnetz -t ACCEPT

Angaben ohne Gewähr, weil aus dem Stegreif am Handy geschrieben. Wie gesagt gibt es vermutlich ein File für User-Rules, die Docker dann von dort in die Chain einträgt, weil manuelle Eingriffe ggfs vom Docker-Service gekillt werden, wenn er (neu)startet.
 
Hab nochmal drüber nachgedacht. Du kannst obige rules aus #11 natürlich auch mit -I FORWARD vor die DOCKER-USER chain direkt in die FORWARD chain reinhängen. So ist die Regel von Docker entkoppelt, weil Docker damit ja eigentlich nix zu tun hat.
 
Danke Raijin für die Antworten.

Sieht jetzt so aus
Bash: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere           
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (1 references)
target     prot opt source               destination         

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere           
RETURN     all  --  anywhere             anywhere           

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere           
RETURN     all  --  anywhere             anywhere           

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
ACCEPT     all  --  10.10.10.0/24        10.8.0.0/24         
ACCEPT     all  --  10.8.0.0/24          10.10.10.0/24       
RETURN     all  --  anywhere             anywhere
Leider ohne erfolg.
 
Nimm bitte erstmal die Masquerade-Regel für 10.8.0.0/24 raus. Man kann das korrekte Routing und die korrekten Firewall-Einstellungen nicht testen, wenn der Server alles NATtet.

An dieser Stelle muss man aber erstmal mit tcpdump/WireShark prüfen wo der Traffic hängen bleibt. Bisher habe ich nur ins Blaue geschossen, aber wenn das immer noch nicht funzt, liegt das Problem evtl ganz woanders.



Während du am VPN-Client einen Ping ins Server-LAN machst, prüfst du am PI

tcpdump -i tun0 icmp

Wenn du den Ping da siehst, dann schickt der VPN-Client zumindest den Ping korrekt ins VPN. Nun gehst du an das Zielgerät und je nach Betriebssystem machst du entweder das gleiche wie am PI - tun0 natürlich durch das (W)LAN-Interface ersetzen - oder wenn's Windows ist eben mit WireShark.

Der Rückweg muss dann natürlich auch stimmen, also entweder die Ping-Antwort verfolgen oder eben vom LAN-Client ins VPN pingen.

*edit
Ich bin morgen leider den ganzen Tag nicht da (Paintball), aber evtl. kommt ja noch einem anderen Foristen eine Idee oder wir müssen Montag weitermachen ;)
 
Wie ist der Stand?
 
Bin die Woche unterwegs. Melde mich dann
 
Ich hab damals den Pi neu aufgesetzt, ohne Docker. Da gabs dann keine Probleme
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

F
IP4 Route auf Raspbian
Antworten
4
Aufrufe
447
Raijin
Raijin
M
PIVPN Probleme
Antworten
10
Aufrufe
1.170
Majo74
M
R
  • Frage
Kein Internet über PiVPN / OpenVPN Client
Antworten
14
Aufrufe
3.671
n1tro666
N
darkiop
Wireguard Site2Site ohne Masquerading
Antworten
6
Aufrufe
2.895
riversource
R
conf_t
Fritzbox IPSec VPN mit Wireguard ablösen, Anleitungen funktionieren nicht
2
Antworten
25
Aufrufe
1.506
conf_t
conf_t
Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 165 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz