VPN verbindet, aber kein Traffic geht durch?!

[Fabian_otto]

Hi an alle,

habe "erfolgreich" einen OpenVPN Server aufgesetzt und kann dahin auch verbinden. Allerdings geht kein Traffic durch den VPN und ich bekomme am externen Gerät keine neue WAN IP. Hier mal ein Auszug aus dem LOG:

"Tue Jun 11 08:30:04 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]MY_IP:1194
Tue Jun 11 08:30:04 2019 UDP link local: (not bound)
Tue Jun 11 08:30:04 2019 UDP link remote: [AF_INET]MY_IP:1194
Tue Jun 11 08:30:05 2019 [MY_DDNS] Peer Connection Initiated with [AF_INET]MY_IP:1194
Tue Jun 11 08:30:06 2019 open_tun
Tue Jun 11 08:30:06 2019 TAP-WIN32 device [MY_DDNS] opened: \\.\Global\{6F283042-B497-44F7-84E2-BF3FA3AB407A}.tap
Tue Jun 11 08:30:06 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.0.1.2/255.255.255.0 on interface {6F283042-B497-44F7-84E2-BF3FA3AB407A} [DHCP-serv: 10.0.1.0, lease-time: 31536000]
Tue Jun 11 08:30:06 2019 Successful ARP Flush on interface [7] {6F283042-B497-44F7-84E2-BF3FA3AB407A}
Tue Jun 11 08:30:11 2019 Initialization Sequence Completed"
"
Bin für jeden Tipp dankbar.

Viele Grüße

 

[DeusoftheWired]

Kannst du Geräte aus dem entfernten LAN mit ihrer lokalen IP pingen?

 

[ms007]

Stell mal die server.ovpn und client.ovpn und ggf. die zugehörige ccd hier rein (ohne DNS- / IP des Servers und Zertifikatsangaben) ...

 

[Raijin]

Das Log sagt leider so ziemlich gar nichts aus abgesehen davon, dass der Tunnel hergestellt wurde. Es wäre hilfreicher, wenn du die Konfigurationsdateien von Server bzw. Client hier postest (ggfs sensible Daten entfernen).

Ins Blaue geschossen: Du hast die option "redirect-gateway" vergessen. Damit wird überhaupt erst das Standard-Gateway des Clients geändert. Die Option kannst du wahlweise direkt in die client.conf oder mit push in der server.conf eintragen.

Um weitergehende Hilfe zu leisten, müsste man auch wissen auf welchen Geräten Server bzw. Client läuft. So muss beispielsweise auch das Betriebssystem des Servers erstmal dafür eingerichtet werden, überhaupt Daten zu routen. Standardmäßig wird nämlich alles in die Tonne getreten was nicht explizit an das Gerät selbst gerichtet ist - geroutet wird nur, wenn es explizit konfiguriert wird.
Darüber hinaus muss ggfs auch NAT eingerichtet werden, wenn der Internet-Router am Server keine manuellen Routen zulässt (im Detail: die Route ins VPN-Subnetz).

 

[Fabian_otto]

Stell mal die server.ovpn und client.ovpn und ggf. die zugehörige ccd hier rein (ohne DNS- / IP des Servers und Zertifikatsangaben) ...

ccd?

hier die anonymisierten (IP und mail) OVPNs

Spoiler: server ovpn

"
port 1194
proto udp
tun-mtu 1500
tun-mtu-extra 32
mssfix 1460
dev tap
dev-node My_DDNS
<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha512WithRSAEncryption
Issuer: C=CA, ST=AB, L=Edmonton, O=Stalwart, CN=My_DDNS/emailAddress=My_MAIL
Validity
Not Before: Jun 11 11:43:23 2019 GMT
Not After : Jun 8 11:43:23 2029 GMT
Subject: C=CA, ST=AB, O=Stalwart, CN=My_DDNS/emailAddress=My_MAIL
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:a2:3f:1d:0d:48:20:53:bf:b8:cf:b8:06:5e:64:
77:56:ac:31:5c:d8:06:0d:53:9b:91:0a:e9:11:4d:
8c:fb:d8:6d:3a:d4:b2:e5:f6:7a:4e:36:42:e8:53:
3e:0e:d3:8b:3b:19:1b:00:8c:98:3e:2c:c6:62:0b:
5b:b3:46:80:0b:91:fc:47:bb:40:3d:ee:08:a5:ee:
a1:ff:19:4b:9f:11:6d:c0:26:df:24:57:97:11:e7:
75:64:85:18:f0:7e:5a:5c:54:af:12:b6:16:e9:ce:
65:88:c2:b8:51:1b:fc:26:bc:7d:37:1d:e2:9f:bb:
85:27:5e:dc:7f:68:90:3c:e5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
X509v3 Subject Key Identifier:
77:E6:13:5C:65:9B:B8:F0:80:4A:63:5F2:A5:65:9D:03:5F:6E:7E
X509v3 Authority Key Identifier:
keyid:6D:C0:AE:51:5C:C33:39:C2:14:CA:B9F:3C:72:62:6B:E06:E9
DirName:/C=CA/ST=AB/L=Edmonton/O=Stalwart/CN=My_DDNS/emailAddress=My_MAIL
serial:C8:EB:59:5F:A3:3F:03B

