9
Windows-OpenVPN-Server kein Zugriff auf mein Heimnetz
meine OPEN-VPN-Konfiguration:
Win10-Laptop(1) ---- Wifi-Hotspot(2) ---- Internet --- Connectbox(3) ---
Connectbox(3)-----Win10-PC(4) oder Vbox-Ubuntu-OpenVPN-Server(4a)
Connectbox(3)-----NAS(6)
Connectbox(3)-----andere Geräte im Heimnetz(7)
Ich möchte von extern mit Laptop/Handy auf mein Heim-Netzwerk z.B. NAS(6) per VPN zugreifen.
Dazu habe ich bei (1) einen Open-VPN Client unter Win10
und bei (4) einen OPEN-VPN-Server unter Win10 mit entsprechen Zertifikaten eingerichtet.
Der Verbindungsaufbau mit dem OpenVPN Client klappt auch, der Tunnel steht.
Trotzdem habe ich danach keinen Zugriff auf die Geräte im Heimnetz (z.B. NAS).
Was habe ich bisher gemacht:
- OpenVPN-Server 2.4.8 eingerichtet mit LAN- (192.168.0.105) und virtuellen TUN-Adapter (10.8.0.1)
- Heimnetzwerk (per DHCP): 192.168.0.xxx, VPN-Server: 10.8.0.1 , VPN-Client: 10.8.0.2
- Windows-Firewall für LAN-Adapter und virtuellen TAP OpenVPN-Adapter deaktiviert (privates Netz)
- DynDNS Adresse angelegt für die Unitymedia Connectbox(3) für einen permanenten Zugriff.
- OpenVPN-Port forwarding auf PC(4) in der Connectbox(3) eingerichtet.
- IP-Forwarding auf dem OpenVPN Server(4) per Registry aktiviert (kontrolliert mit ipconfig -all)
- OVPN-Server Config: <push "route 192.168.0.0 255.255.255.0">
damit sollten die VPN-Clients doch dann Zugriff auf Rechner in meinem LAN bekommen.
Ein Ping 10.8.0.2 (VPN-Client) auf 10.8.0.1 (VPN-Server) oder 192.168.0.105 (VPN-Server-LAN) geht.
Wireshark zeigt: ein Ping auf ein Heimnetz-Gerät (7) (192.168.0.78) kommt dort an,
aber scheinbar kann der Ping nicht zum VPN-Client zurückgeschickt werden.
Weitere Nachforschungen im Web führen auf folgende Lösung:
es würde eine statische Route (SR) im DSL-Router fehlen:
z.B. 10.8.0.0 255.255.255.0 über 192.168.0.105 (das ist die LAN-IP des OpenVPN-Servers)
Diese Lösung geht bei mir nicht, da ich auf der Unitymedia Connectbox (echtes IPV4)
keine statischen Routen eintragen kann !!
In meiner Not habe ich den OPEN-VPN Server bei (4) durch einen VirtualBox Ubuntu-OPEN-VPN Server(4a)
auf dem Win10-PC (4) ersetzt ….. und siehe da: das Ganze funktioniert !! (auch ohne statische Route SR)
Aber eigentlich wollte ich ja die OPEN-VPN-Konfiguration mit dem Win10-PC alleine realisieren;
da mein Win10-PC (4) etwas zu schwach für eine zusätzliche Virtualbox-VM ist.
Die IPv4-Routentabelle auf dem Windows OPEN_VPN-Client (1)
sind bei beiden Varianten1 (Server=Ubuntu) und Varianten2 (Server=Win10) identisch.
IPv4-Routentabelle auf dem Ubuntu OPEN_VPN-Server (4)
route -Vn
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 enp0s3
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3
192.168.0.1 0.0.0.0 255.255.255.255 UH 100 0 0 enp0s3
IPv4-Routentabelle auf dem Windows OPEN_VPN-Server (4)
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.105 25
10.8.0.0 255.255.255.0 Auf Verbindung 10.8.0.1 281
10.8.0.1 255.255.255.255 Auf Verbindung 10.8.0.1 281
10.8.0.255 255.255.255.255 Auf Verbindung 10.8.0.1 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.105 281
192.168.0.105 255.255.255.255 Auf Verbindung 192.168.0.105 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.105 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.8.0.1 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.105 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.8.0.1 281
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.105 281
Ständige Routen: Keine
OPEN-VPN-Konfiguration-Client:
client
remote xxx.yyyy.zzz 1199
proto udp4
dev tun
ca ca.crt
cert client.crt
key client.key
resolv-retry infinite
nobind
pull
persist-key
persist-tun
remote-cert-tls server
keepalive 10 120
auth SHA512
cipher AES-256-CBC
comp-lzo
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
OPEN-VPN-Konfiguration-Server:
server 10.8.0.0 255.255.255.0
port 1199
proto udp4
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
auth SHA512
topology subnet
ifconfig-pool-persist ipp.txt
push "route-gateway 10.8.0.1"
push "route 192.168.0.0 255.255.255.0"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
explicit-exit-notify 1
verb 3
Weis jemand, warum ich bei der Windows Open-VPN-Konfiguration nicht ins Heimnetz komme?
Warum funktioniert die Windows-Variante nicht ….aber die Ubuntu-Variante so problemlos?
Win10-Laptop(1) ---- Wifi-Hotspot(2) ---- Internet --- Connectbox(3) ---
Connectbox(3)-----Win10-PC(4) oder Vbox-Ubuntu-OpenVPN-Server(4a)
Connectbox(3)-----NAS(6)
Connectbox(3)-----andere Geräte im Heimnetz(7)
Ich möchte von extern mit Laptop/Handy auf mein Heim-Netzwerk z.B. NAS(6) per VPN zugreifen.
Dazu habe ich bei (1) einen Open-VPN Client unter Win10
und bei (4) einen OPEN-VPN-Server unter Win10 mit entsprechen Zertifikaten eingerichtet.
Der Verbindungsaufbau mit dem OpenVPN Client klappt auch, der Tunnel steht.
Trotzdem habe ich danach keinen Zugriff auf die Geräte im Heimnetz (z.B. NAS).
Was habe ich bisher gemacht:
- OpenVPN-Server 2.4.8 eingerichtet mit LAN- (192.168.0.105) und virtuellen TUN-Adapter (10.8.0.1)
- Heimnetzwerk (per DHCP): 192.168.0.xxx, VPN-Server: 10.8.0.1 , VPN-Client: 10.8.0.2
- Windows-Firewall für LAN-Adapter und virtuellen TAP OpenVPN-Adapter deaktiviert (privates Netz)
- DynDNS Adresse angelegt für die Unitymedia Connectbox(3) für einen permanenten Zugriff.
- OpenVPN-Port forwarding auf PC(4) in der Connectbox(3) eingerichtet.
- IP-Forwarding auf dem OpenVPN Server(4) per Registry aktiviert (kontrolliert mit ipconfig -all)
- OVPN-Server Config: <push "route 192.168.0.0 255.255.255.0">
damit sollten die VPN-Clients doch dann Zugriff auf Rechner in meinem LAN bekommen.
Ein Ping 10.8.0.2 (VPN-Client) auf 10.8.0.1 (VPN-Server) oder 192.168.0.105 (VPN-Server-LAN) geht.
Wireshark zeigt: ein Ping auf ein Heimnetz-Gerät (7) (192.168.0.78) kommt dort an,
aber scheinbar kann der Ping nicht zum VPN-Client zurückgeschickt werden.
Weitere Nachforschungen im Web führen auf folgende Lösung:
es würde eine statische Route (SR) im DSL-Router fehlen:
z.B. 10.8.0.0 255.255.255.0 über 192.168.0.105 (das ist die LAN-IP des OpenVPN-Servers)
Diese Lösung geht bei mir nicht, da ich auf der Unitymedia Connectbox (echtes IPV4)
keine statischen Routen eintragen kann !!
In meiner Not habe ich den OPEN-VPN Server bei (4) durch einen VirtualBox Ubuntu-OPEN-VPN Server(4a)
auf dem Win10-PC (4) ersetzt ….. und siehe da: das Ganze funktioniert !! (auch ohne statische Route SR)
Aber eigentlich wollte ich ja die OPEN-VPN-Konfiguration mit dem Win10-PC alleine realisieren;
da mein Win10-PC (4) etwas zu schwach für eine zusätzliche Virtualbox-VM ist.
Die IPv4-Routentabelle auf dem Windows OPEN_VPN-Client (1)
sind bei beiden Varianten1 (Server=Ubuntu) und Varianten2 (Server=Win10) identisch.
IPv4-Routentabelle auf dem Ubuntu OPEN_VPN-Server (4)
route -Vn
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 enp0s3
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3
192.168.0.1 0.0.0.0 255.255.255.255 UH 100 0 0 enp0s3
IPv4-Routentabelle auf dem Windows OPEN_VPN-Server (4)
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.105 25
10.8.0.0 255.255.255.0 Auf Verbindung 10.8.0.1 281
10.8.0.1 255.255.255.255 Auf Verbindung 10.8.0.1 281
10.8.0.255 255.255.255.255 Auf Verbindung 10.8.0.1 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.105 281
192.168.0.105 255.255.255.255 Auf Verbindung 192.168.0.105 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.105 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.8.0.1 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.105 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.8.0.1 281
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.105 281
Ständige Routen: Keine
OPEN-VPN-Konfiguration-Client:
client
remote xxx.yyyy.zzz 1199
proto udp4
dev tun
ca ca.crt
cert client.crt
key client.key
resolv-retry infinite
nobind
pull
persist-key
persist-tun
remote-cert-tls server
keepalive 10 120
auth SHA512
cipher AES-256-CBC
comp-lzo
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
OPEN-VPN-Konfiguration-Server:
server 10.8.0.0 255.255.255.0
port 1199
proto udp4
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
auth SHA512
topology subnet
ifconfig-pool-persist ipp.txt
push "route-gateway 10.8.0.1"
push "route 192.168.0.0 255.255.255.0"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
explicit-exit-notify 1
verb 3
Weis jemand, warum ich bei der Windows Open-VPN-Konfiguration nicht ins Heimnetz komme?
Warum funktioniert die Windows-Variante nicht ….aber die Ubuntu-Variante so problemlos?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 548595
Url: https://administrator.de/contentid/548595
Printed on: April 26, 2024 at 12:04 o'clock
9 Comments
Latest comment
Hi it-wurm,
den OpenVPN-Server auf einem Windows10 PC zu terminieren, ist meines Erachtens nach, nicht gerade eine gute Idee, wenn es andere Möglichkeiten gibt. Abgesehen davon, das Routing eines Windows-Desktops nicht gerade seine Stärken sind, sollte er ja dann auch noch ständig in Betrieb sein.
Hierzu ist eigentlich ein 24/7 Gerät, welches sich im Netzwerk befindet und ein Linux-OS als Firmware aufweist, sinnvoller.
Entweder Du verwendest das NAS, so es OpenVPN-fähig ist, oder eine alternative Router-Software wie OpenWRT, falls das auf Deinen "Boxen" denn möglich ist. Ansonsten denk einfach mal auf eine "Umstrukturierung" Deines Netzes nach.
LG orcape
den OpenVPN-Server auf einem Windows10 PC zu terminieren, ist meines Erachtens nach, nicht gerade eine gute Idee, wenn es andere Möglichkeiten gibt. Abgesehen davon, das Routing eines Windows-Desktops nicht gerade seine Stärken sind, sollte er ja dann auch noch ständig in Betrieb sein.
Hierzu ist eigentlich ein 24/7 Gerät, welches sich im Netzwerk befindet und ein Linux-OS als Firmware aufweist, sinnvoller.
Entweder Du verwendest das NAS, so es OpenVPN-fähig ist, oder eine alternative Router-Software wie OpenWRT, falls das auf Deinen "Boxen" denn möglich ist. Ansonsten denk einfach mal auf eine "Umstrukturierung" Deines Netzes nach.
LG orcape
Du hast das Gros schon alles richtig gemacht. Vermutlich hast du aber die 2 wichtigsten Dinge missachtet die zwingend zu konfigurieren sind wenn du einen OVPN Server im internen lokale Netzwerk betreibst.
Dein Design dürfte vermutlich so aussehenh, richtig ??
VPN Clients von außen kommen wie du da ja unschwer sehen kannst mit einer 10.10.10.x IP Adresse als Absender Adresse. Bei dir ist es die 10.8.0.x.
Wenn du damit einen lokalen LAN Client erreichen willst klappt das ja auch durch dein richtig aktiviertes IPv4 Forwarding auf dem OVPN Server. Soweit so gut...
Der lokale LAN Client muss ja aber seine Antwortpakete wieder an die 10.8.0.x bzw. 10.10.10.x zurücksenden....klar.
Dazu sieht er in seiner Routing Tabelle nach. Da er keine dedizierte Route in diese OVPN Client IP Netze findet nimmt er sein Default Gateway und das dürfte dein lokaler Internet Router sein.
Wenn der jetzt das Paket an den VPN Client weiter routen will sieht er auch wieder in seine Routing Tabelle und dann entscheidet sich obs klappt oder nicht, je nachdem was er da findet.
Hast du die statische Route auf die lokale LAN IP des OVPN Server dort vergessen, dann sendet er es ebenfalls an seine Default Route die zum Provider zeigt und damit dann ins Nirwana, weil der RFC 1918 IP Netze nicht routet und gleich entsorgt.
Hast du dort aber richtigerweise die statische Route eingetragen wird alles klappen und der VPN Client bekommt sein Antwortpaket via routendem OVPN Server.
Fazit zu Punkt 1:
Die statische Route auf dem Internet Router ist zwingend erforderlich. Für dich sieht sie so aus:
Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.0.105
Fertisch.
Die zweite Falle die zumindest bei Winblows Rechner im lokalen LAN lauert, ist die dortige lokale Winblows Firewall.
Die blockt generell erstmal ICMP (Ping).
Zudem blockt sie generell noch alles was aus fremden IP Netzen kommt wie z.B. Traffic der aus deinem VPN Clientnetz 10.8.0.0 /24 kommt.
Hier musst du bei den lokalen Clients also die Firewall zwingend anpassen !
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Dein Design dürfte vermutlich so aussehenh, richtig ??
VPN Clients von außen kommen wie du da ja unschwer sehen kannst mit einer 10.10.10.x IP Adresse als Absender Adresse. Bei dir ist es die 10.8.0.x.
Wenn du damit einen lokalen LAN Client erreichen willst klappt das ja auch durch dein richtig aktiviertes IPv4 Forwarding auf dem OVPN Server. Soweit so gut...
Der lokale LAN Client muss ja aber seine Antwortpakete wieder an die 10.8.0.x bzw. 10.10.10.x zurücksenden....klar.
Dazu sieht er in seiner Routing Tabelle nach. Da er keine dedizierte Route in diese OVPN Client IP Netze findet nimmt er sein Default Gateway und das dürfte dein lokaler Internet Router sein.
Wenn der jetzt das Paket an den VPN Client weiter routen will sieht er auch wieder in seine Routing Tabelle und dann entscheidet sich obs klappt oder nicht, je nachdem was er da findet.
Hast du die statische Route auf die lokale LAN IP des OVPN Server dort vergessen, dann sendet er es ebenfalls an seine Default Route die zum Provider zeigt und damit dann ins Nirwana, weil der RFC 1918 IP Netze nicht routet und gleich entsorgt.
Hast du dort aber richtigerweise die statische Route eingetragen wird alles klappen und der VPN Client bekommt sein Antwortpaket via routendem OVPN Server.
Fazit zu Punkt 1:
Die statische Route auf dem Internet Router ist zwingend erforderlich. Für dich sieht sie so aus:
Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.0.105
Fertisch.
Die zweite Falle die zumindest bei Winblows Rechner im lokalen LAN lauert, ist die dortige lokale Winblows Firewall.
Die blockt generell erstmal ICMP (Ping).
Zudem blockt sie generell noch alles was aus fremden IP Netzen kommt wie z.B. Traffic der aus deinem VPN Clientnetz 10.8.0.0 /24 kommt.
Hier musst du bei den lokalen Clients also die Firewall zwingend anpassen !
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Danke orcape,
Ich habe ja schon eine funktionierende openvpn-Konfiguration mit der ubuntu-vbox (4a)
Leider ist mein win10-PC nicht sehr performant, daher versuche ich die vbox-lösung zu vermeiden.
Mein NAS ist leider nicht OpenVPN-fähig.
Gruß zurück!
Ich habe ja schon eine funktionierende openvpn-Konfiguration mit der ubuntu-vbox (4a)
Leider ist mein win10-PC nicht sehr performant, daher versuche ich die vbox-lösung zu vermeiden.
Mein NAS ist leider nicht OpenVPN-fähig.
Gruß zurück!
Danke aqui,
gutes Schaubild, das passt schon so. Frühere ähnliche Artikel von Dir habe ich schon gelesen.
Nur - wie schon gesagt - auf meinem Internet-Router von Unitymedia kann ich keine statische Route eintragen!
Die ICMP-Blockade auf meinen Windows Rechnern hatte ich schon vorher entsperrt ..., ist also kein Problem.
Generell wollte ich mit meinem Beitrag auch zeigen, dass man auf dem Internet-Router keine statische Route braucht,
wenn man mit einem LINUX-OpenVPN-Server arbeitet (was ich ja mit meiner 2. Variante bewiesen habe).
Mir will nur nicht einleuchten, warum man das nicht ähnlich mit einem Windows-Open-VPN Server hinbekommt.
Gruß zurück
gutes Schaubild, das passt schon so. Frühere ähnliche Artikel von Dir habe ich schon gelesen.
Nur - wie schon gesagt - auf meinem Internet-Router von Unitymedia kann ich keine statische Route eintragen!
Die ICMP-Blockade auf meinen Windows Rechnern hatte ich schon vorher entsperrt ..., ist also kein Problem.
Generell wollte ich mit meinem Beitrag auch zeigen, dass man auf dem Internet-Router keine statische Route braucht,
wenn man mit einem LINUX-OpenVPN-Server arbeitet (was ich ja mit meiner 2. Variante bewiesen habe).
Mir will nur nicht einleuchten, warum man das nicht ähnlich mit einem Windows-Open-VPN Server hinbekommt.
Gruß zurück
auf meinem Internet-Router von Unitymedia kann ich keine statische Route eintragen!
Dann ist das OVPN Konzept so nicht umsetzbar, das ist klar.Gibt es einen Grund warum du an diesen billigen Provider Schrottrouter gebunden bist und den nicht mit einer sinnvollen FritzBox usw. ersetzt ? Im Rahmen der freien Routerwahl ja kein Thema und sicher sinnvoll.
Du musst dann den sehr umständlichen Weg gehen auf allen Endgeräten in deinem LAN die mit dem VPN kommunizieren sollen oder müssen eine separate statische Route manuell zu konfigurieren.
Bei Winblows dann:
route add 10.8.0.0 mask 255.255.255.0 192.168.0.105 -p
Das "-p" am Ende bewirkt das diese Route permament ist und nicht nach dem nächsten Reoot verschwindet.
Wie gesagt das gilt für ALLE Endgeräte die mit dem VPN kommunizieren.
Generell wollte ich mit meinem Beitrag auch zeigen, dass man auf dem Internet-Router keine statische Route braucht,
Das ist natürlich Quatsch, denn in einem gerouteten Umfeld kommt man um diese statische Route entweder auf dem Router oder einzeln auf den Clients niemals drum rum. Hier irrst du also gewaltig.Ausnahme du machst auf dem OVPN Server ein NAT (Masquerading) ins lokale LAN, was bei dir sehr wahrscheinlich der Fall ist !
Damit sendet der Server dann alles aus dem Client VPN Netz auf seine LAN IP Adresse geNATet raus. Sprich alle Pakete haben immer eine Absender IP aus dem lokalen LAN.
Solche Konstellation ist für ein VPN generell sehr schlecht, da man sich eine Routing Einbahnsrarße erzeugt und sollte man besser immer vermeiden. Allein auch schon aus Performancegründen die das NAT/Masquerading frisst. Clients im LAN können keine Session auf VPN Clients aufmachen weil das NAT/Masquerading das verhindert.
Diese Tatsache hast du vermutlich übersehen bzw. ignoriert.
Sowas ist natürlich auch mit Winblows möglich und nennt sich "ICS". Wenn du den Server also als ICS aufsetzt macht dieser auch NAT. Siehe dazu hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Generell kann man von NAT bzw. ICS im VPN Umfeld nur dringenst abraten. Aber als Zwangs- und Schnüffelrouter Knecht mit Provider Gängelung ist das dann eben nicht so leicht weil man dann so nicht mehr frei wählen kann....
Deshalb sollte ein VPN Server ja auch immer auf der Peripherie werkeln und niemals innerhalb eines lokalen LANs. Man muss ja so auch vollkommen ungeschützen Internet Traffic in sein lokales LAN lassen...ein NoGo für jemanden dem Sicherheit etwas wert ist. Aber auch dagegen spricht bei dir dann wieder der billige Provider Schrottrouter.
Es ist sinnvoller auf lange Sicht besser deinen unseligen Schrottrouter zu entsorgen und durch etwas zu ersetzen was auch den Namen "Router" verdient !
Case closed
How can I mark a post as solved?
Aber als Zwangs- und Schnüffelrouter Knecht mit Provider Gängelung ist das dann eben nicht so leicht weil man dann so nicht mehr frei wählen kann....
Notfalls bleibt dann noch eine Routerkaskade mit einem nachgeschalteten Router. Hätte den Vorteil, das man den OpenVPN-Server dort terminieren kann.Ein einfaches Portforwarding für den OpenVPN-Port, wird doch die Unitymedia -Krücke noch hinbekommen.
Danke orcade,
Ja, ich denke schon lange darüber nach die Connectbox Krücke durch eine Kabel-Fritzbox zu ersetzen....sollte das Geld wert sein!
Viele Grüß
Ja, ich denke schon lange darüber nach die Connectbox Krücke durch eine Kabel-Fritzbox zu ersetzen....sollte das Geld wert sein!
Viele Grüß
Danke Aqui,
für Deine detaillierte technische Analyse. Da steckt doch viel fundiertes Hintergrund-Wissen drin!
mein Fazit bis heute:
an meiner gewählten Open-VPN-Konfiguration habe ich nichts grundlegend falsch gemacht,
aber die 1.Windows-Lösung funktioniert ohne zusätzliche Umbauten im meinem Netzwerk nicht!
mit der meiner 2. Lösung "Ubuntu-Open-VPN-Server" kann ich im Moment gut leben.
Damit kann ich alles machen, was ich wollte (NAS-Zugriff, RDP-Verbindungen,..) ...und auch die Performance ist ausreichend.
Längerfristig werde ich wohl irgendwann die Connectbox durch eine Kabel-Fritzbox ersetzen...versprochen!
Viele Grüße
für Deine detaillierte technische Analyse. Da steckt doch viel fundiertes Hintergrund-Wissen drin!
mein Fazit bis heute:
an meiner gewählten Open-VPN-Konfiguration habe ich nichts grundlegend falsch gemacht,
aber die 1.Windows-Lösung funktioniert ohne zusätzliche Umbauten im meinem Netzwerk nicht!
mit der meiner 2. Lösung "Ubuntu-Open-VPN-Server" kann ich im Moment gut leben.
Damit kann ich alles machen, was ich wollte (NAS-Zugriff, RDP-Verbindungen,..) ...und auch die Performance ist ausreichend.
Längerfristig werde ich wohl irgendwann die Connectbox durch eine Kabel-Fritzbox ersetzen...versprochen!
Viele Grüße
mit der meiner 2. Lösung "Ubuntu-Open-VPN-Server" kann ich im Moment gut leben.
Wenn du deine VLAN Lösung auch nur als reine "Einbahnstraße" sprich rein nur von den Clients zum lokalen LAN nutzt dann ist das auch OK.Transparent, also auch andersrum, wäre das VPN Design so weniger sinnvoll durch das erzwungene NAT am VPN Server.
Mit einer Winblows Lösung müsstest du nichts umbauen ! Wenn du den Server Port als ICS Port definierst funktioniert es doch genau so !
Aber wäre unsinnig wenn du jetzt eine laufende Lösung hast. Was sollte der Vorteil sein es mit Winblows zu machen ? Kostet mehr Geld und ist erheblich umständlicher zu konfigurieren. Warum also der Aufwand ?!
Wenn's das denn nun war bitte dann auch
How can I mark a post as solved?
nicht vergessen !