istike2
Goto Top

OpenVPN Server erlaubt keinen Zugriff auf eigenes Netz

Hallo,

ich richte jetzt die 3. Synology 2600AC Router für ein Kleinunternehmen ein. Meine bisherigen Versuche scheiterten auf den ersten Versuch immer an irgendwelche Kleinigkeit.

In dem aktuell Fall scheint alles OK zu sein, ist aber kein Zugriff möglich im selben Netz wo der Server gleichzeitig der Router ist: 10.1.1.1.
Der Router ist hinter einem UnityMedia-Modem wo LAN in Bridge Modus benutzt wird.

Da es um dasselbe Netzwerk geht habe ich kein statischen Routing eingerichtet sondern lediglich ein Firewall Rule, der den Zugriff (auch) auf 10.1.1.0 erlaubt

Die Verbindung klappt:

Mon Sep 18 23:32:04 2017 OpenVPN 2.4.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jul 14 2017
.
.
.
Mon Sep 18 23:32:09 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {7398AC97-8B48-4134-AB3E-1C9B6C179DBA} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Mon Sep 18 23:32:09 2017 Successful ARP Flush on interface [15] {7398AC97-8B48-4134-AB3E-1C9B6C179DB

Als DHCP Server ist 10.8.0.5 (DHCP Server @ VPN) auf auf dem Notebook eingestellt:

dev tun
tls-client
remote DynDNS-IP 1194
#float
  1. redirect-gateway def1
dhcp-option DNS 10.8.0.5
pullproto udp
script-security 2
comp-lzo
reneg-sec 0
auth SHA512
cipher AES-256-CBC
auth-user-pass
key-direction 1

Traffic geht durch den Tunnel.
Wenn ich auf dem Notebook 10.1.1.1 aufrufe kann ich auf die Weboberfläche zugreifen.

Wenn ich https://10.1.1.199:5002 aufrufe, klappt nicht, obwolh der VPN Server eingetlich erlaubt, dass Clients aufs Netz des Servers zugreifen ...

2017-09-18_23h52_23
Aus dem lokalen LAN kann ich es ohne Probleme erreichen.


Die Firewall erlaubt alles zu diesem Host...

firewall_k


Ich verstehe einfach nicht woran es noch scheitert...

Wenn jemand eventuell auf einen Denkfehler hinweisen könnte wäre ich dankbar.

Soll ich eventuell doch statische Routing einsetzen?
Oder sollte DHCP Server 10.1.1.1 sein?

Gr. I.

Content-Key: 349377

Url: https://administrator.de/contentid/349377

Ausgedruckt am: 29.03.2024 um 01:03 Uhr

Mitglied: em-pie
em-pie 19.09.2017 um 09:29:48 Uhr
Goto Top
Moin,

wie in sehr vielen Fällen:
Was für ein OS hängt an 10.1.1.199?
Ist es eine WIndows-Büchse: prüfe die Firewall und lass Zugriffe aus dem VPN-Netz (10.8.0.0/24?) zu...

Gruß
em-pie
Mitglied: aqui
aqui 19.09.2017 aktualisiert um 10:28:11 Uhr
Goto Top
wo der Server gleichzeitig der Router ist: 10.1.1.1.
Du meinst sicher OpenVPN Server und gleichzeitig Router ist, oder ??
Wenn ja ist das ja technisch ertsmal der Idealfall sofern dieser Router nicht noch irgendwie in einjer Router Kaskade arbeitet mit einem Router davor usw ?!
Da es um dasselbe Netzwerk geht
Route auf dem VPN Server oder wie ?? Die Beschreibung ist etwas unverständlich face-sad
Eine Firewall Regel braucht man ebenfalls nicht, die ist wie immer überflüssig wenn es der Router ist.
Wenn ich https://10.1.1.199:5002 aufrufe,
Das ist ein Endgerät im lokalen LAN, richtg ??

Du solltest wie immer strategisch vorgehen ! Wenn man es aus der etwas holprigen Beschreibung oben richtig versteht nutzt dein OpenVPN das interne IP Netz 10.8.0.0 /24, richtig ?
Hier ist es essentiell wichtig das der Prefix stimmt (Subnetzmaske) denn du nutzt im lokalen LAN auch eine 10er IP so das hier ein höhere Prefix als 16 Bit zwingend ist.
Wenn beide Subnetze eine /24 nutzen ist das OK

Wenn du mit dem Client eingewählt bist solltest du ein route print eingeben (Windows).
Anhand der Routing Tabelle kannst du genau sehen ob das 10.1.1.0er Netz in den VPN Tunnel sprich das VPN Interface geroutet wird. Dieser Output der Client Routing Tabelle wäre hier sehr hilfreich gewesen face-sad
Ebenso ein ipconfig -all um die IP Adressierung des virtuellen Tunnel Interfaces zu sehen.

Ist das alles der Fall, dann kann nur die lokale Firewall auf den Endgeräten im 10.1.1.0er Netz noch der Fallstrik sein !
VPN Clients haben eine Absender IP von 10.8.0.x damit würde die lokale Firewall alle IP Pakete dieses Clients am Ziel im 10.1.1.0er Netz blocken, denn die lässt nur Pakete mit 10.1.1.x IP Adressen durch.
Hier muss also die Firewall entsprechend customized sein das sie auch das 10.8.0.0 VPN Netz passieren lässt.
Sinnvoll ist es immer zuerst Drucker, NAS usw. im lokalen LAN zu pingen da diese in der Regel keine Firewall haben.
Klappt das aber nicht bei Geräten mit lokaler FW ist die Sache klar.

Wenn alle Stricke reissen einfach einen Wireshark an einem der lokalen Geräte im 10.1.1.0er Netz laufen lassen und erstmal checken ob dort überhaupt Pakete mit 10.8.0.x Absender IPs ankommen !
Ist das gar nicht der Fall liegt das problem noch davor.
Mitglied: istike2
istike2 28.09.2017 aktualisiert um 21:52:56 Uhr
Goto Top
Hallo Aqui,

vielen Dank für deine ausführliche Antwort.

1. Router und OpenVPN Server sind ein Gerät, angeschlossen an einem UnityMedia Kabelmodem
2. https://10.1.1.199:5002 ist das Synology NAS worauf die Kollegen bei einem Auslandsreise zugreifen möchten (als Netzwerkfreigabe)

Stand der Dinge:

- VPN Verbindung wird korrekt ufgebaut
- Traffic geht durch Tunner und wird bei Bedarf im Hostnetz Richtung öffentliches Internet geroutet
- Ich kann durch den Tunnel auf den Router zugreifen (mit 10.8.0.1)

Was nicht geht: ich erreiche keinen Host im Netz des Routers (10.1.1.0/24), obwohl die entsprechende Option auf der WebGUI aktiviert ist.

"Clients den Server-LAN Zugriff erlauben: Ja"

Hier ist die Routing-Tabelle der Firewall:

routing_tabelle

Hier sind die Firewall-Rules

firewall_route

Hier ist das Output von "Route Print"

Schnittstellenliste
8...34 e6 d7 83 8a 4c ......Intel(R) Ethernet Connection (3) I218-LM
18...60 57 18 d5 0a f3 ......Microsoft Wi-Fi Direct Virtual Adapter #2
10...00 ff 46 48 8d d7 ......TAP-NordVPN Windows Adapter V9
15...00 ff 73 98 ac 97 ......TAP-Windows Adapter V9
21...60 57 18 d5 0a f2 ......Intel(R) Dual Band Wireless-AC 7265
1...........................Software Loopback Interface 1
17...00 00 00 00 00 00 00 e0 Microsoft Teredo Tunneling Adapter
7...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
5...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #5

IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.43.1 192.168.43.136 55
10.1.1.0 255.255.255.0 10.8.0.5 10.8.0.6 291
10.8.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
192.168.43.0 255.255.255.0 Auf Verbindung 192.168.43.136 311
192.168.43.136 255.255.255.255 Auf Verbindung 192.168.43.136 311
192.168.43.255 255.255.255.255 Auf Verbindung 192.168.43.136 311
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.43.136 311
224.0.0.0 240.0.0.0 Auf Verbindung 10.8.0.6 291
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.43.136 311
255.255.255.255 255.255.255.255 Auf Verbindung 10.8.0.6 291
St„ndige Routen:
Keine

IPv6-Routentabelle
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
21 311 fe80::/64 Auf Verbindung
15 291 fe80::/64 Auf Verbindung
21 311 fe80::30b5:593a:b65c:efb3/128
Auf Verbindung
15 291 fe80::d41a:f18a:8f09:1c61/128
Auf Verbindung
1 331 ff00::/8 Auf Verbindung
21 311 ff00::/8 Auf Verbindung
15 291 ff00::/8 Auf Verbindung
St„ndige Routen:
Keine

Hier ist der Output von ipconfig / all

Ethernet-Adapter Ethernet 4:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : TAP-Windows Adapter V9
Physische Adresse . . . . . . . . : 00-FF-73-98-AC-97
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::d41a:f18a:8f09:1c61%15(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 10.8.0.6(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.252
Lease erhalten. . . . . . . . . . : Donnerstag, 28. September 2017 21:18:57
Lease l„uft ab. . . . . . . . . . : Freitag, 28. September 2018 21:18:58
Standardgateway . . . . . . . . . :
DHCP-Server . . . . . . . . . . . : 10.8.0.5
DHCPv6-IAID . . . . . . . . . . . : 151060339
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1F-90-D0-C5-F8-CA-B8-48-69-22
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS ber TCP/IP . . . . . . . : Aktiviert
Mitglied: aqui
aqui 29.09.2017 aktualisiert um 08:54:47 Uhr
Goto Top
ich erreiche keinen Host im Netz des Routers (10.1.1.0/24)
Das liegt dann an der lokalen Firewall dieser Geräte sofern vorhanden. Die würden ja nur Zugriff aus dem lokalen 10.1.1.0er Netz zulassen und alles von fremden Netzen blockieren.
Da du ja als Absender IP Adresse im VPN immer eine des internen OpenVPN Netzes hast bist du damit fremd und bleibst an den internen, lokalen Firewall hängen.
Wenn das NAS allerdings keine aktive Firewall hat dann sollte das natürlich klappen. Auch auf Geräte wie Drucker usw. die keine lokale Firewall haben.
Zwingende Voraussetzung ist natürlich das diese Geräte ihr Default Gateway auf den OpenVPN Router eingestellt haben.

Bei deinen Firewall Regeln ist auffällig das du nur Traffic von 10.8.0.0 auf die 10.1.1.0 zulässt aber nicht andersrum. Sofern die FW das auch noch kontrolliert hast du natürlich ein Problem mit den Rückpaketen.
Wenn du schreibst du kannst auf den Router zugreifen, nutzt du dann seine Tunnel IP im 10.8.0er Netz oder die lokale LAN IP im 10.1.1er Netz ?

Du solltest mal einen Test machen ob VPN Pakete überhaupt an einem Host im lokalen LAN ankommen oder nicht. Das zeigt dir dann wasserdicht ob der Router und seine Firewall das Problem sind.
Das ist ganz einfach...
Installiere dir dazu einen Testrechner im LAN oder nimm einen vorhandenen mit einer 10.1.1.er IP Adresse und starte auf diesem Rechner einen Wireshark.
Dann pingst du von einem aktiven VPN Rechner der einen Tunnel aufgebaut hat diese IP des Testrechners und checkst im Wireshark ob du dort eingehende ICMP Echo Request Pakete sehen kannst mit den entsprechenden Quell- und Ziel IP Adressen.
Ist das der Fall weisst du das der OVPN Router alles richtig macht und das Problem an den lokalen Firewalls liegt.
Kommen diese Pakete gar nicht erst an, dann liegt das Problem am Router bzw. dessen Firewall das die nicht richtig konfiguriert sind.
Was am Router ein bischen auffällig ist, ist die Tatsache das der das 10er Netz 10.0.0.0 als VPN tituliert mit einem 24er Prefix obwohl es dieses Netz gar nicht gibt.
Das nährt den Verdacht das der Router nicht wirklich mit Subnetting umgehen kann.
Um das sicher auszuschliessen solltest du dem internen VPN Netz mal KEIN Subnetz aus dem 10er Bereich geben sondern ein dediziertes eigenens Netz.
Nimm am besten sowas wie 172.32.1.0 /24 oder sowas um auch da ggf. einen Firmware Bug mal sicher ausschliessen zu können.