13
Azure VM RDP Zugriff via openVPN absichern
Hallo liebes Forum,
testweise habe ich mit eine Azure (Win) VM eingerichtet und kann per default via RDP (TCP 3389) über die feste IP auf die VM zugreifen.
RDP-Zugriff möchte ich natürlich nicht so direkt zulassen und habe mir überlegt, ob ich einen openVPN Server direkt auf demselben
Server installieren könnte.
Ist mir klar, dass das keine saubere Lösung ist, wollte für meine Testumgebung aber keine zweite (Linux) VM mit openVPN aufsetzen,
die mir MS natürlich zusätzlich zusätzlich berechnen würde.
Ich bräuchte Eure Meinung, ob openVPN auf derselben Maschine laufen könnte und ob ich mir dadurch ein Sicherheitsleck
"einkaufen" würde.
Beste Grüße
Benson
testweise habe ich mit eine Azure (Win) VM eingerichtet und kann per default via RDP (TCP 3389) über die feste IP auf die VM zugreifen.
RDP-Zugriff möchte ich natürlich nicht so direkt zulassen und habe mir überlegt, ob ich einen openVPN Server direkt auf demselben
Server installieren könnte.
Ist mir klar, dass das keine saubere Lösung ist, wollte für meine Testumgebung aber keine zweite (Linux) VM mit openVPN aufsetzen,
die mir MS natürlich zusätzlich zusätzlich berechnen würde.
Ich bräuchte Eure Meinung, ob openVPN auf derselben Maschine laufen könnte und ob ich mir dadurch ein Sicherheitsleck
"einkaufen" würde.
Beste Grüße
Benson
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: 604209
Url: https://administrator.de/forum/azure-vm-rdp-zugriff-via-openvpn-absichern-604209.html
Ausgedruckt am: 23.12.2024 um 18:12 Uhr
13 Kommentare
Neuester Kommentar
Ja, natürlich kann es das und es ist natürlich kein Sicherheitsleck. Ganz im Gegenteil, denn RDP gilt mit seiner sehr schwachen Verschlüsselung als nicht sicher. Du tust also gut daran das abzusichern.
Aller weiteren OVPN Infos findest du HIER:
Aller weiteren OVPN Infos findest du HIER:
Vielen Dank. Mittlerweile habe ich erfolgreich openVPN mit static key eingerichtet. RDP durch den Tunnel funktioniert.
Eine Herausforderung habe ich noch. Ich möchte, dass der Server nach einem Neustart automatisch die VPN Verbindung aufbaut. Geht via —connect server.ovpn per Aufgabenplanung.
Irgendwie zieht er aber die Config nicht.
Daran bastle ich heute noch.
Gruß,
Benson
Eine Herausforderung habe ich noch. Ich möchte, dass der Server nach einem Neustart automatisch die VPN Verbindung aufbaut. Geht via —connect server.ovpn per Aufgabenplanung.
Irgendwie zieht er aber die Config nicht.
Daran bastle ich heute noch.
Gruß,
Benson
Static Key ist immer ein Vabanque Spiel mit der Sicherheit. Besser wären die OVPN üblichen Zertifikate...!
Autostart:
https://blog.joergboesche.de/openvpn-windows-autostart-mit-automatischem ...
https://www.it-management-kirchberger.at/manuals-tutorials/clients-manua ...
https://www.internet-xs.de/support/vpn-verbindung/openvpn-client-bei-sys ...
Usw. usw.
Autostart:
https://blog.joergboesche.de/openvpn-windows-autostart-mit-automatischem ...
https://www.it-management-kirchberger.at/manuals-tutorials/clients-manua ...
https://www.internet-xs.de/support/vpn-verbindung/openvpn-client-bei-sys ...
Usw. usw.
1
Das Netzwerkinterface von Windows sollte man nicht direkt ins Internet stellen. Worst practice. Egal ob da ein OpenVPN Listener läuft oder der für RDP. Wenn es denn unbedinbt sein muß über einen Reverse Proxy (und der kostet defintiv extra)
RDP von Windows 2016 ist nach ein paar Tagen über Zerodays gehackt, egal wie stark das Kennwort ist (hatte ich mal) und ich wage mal zu behaupten, daß es um die Robistheit des Windows NEtzwerkadapters auch nicht allzuweit bestellt ist.
Und warum so kompliziert wenn es auch einfach geht... Azure offeriert unter anderem Point-to-Point VPN und Point-to-Site VPN , da gibts sogar einen Konfigurator für, der einem für den Client-PC gleich ein Icon auf den Bildschirm heftet.
RDP von Windows 2016 ist nach ein paar Tagen über Zerodays gehackt, egal wie stark das Kennwort ist (hatte ich mal) und ich wage mal zu behaupten, daß es um die Robistheit des Windows NEtzwerkadapters auch nicht allzuweit bestellt ist.
Und warum so kompliziert wenn es auch einfach geht... Azure offeriert unter anderem Point-to-Point VPN und Point-to-Site VPN , da gibts sogar einen Konfigurator für, der einem für den Client-PC gleich ein Icon auf den Bildschirm heftet.
1
Auch wenn es eine Testumgebung ist, eine Sicherheitslücke wollte ich vermeiden.
Site to Site VPN bekomme ich wegen meiner AVM Fritz!Box und dyn. IP nicht hin.
Daher werde ich den Ratschlag umsetzen und eine Ubuntu VM mit openVPN (möchte gerne openVPN verwenden) installieren. Darüber werde ich den Zugriff auf die VM realisieren.
Alternativ teste ich auf der Ubuntu Maschine einen Reverse Proxy, wenn es möglich ist von außen via 443 zu kommen und dann intern via RDP auf die VM zu verbinden.
Hast Du ggf. einen Link für mich, den Du empfehlen kannst?
Danke,
Benson
Site to Site VPN bekomme ich wegen meiner AVM Fritz!Box und dyn. IP nicht hin.
Daher werde ich den Ratschlag umsetzen und eine Ubuntu VM mit openVPN (möchte gerne openVPN verwenden) installieren. Darüber werde ich den Zugriff auf die VM realisieren.
Alternativ teste ich auf der Ubuntu Maschine einen Reverse Proxy, wenn es möglich ist von außen via 443 zu kommen und dann intern via RDP auf die VM zu verbinden.
Hast Du ggf. einen Link für mich, den Du empfehlen kannst?
Danke,
Benson
ich glaub du hast da was mißverstanden, Site-to-Site würde nur mit festen IP Addressen auf deiner Seite gehen, das dürfte schon mal am Provider scheitern. Aber ist auch nicht nötig.
Ich meinte Point to Site wo dein Rechner als Client (Point) die VPN Verbinudng zu einem Endpunkt in Azure aufbaut (Site) und das wird als VPN Gatway zur Verfügung gestellt.
Bei mir hat die Point to Site Variante mit allem funktioniert, was es so an Internetzugängen gibt, nur nicht wenn ich im Homeoffice schon im Firmen-VPN eingewählt bin.
Aber OpenVPN wäre auch eine Alternative... dafür gibts im Azure sogar Vorlangen-VM s im Marketplace. Wäre aber sichereer wenn man das selber baut denn man weiß ja nie was in so einerVorlangen-VM drin ist, selbst Microsoft distanziiert sich davon.
Ich meinte Point to Site wo dein Rechner als Client (Point) die VPN Verbinudng zu einem Endpunkt in Azure aufbaut (Site) und das wird als VPN Gatway zur Verfügung gestellt.
Bei mir hat die Point to Site Variante mit allem funktioniert, was es so an Internetzugängen gibt, nur nicht wenn ich im Homeoffice schon im Firmen-VPN eingewählt bin.
Aber OpenVPN wäre auch eine Alternative... dafür gibts im Azure sogar Vorlangen-VM s im Marketplace. Wäre aber sichereer wenn man das selber baut denn man weiß ja nie was in so einerVorlangen-VM drin ist, selbst Microsoft distanziiert sich davon.
1
danke für die Hinweise! Ich bin gerade dabei, OpenVPN als VM selbst zu bauen, anhand dieses Artikels:
https://www.digitalocean.com/community/tutorials/how-to-set-up-and-confi ...
Wenn es klappt, gebe ich eine Rückmeldung.
Würde allerdings parallel auch gerne die Reverse Proxy Thematik angehen (443 Proxy nach 3389 intern).
Hab dazu noch nichts spannendes gefunden.
https://www.digitalocean.com/community/tutorials/how-to-set-up-and-confi ...
Wenn es klappt, gebe ich eine Rückmeldung.
Würde allerdings parallel auch gerne die Reverse Proxy Thematik angehen (443 Proxy nach 3389 intern).
Hab dazu noch nichts spannendes gefunden.
Site-to-Site würde nur mit festen IP Addressen auf deiner Seite gehen
Jein. DDNS würde auch klappen. Schlimmer wären DS-Lite Anschlüsse. Da gehts nicht, oder eben nur mit IPv6.OpenVPN als VM selbst zu bauen, anhand dieses Artikels:
Oder auch hier steht wie es geht:Merkzettel: VPN Installation mit OpenVPN
gerne die Reverse Proxy Thematik angehen
https://containo.us/traefik/oder Nginx Reverse Proxy.
Hallo zusammen,
kurze Rückmeldung.
Ich habe jetzt anhand der Anleitungen eine CA-VM (Ubuntu) und eine OpenVPN-VM (Ubuntu) in Azure aufgesetzt und konfiguriert.
Eine Verbindung zum RDP-Rechner vm-prod-001 (Win10Pro) sollte dann im Anschluss durch den VPN-Tunnel ermöglicht werden.
Ich bin soweit gekommen, dass ein openVPN Client die Verbindung zum OpenVPN-Server erfolgreich aufbauen kann (Hurra!).
Ein Ping zum OpenVPN-Server 10.8.0.1 geht durch.
Ich bekomme aber keine Verbindung zum RDP-Server oder auch zum CA-Server (beide ebenfalls im gleichen 10.0.0.0/24er Netz).
Route ADD 10.0.0.0 MASK 255.255.255.0 10.8.0.5 ist in der server.conf gesetzt (sieht man auch im Log).
Umgebung:
OpenVPN Server
Public IP: 123.123.123.123
Private IP: 10.0.0.5
RDP-Maschine
Private IP: 10.0.0.4
VPN-Netz: 10.8.0.0/255.255.252
Gateway: 10.8.0.1
tun0 (VPN-Adapter des OpenVPN Servers): 10.8.0.6
VPN-Client-Netz: 192.168.2.0/254
Router (AVM 7590): 192.168.2.251
Hier das Client-Log der OpenVPN-Verbindung:
Liegt es vielleicht an der Ubuntu-Firewall?
Danke für jeden Tipp in die richtige Richtung
LG
Benson
kurze Rückmeldung.
Ich habe jetzt anhand der Anleitungen eine CA-VM (Ubuntu) und eine OpenVPN-VM (Ubuntu) in Azure aufgesetzt und konfiguriert.
Eine Verbindung zum RDP-Rechner vm-prod-001 (Win10Pro) sollte dann im Anschluss durch den VPN-Tunnel ermöglicht werden.
Ich bin soweit gekommen, dass ein openVPN Client die Verbindung zum OpenVPN-Server erfolgreich aufbauen kann (Hurra!).
Ein Ping zum OpenVPN-Server 10.8.0.1 geht durch.
Ich bekomme aber keine Verbindung zum RDP-Server oder auch zum CA-Server (beide ebenfalls im gleichen 10.0.0.0/24er Netz).
Route ADD 10.0.0.0 MASK 255.255.255.0 10.8.0.5 ist in der server.conf gesetzt (sieht man auch im Log).
Umgebung:
OpenVPN Server
Public IP: 123.123.123.123
Private IP: 10.0.0.5
RDP-Maschine
Private IP: 10.0.0.4
VPN-Netz: 10.8.0.0/255.255.252
Gateway: 10.8.0.1
tun0 (VPN-Adapter des OpenVPN Servers): 10.8.0.6
VPN-Client-Netz: 192.168.2.0/254
Router (AVM 7590): 192.168.2.251
Hier das Client-Log der OpenVPN-Verbindung:
Thu Sep 17 11:47:40 2020 NOTE: --user option is not implemented on Windows
Thu Sep 17 11:47:40 2020 NOTE: --group option is not implemented on Windows
Thu Sep 17 11:47:40 2020 OpenVPN 2.4.5 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar 1 2018
Thu Sep 17 11:47:40 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Sep 17 11:47:40 2020 library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.10
Enter Management Password:
Thu Sep 17 11:47:40 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25343
Thu Sep 17 11:47:40 2020 Need hold release from management interface, waiting...
Thu Sep 17 11:47:40 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25343
Thu Sep 17 11:47:41 2020 MANAGEMENT: CMD 'state on'
Thu Sep 17 11:47:41 2020 MANAGEMENT: CMD 'log all on'
Thu Sep 17 11:47:41 2020 MANAGEMENT: CMD 'echo all on'
Thu Sep 17 11:47:41 2020 MANAGEMENT: CMD 'bytecount 5'
Thu Sep 17 11:47:41 2020 MANAGEMENT: CMD 'hold off'
Thu Sep 17 11:47:41 2020 MANAGEMENT: CMD 'hold release'
Thu Sep 17 11:47:41 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Thu Sep 17 11:47:41 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Sep 17 11:47:41 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Thu Sep 17 11:47:41 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Sep 17 11:47:41 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]123.123.123.123:1194
Thu Sep 17 11:47:41 2020 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Sep 17 11:47:41 2020 UDP link local: (not bound)
Thu Sep 17 11:47:41 2020 UDP link remote: [AF_INET]123.123.123.123:1194
Thu Sep 17 11:47:41 2020 MANAGEMENT: >STATE:1600336061,WAIT,,,,,,
Thu Sep 17 11:47:41 2020 MANAGEMENT: >STATE:1600336061,AUTH,,,,,,
Thu Sep 17 11:47:41 2020 TLS: Initial packet from [AF_INET]123.123.123.123:1194, sid=7f07355e 1e9f9ece
Thu Sep 17 11:47:41 2020 VERIFY OK: depth=1, CN=Easy-RSA CA
Thu Sep 17 11:47:41 2020 VERIFY KU OK
Thu Sep 17 11:47:41 2020 Validating certificate extended key usage
Thu Sep 17 11:47:41 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Sep 17 11:47:41 2020 VERIFY EKU OK
Thu Sep 17 11:47:41 2020 VERIFY OK: depth=0, CN=server
Thu Sep 17 11:47:41 2020 WARNING: 'keydir' is present in local config but missing in remote config, local='keydir 0'
Thu Sep 17 11:47:41 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1
Thu Sep 17 11:47:41 2020 [server] Peer Connection Initiated with [AF_INET]123.123.123.123:1194
Thu Sep 17 11:47:42 2020 MANAGEMENT: >STATE:1600336062,GET_CONFIG,,,,,,
Thu Sep 17 11:47:42 2020 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Sep 17 11:47:42 2020 PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM'
Thu Sep 17 11:47:42 2020 OPTIONS IMPORT: timers and/or timeouts modified
Thu Sep 17 11:47:42 2020 OPTIONS IMPORT: --ifconfig/up options modified
Thu Sep 17 11:47:42 2020 OPTIONS IMPORT: route options modified
Thu Sep 17 11:47:42 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Sep 17 11:47:42 2020 OPTIONS IMPORT: peer-id set
Thu Sep 17 11:47:42 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
Thu Sep 17 11:47:42 2020 OPTIONS IMPORT: data channel crypto options modified
Thu Sep 17 11:47:42 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Sep 17 11:47:42 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Sep 17 11:47:42 2020 interactive service msg_channel=692
Thu Sep 17 11:47:42 2020 ROUTE_GATEWAY 192.168.2.251/255.255.255.0 I=56 HWADDR=38:af:d7:af:96:92
Thu Sep 17 11:47:42 2020 open_tun
Thu Sep 17 11:47:42 2020 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{7B2E90FA-9CE3-4B41-BF79-9206926DB1FC}.tap
Thu Sep 17 11:47:42 2020 TAP-Windows Driver Version 9.21
Thu Sep 17 11:47:42 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {7B2E90FA-9CE3-4B41-BF79-9206926DB1FC} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Thu Sep 17 11:47:42 2020 Successful ARP Flush on interface [30] {7B2E90FA-9CE3-4B41-BF79-9206926DB1FC}
Thu Sep 17 11:47:42 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Sep 17 11:47:42 2020 MANAGEMENT: >STATE:1600336062,ASSIGN_IP,,10.8.0.6,,,,
Thu Sep 17 11:47:47 2020 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Sep 17 11:47:47 2020 MANAGEMENT: >STATE:1600336067,ADD_ROUTES,,,,,,
Thu Sep 17 11:47:47 2020 C:\WINDOWS\system32\route.exe ADD 10.0.0.0 MASK 255.255.255.0 10.8.0.5
Thu Sep 17 11:47:47 2020 Route addition via service succeeded
Thu Sep 17 11:47:47 2020 C:\WINDOWS\system32\route.exe ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5
Thu Sep 17 11:47:47 2020 Route addition via service succeeded
Thu Sep 17 11:47:47 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Sep 17 11:47:47 2020 Initialization Sequence Completed
Thu Sep 17 11:47:47 2020 MANAGEMENT: >STATE:1600336067,CONNECTED,SUCCESS,10.8.0.6,123.123.123.123,1194,,Liegt es vielleicht an der Ubuntu-Firewall?
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
# ufw-before-input
# ufw-before-output
# ufw-before-forward
#
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0 (change to the interface you discov>
-A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULESDanke für jeden Tipp in die richtige Richtung
LG
Benson
Ich habe es selbst lösen können. Meine Vermutung war wohl richtig, dass es an der Firewall liegen muss:
Kann mir das jemand erklären, warum ich das VPN-Netz maskieren muss? Ich will ja eigentlich ins 10.0.0.0/24er-Netz,
was ja jetzt auch funktioniert....
# -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMITKann mir das jemand erklären, warum ich das VPN-Netz maskieren muss? Ich will ja eigentlich ins 10.0.0.0/24er-Netz,
was ja jetzt auch funktioniert....
Kann mir das jemand erklären, warum ich das VPN-Netz maskieren muss?
Das ist auch kompletter Unsinn, denn die internen Netze NATet (IP Adress Translation) man natürlich niemals. Genau das hast du aber gemacht (Maquerading= NAT). Das geht immer mit einem massiven Performance Verlust einher bzw. kann gravierende Nachteile mit Fragmentierungen nach sich ziehen. Kein Netzwerker macht so einen Unsinn denn intern besteht logischerweise niemals Zwang zu NATen.Außerdem mit der dann aktiven NAT Firewall machst du kein transparentes Routing mehr. Dein Routing ist also eine Einbahnstraße.
Vergiss den Unsinn also.
Was du falsch gemacht hast hat 2 Gründe:
- a.) Du hast vergessen IP Forwarding zu aktivieren auf dem Server
- b.) Du hast vergessen eine statische Route auf das interne OVPN IP Netz im Router einzutragen sofern ein externer Internet Router im Spiel ist.
Merkzettel: VPN Installation mit OpenVPN
Deine aktuelle "Lösung" ist also mehr als suboptimal...auch wenn es vermeintlich rennt.
Traceroute und Wireshark sind wie immer deine besten Freunde !
1
Hallo aqui,
danke Dir für den ausführlichen Kommentar! Natrülich möchte ich, auch wenn es nur eine Testumgebung ist,
openVPN sauber einrichten.
zu a)
IP Forwarding ist auf dem openVPN Server bereits aktiv:
zu b)
Mir ist nicht klar, wo ich die feste Route eintragen soll. Der openVPN-Server ist ja m. E. auch in meinem Falle der Router (Azure).
So sieht die Route vom OpenVPN Server aus:
Und so die des Clients nach dem VPN-Aufbau:
Der Router des Clients ist eine Fritz!Box mit der IP 192.168.2.251.
Ich denke aber, dass hier keine Route eingetragen werden muss, da es ja keine Site-to-Site Kopplung ist.
VG
Benson
danke Dir für den ausführlichen Kommentar! Natrülich möchte ich, auch wenn es nur eine Testumgebung ist,
openVPN sauber einrichten.
zu a)
IP Forwarding ist auf dem openVPN Server bereits aktiv:
sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1zu b)
Mir ist nicht klar, wo ich die feste Route eintragen soll. Der openVPN-Server ist ja m. E. auch in meinem Falle der Router (Azure).
So sieht die Route vom OpenVPN Server aus:
ip route
default via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.5 metric 100
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.5
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
168.63.129.16 via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.5 metric 100
169.254.169.254 via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.5 metric 100Und so die des Clients nach dem VPN-Aufbau:
route print
===========================================================================
Schnittstellenliste
54...00 e1 04 00 06 8e ......Realtek USB GbE Family Controller
56...38 af d7 af 96 92 ......Hyper-V Virtual Ethernet Adapter #2
63...74 e5 f9 46 49 53 ......Microsoft Wi-Fi Direct Virtual Adapter
31...76 e5 f9 46 49 52 ......Microsoft Wi-Fi Direct Virtual Adapter #2
30...00 ff 7b 2e 90 fa ......TAP-Windows Adapter V9
40...74 e5 f9 46 49 56 ......Bluetooth Device (Personal Area Network)
14...74 e5 f9 46 49 52 ......Hyper-V Virtual Ethernet Adapter #3
1...........................Software Loopback Interface 1
45...84 9b 94 5c 5f 4a ......Sierra Wireless Mobile Broadband Network Adapter #22
72...00 15 5d 7f dc 63 ......Hyper-V Virtual Ethernet Adapter
===========================================================================
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.2.251 192.168.2.171 25
10.0.0.0 255.255.255.0 10.8.0.5 10.8.0.6 291
10.8.0.1 255.255.255.255 10.8.0.5 10.8.0.6 291
10.8.0.4 255.255.255.252 Auf Verbindung 10.8.0.6 291
10.8.0.6 255.255.255.255 Auf Verbindung 10.8.0.6 291
10.8.0.7 255.255.255.255 Auf Verbindung 10.8.0.6 291
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
172.17.99.128 255.255.255.240 Auf Verbindung 172.17.99.129 5256
172.17.99.129 255.255.255.255 Auf Verbindung 172.17.99.129 5256
172.17.99.143 255.255.255.255 Auf Verbindung 172.17.99.129 5256
192.168.2.0 255.255.255.0 Auf Verbindung 192.168.2.171 281
192.168.2.171 255.255.255.255 Auf Verbindung 192.168.2.171 281
192.168.2.255 255.255.255.255 Auf Verbindung 192.168.2.171 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 192.168.2.171 281
224.0.0.0 240.0.0.0 Auf Verbindung 10.8.0.6 291
224.0.0.0 240.0.0.0 Auf Verbindung 172.17.99.129 5256
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 192.168.2.171 281
255.255.255.255 255.255.255.255 Auf Verbindung 10.8.0.6 291
255.255.255.255 255.255.255.255 Auf Verbindung 172.17.99.129 5256
===========================================================================
Ständige Routen:
Keine
IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
56 281 fd00::/64 Auf Verbindung
56 281 fd00::/64 fe80::3ea6:2fff:feb2:7b18
56 281 fd00::8d4d:39de:51ce:74ab/128
Auf Verbindung
56 281 fd00::dc1f:6135:e9aa:8d9f/128
Auf Verbindung
56 281 fe80::/64 Auf Verbindung
30 291 fe80::/64 Auf Verbindung
72 5256 fe80::/64 Auf Verbindung
30 291 fe80::593b:4781:e037:625e/128
Auf Verbindung
56 281 fe80::dc1f:6135:e9aa:8d9f/128
Auf Verbindung
72 5256 fe80::e06b:776d:9227:29be/128
Auf Verbindung
1 331 ff00::/8 Auf Verbindung
56 281 ff00::/8 Auf Verbindung
30 291 ff00::/8 Auf Verbindung
72 5256 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
KeineDer Router des Clients ist eine Fritz!Box mit der IP 192.168.2.251.
Ich denke aber, dass hier keine Route eingetragen werden muss, da es ja keine Site-to-Site Kopplung ist.
VG
Benson
Mir ist nicht klar, wo ich die feste Route eintragen soll. Der openVPN-Server ist ja m. E. auch in meinem Falle der Router (Azure).
Das ist richtig ! Wenn der OVPN Server dein Tunnelendpunkt mit der öffentlichen IP ist dann ist dem auch so. Dann benötigst du dort natürlich keine extra statische Route, denn der Server "kennt" diese beiden IP Netz ja da sie direkt an ihm angeschlossen sind.Du hast es ja schon richtig gemacht und bei aktivem OVPN Client ein route print in der Eingabeaufforderung (Windows) eingegeben. Dort sollte dann jeweils ein Eintrag für das interne OpenVPN Netz vorhanden sein und auch einer für dein lokales LAN !
Beides ist bei dir der Fall, folglich werden aus beide Netze in den Tunnel geroutet
Ich denke aber, dass hier keine Route eingetragen werden muss, da es ja keine Site-to-Site Kopplung ist.
Auch das ist richtig !OVPN technisch hast du soweit alles richtig gemacht.
Es ist also stark zu vermuten, sofern ein Winblows OS als Server im Spiel ist, fast immer bei Winblows die lokale Firewall des Servers zuschlägt. Da die Windows eigene Auto Erkennung des Tunnelnetzes durch das fehlende Gateway immer fehlschlägt deklariert die lokale Firewall dieses Netz immer als "Public" und blockt somit jeglichen Zugriff. Typische Winblows Firewall Problematik.
Was du aber immer in den Firewall mit erweiterer Einstellung Optionen entsprechend auf ein Private Profil anpassen kannst mit einem Mausklick, was das Problem dann sofort löst.
Alternativ kannst du die FW auch entsprechend manuell customizen nach deinen Sicherheitsvorgaben.
Es kann final nur noch ein Firewall Problem sein !