X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment
Signature Algorithm: sha512WithRSAEncryption
7d:6f:ca:3a:6f:e9:43:ac:9b:8c:ab:3e:64:b3:24:6c:2e:03:
04:c7:74:6e:b0:a0:9f:91:f7:cb:60:98:d3:69:17:06:d8:fe:
0f:a4:84:9f:14:17:05:b3:5f:ee:53:64:00:d8:52:fd:ae:19:
e0:62:78:20:34:87:f4:bb:9f:d0:8f:3a:14:9a:07:6a:48:e8:
8c:aa:7d:f0:94:85:aa:72:75:85:ab:67:a8:71:ef:33:d3:ec:
27:d9:99:13:65:74:b2:61:63:50:0d:4a:e2:e3:9a:dc:d5:da:
71:0c:f8:31:5f:62:ee:31:66:d6:dd:f4:28:f7:00:aa:c5:f9:
25:2c
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----
</key>
dh "../easy-rsa/keys/My_DDNS.dh.pem"
server 10.0.1.0 255.255.255.0
ifconfig-pool-persist "My_DDNS.ipp.txt"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
max-clients 100
persist-key
persist-tun
status "My_DDNS.status.log"
verb 1
;client-to-client
;user nobody
;group nobody
tls-server
key-direction 0
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----

-----END OpenVPN Static key V1-----
</tls-auth>
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
crl-verify "../easy-rsa/keys/My_DDNS.crl.pem""

und client

Spoiler: client ovpn

"
client
;Settings in this file are client-specific. You may want to push some settings from the server's ovpn file instead.
;You may want to review "--push option" and "--push-reset" at: https://openvpn.net/index.php/manuals.html
;INTERNET ACCESS: Route client traffic through the server. (Must enable Internet Connection Sharing or other Network Address Translation on the server.)
;redirect-gateway def1 bypass-dhcp
;Enable if you actually have a domain. (You probably don't need this.)
;dhcp-option DOMAIN MY_DDNS
;Enable if your OVPN server is a DNS server (or forwarder). This will hide your DNS queries.
;dhcp-option DNS 10.0.1.1
;Enable if your OVPN server is a WINS server (or forwarder)...
;dhcp-option WINS 10.0.1.1
;Enable if your OVPN server is a NBDD server (or forwarder)...
;dhcp-option NBDD 10.0.1.1
;Enable if your OVPN server is a time server (NetTime is a good/full time server).
;dhcp-option NTP 10.0.1.1
;Untested NetBIOS (which I never use):
;dhcp-option NBT 8
;Untested NetBIOS scope id:
;dhcp-option NBS "@MY_DDNS"
;Enable this if you don't need NetBIOS (I personally always disable NetBIOS).
;dhcp-option DISABLE-NBT

dev tap
;To determine the correct MTU, you can ping the server with fragmentation turned off, and try different values until you find the max supported that doesn't fragment. For example: ping 10.0.0.1 -f -l 1500
tun-mtu 1500
tun-mtu-extra 32
;This should be the MTU - 40
mssfix 1460
;Note that mtu-disc isn't supported on Windows so it must be disabled there, or OpenVPN won't start.
;mtu-disc yes
dev-node "MY_DDNS"
proto udp
resolv-retry infinite
nobind
cipher AES-256-CBC
comp-lzo
tls-client
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----

-----END OpenVPN Static key V1-----
</tls-auth>
key-direction 1
;Prevent passwords from being cached (in case you use askpass or auth-user-pass).
auth-nocache
remote-cert-tls server
remote MY_DDNS 1194
<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha512WithRSAEncryption
Issuer: C=CA, ST=AB, L=Edmonton, O=Stalwart, CN=MY_DDNS/emailAddress=MY_MAIL
Validity
Not Before: Jun 11 11:43:56 2019 GMT
Not After : Jun 8 11:43:56 2029 GMT
Subject: C=CA, ST=AB, O=Stalwart, CN=lkwpeter@MY_DDNS/emailAddress=MY_MAIL
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:9d:a1:59:e0:b7:89:28:8d:f7:75:d8:db:ad:67:
bb:9d:13:cd:65:ef:68:dc:c4:ac:0b:c9:92:d5:27:
b9:81:f4:91:81:c9:3e:9a:64:18:d2:e1:41:99:f9:
9e:b1:d6:67:ef:f8:5a:cb:d1:b1:a6:00:a6:86:ba:
8e:0d:c2:2e:df:b1:dc:9a:34:c2:59:e3:f8:e6:50:
57:df:5a:51:2b:82:60:02:bd:d0:4a:15:51:0b:7f:
7b:2b:08:48:b6:32:50:8f:9d:eb:ee:39:3a:c1:d1:
b3:70:d8:fc:ab:3a:b1:d3:64:8e:0d:1b:b1:cd:87:
73:c3:fd:bd:c0:e8:10:bf:89
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
DB:5B:88:66:93:69:F5:21:42:B3:CC:C6:9DE:B4:71:58:5BC:69
X509v3 Authority Key Identifier:
keyid:6D:C0:AE:51:5C:C33:39:C2:14:CA:B9F:3C:72:62:6B:E06:E9
DirName:/C=CA/ST=AB/L=Edmonton/O=Stalwart/CN=MY_DDNS/emailAddress=MY_MAIL
serial:C8:EB:59:5F:A3:3F:03B

X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Client Authentication
Signature Algorithm: sha512WithRSAEncryption
b2:2d:cb:5d:fc:76:30:0e:27:40:0b:25:f0:e4:43:24:d9:ee:
ba:17:cd:dd:b2:68:b2:1c:4b:02:0c:97:46:82:76:7d:0b:e3:
ca:e7:6b:1d:4f:c2:cd:04:eb:35:83:24:fa:d7:77:66:de:6a:
18:a3:50:c6:0c:01:ad:0f:61:ab:68:ea:4c:10:d7:e9:8a:05:
be:68:02:92:d8:ac:50:fa:51:90:69:4a:b0:4b:b2:bc:f4:11:
c6:3a:df:9a:9e:f9:0c:4e:dc:01:8b:d9:68:93:13:78:97:0e:
d5:13:22:b0:52:06:01:ca:3d:fb:32:9d:55:5d:41:a4:b9:03:
40:27
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----
</key>
persist-key
persist-tun
verb 1
"

Ergänzung (11. Juni 2019)

Das Log sagt leider so ziemlich gar nichts aus abgesehen davon, dass der Tunnel hergestellt wurde. Es wäre hilfreicher, wenn du die Konfigurationsdateien von Server bzw. Client hier postest (ggfs sensible Daten entfernen).

Ins Blaue geschossen: Du hast die option "redirect-gateway" vergessen. Damit wird überhaupt erst das Standard-Gateway des Clients geändert. Die Option kannst du wahlweise direkt in die client.conf oder mit push in der server.conf eintragen.

Um weitergehende Hilfe zu leisten, müsste man auch wissen auf welchen Geräten Server bzw. Client läuft. So muss beispielsweise auch das Betriebssystem des Servers erstmal dafür eingerichtet werden, überhaupt Daten zu routen. Standardmäßig wird nämlich alles in die Tonne getreten was nicht explizit an das Gerät selbst gerichtet ist - geroutet wird nur, wenn es explizit konfiguriert wird.
Darüber hinaus muss ggfs auch NAT eingerichtet werden, wenn der Internet-Router am Server keine manuellen Routen zulässt (im Detail: die Route ins VPN-Subnetz).

server läuft auf windows 10 mit deaktivierter firewall hinter einem router (im router portfreigabe auf die server-IP).
verbindung scheint ja auch zu klappen, aber eben nicht richtig mit fremd-WAN-IP etc.

 

[Raijin]

Du hast mich falsch verstanden. Wenn ein PC - sei es mit Windows oder Linux - einen VPN-Server stellt und den Traffic vom VPN ins www routen soll, dann muss er eben auch routen und das wird er out-of-the-box nicht tun.

Wenn man ein 08/15 Desktop-Betriebssystem installiert, wird dieses BS sämtliche Netzwerkpakete komplett ignorieren, wenn sie nicht direkt an diesen PC gerichtet sind. Heißt im Klartext: Ein Ping auf die IP des PCs wird beantwortet, aber sobald ein Ping am Netzwerk- bzw. VPN-Adapter ankommt, der zB an 8.8.8.8 gerichtet ist, wird Windows schlicht und ergreifend sagen "8.8.8.8 bin ich nicht, interessiert mich nicht."

Unter Windows wird die Routing-Funktionalität in der Registry aktiviert:

HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ Tcpip\ Parameters
--> "IPEnableRouter" als REG_DWORD auf 1 setzen

Erst jetzt würde Windows bei besagtem eingehenden Ping auf 8.8.8.8 schauen wohin der Ping denn nu weitergeleitet aka geroutet werden soll.


Ein weiterer Punkt ist aber der Rückweg. Besagter Ping, der über das VPN reinkommt hat auch eine AbsendeIP. Diese ist bei VPN in der Regel die VPN-IP des Clients (bei OpenVPN standardmäßig 10.8.0.x). Nehmen wir nun mal an ein Ping mit Ziel 8.8.8.8 kommt beim VPN-Server an, Absender 10.8.0.123. Windows schaut in der Routing-Tabelle nach und leitet den Ping an das Standardgateway weiter, in der Regel der Internetrouter. Dieser guckt sich auch das Ziel an und macht dasselbe wie Windows -> an das Standardgateway schicken (=Internet Provider). Zuvor ersetzt der Internetrouter aber noch die AbsendeIP mit seiner WAN-IP. Der Ping kommt dann irgendwann bei 8.8.8.8 an und wird an die AbsendeIP beantwortet (die WAN-IP). Der Internetrouter bekommt die Antwort, merkt, dass sie zum Ping von 10.8.0.123 gehört und will die Antwort dahin weiterleiten - nur wohin?

An dieser Stelle benötigt der Internetrouter entweder eine Netzwerkroute ins 10.8.0.0/24 (das VPN-Subnetz) via die lokale LAN-IP des Windows-VPN-Servers oder dieser Windows-VPN-Server muss ganz ähnlich wie der Router zuvor beim Abschicken des Pings ebenfalls die AbsendeIP maskieren, so dass der Internetrouter beim Rückweg die Ping-Antwort an den Server weiterleitet, der dann wiederum zum VPN-Client durchreicht.


Lange Rede, kurzer Sinn:

• IPEnableRouter = 1 setzen
  
  
  
  
  
• im InternetRouter eine statische Route erstellen (Subnetz 10.8.0.0/24 via LAN-IP des Windows-VPN-Servers)

oder

• im Windows-VPN-Server NAT einrichten damit Traffic, der aus dem VPN kommt die LAN-IP des Servers als AbsendeIP bekommt

Die statische Route setzt einen Router voraus, der das überhaupt bietet. NAT unter Windows wiederum ist ein Krampf, weil Windows für Router-Zwecke nur seeeeeeehr bedingt geeignet ist (von Microsoft so gewollt). Ich gebe explizit keine Anleitung für den NAT-Teil unter Windows, weil ich sowas zwei Mal eingerichtet habe und das echt fies war und nicht wirklich zuverlässig lief (das zweite Mal Einrichten kam dadurch, dass Windows nach Tagen plötzlich nicht mehr wollte und ich 1:1 dasselbe nochmal eingerichtet habe (Batchdatei)).

Man kann das unter Windows einrichten, aber ich rate stets dazu, dies mit Linux zu realisieren, zB in einer kleinen VM.

Ergänzung (11. Juni 2019)

Im übrigen ist in der client.ovpn auch die oben erwähnte Option "redirect-gateway" deaktiviert und somit kommt der Client gar nicht erst auf die Idee, den Internet-Traffic zum VPN-Server zu schicken. Wenn du Configs mit eingebetteten Zertifikaten postest, lösche die bitte unbedingt raus. Maskieren löst maximal das Sicherheitsproblem, aber die Files bleiben extrem unübersichtlich mit dem unnützen Zertifikatsschrott drin.

Nochmal zum NAT unter Windows : Das kann auch über die Internetverbindungsfreigabe funktionieren. Hab mich damit nie so richtig beschäftigt, aber da sollte dann automatisch NAT mit dabei sein. Eine Krücke bleibt es aber, weil Windows vom Microsoft explizit nicht als (VPN/Netzwerk)Router gedacht ist. Selbst Windows Server hat nur rudimentäre Routingfunktionen.

 

[Fabian_otto]

Vielen Dank für die ausführliche Hilfe. Dann wird es wohl ein Pi mit PiVPN werden. Ist ein Pi B 3+ von der Leistung her empfehlenswert?

 

[Raijin]

Das kommt auf deine Anforderungen an. OpenVPN ist sehr CPU-lastig, weil es nur auf einem Kern läuft. Das heißt, dass man eine relativ potente CPU benötigt, um mit OpenVPN Übertragungsraten jenseits der 20-30 Mbit/s erreichen möchte. Wenn das ausreicht, kannst du zu einem PI greifen. Anleitungen gibt es dazu Hunderte im Netz.

Reicht das nicht aus, musst du entweder auf potentere Hardware ausweichen oder wireguard ausprobieren. Das ist eine andere VPN-Technologie, die aus einem PI mehr rausholen kann als OpenVPN.