bugzzz
Goto Top

OpenVPN Client kann Namen nicht auflösen

Hallo,

hatte nun meinen Router ASUS AC86U geupdatet, womit mein OpenVPN Server zurückgesetzt wurde.

Habe die letzte Config eingespielt, sodass sich die Clients wieder verbinden können und können sowohl alle IP's im lokalen Netz sowie im VPN als auch im Internet gepingt werden. Allerdings können keine Namen aufgelöst werden und es können auch die Webinterfaces von Router und NAS nicht erreicht werden. Im Wireshark gehen viele 10000 DNS anfragen durch, werden aber mit "Standard query response: Refused..." beantwortet.

Sieht für mich so aus als ob die Clients keinen DNS zugewiesen bekommen oder ihn nicht erreichen. Eventuell ein Problem mit TCP/UDP?

Vielen Dank für eure Unterstützung

Content-ID: 600823

Url: https://administrator.de/forum/openvpn-client-kann-namen-nicht-aufloesen-600823.html

Ausgedruckt am: 22.12.2024 um 08:12 Uhr

117471
117471 31.08.2020 um 06:29:06 Uhr
Goto Top
Hallo,

„Refused“ heißt „verweigert“.

Bei mir wird gleich unter dem ersten Google-Treffer eine Lösung präsentiert. Hast Du die schon getestet?

Gruß,
Jörg
Dr.Bit
Dr.Bit 31.08.2020 um 08:25:36 Uhr
Goto Top
Zitat von @bugzzz:

Hallo,

hatte nun meinen Router ASUS AC86U geupdatet, womit mein OpenVPN Server zurückgesetzt wurde.

Habe die letzte Config eingespielt, sodass sich die Clients wieder verbinden können und können sowohl alle IP's im lokalen Netz sowie im VPN als auch im Internet gepingt werden. Allerdings können keine Namen aufgelöst werden und es können auch die Webinterfaces von Router und NAS nicht erreicht werden. Im Wireshark gehen viele 10000 DNS anfragen durch, werden aber mit "Standard query response: Refused..." beantwortet.

Sieht für mich so aus als ob die Clients keinen DNS zugewiesen bekommen oder ihn nicht erreichen. Eventuell ein Problem mit TCP/UDP?

Vielen Dank für eure Unterstützung

Was sagt denn ein ipconfig /all? Welche Namen werden nicht aufgelöst? Alle oder nur die hinter dem Tunnel?

🖖
aqui
aqui 31.08.2020 aktualisiert um 08:28:20 Uhr
Goto Top
nslookup wäre sinnvoller zum Test bei aktivem VPN Client.
So oder so ist es aber ohne OpenVPN Server Konfig Datei fast unmöglich eine zielführende Antwort zu geben.
Merkzettel: VPN Installation mit OpenVPN
Leider hat der TO es nicht geschafft diese wichtige Konfig hier zu posten. Da bleibt uns dann auch nur die Kristallkugel. face-sad
Dr.Bit
Dr.Bit 31.08.2020 aktualisiert um 08:55:28 Uhr
Goto Top
Zitat von @aqui:

Da bleibt uns dann auch nur die Kristallkugel. face-sad


Und was ist daran neu?

🖖
117471
117471 31.08.2020 um 12:00:38 Uhr
Goto Top
Hallo,

nö, der DNS auf dem ASUS rejected ja.

Sprich: Er kann keine DNS via WAN für Auflösungen außerhalb seiner eigenen Domain erreichen face-smile

Gruß,
Jörg
Dr.Bit
Dr.Bit 31.08.2020 um 12:33:55 Uhr
Goto Top
Zitat von @117471:

Hallo,

nö, der DNS auf dem ASUS rejected ja.

Sprich: Er kann keine DNS via WAN für Auflösungen außerhalb seiner eigenen Domain erreichen face-smile

Gruß,
Jörg
Nicht richtig. Er kann auch kein DNS innerhalb der Domain, da ja die Webinterfaces von NAS und Router auch nicht erreichbar sind. Hört sich für mich so an, als wenn da ein DHCP IPv6 Server auf dem Router läuft und die Namensauflösung durcheinanderschmeißt. Habe ich gerade erst leztzte Woche mit einer Fritte gehabt.
Fritzbox als Router rein -> nix geht mehr, Fritzbox raus -> alles geht, IPv6 DHCP Server auf der Fritzbox abgeschaltet und Fritte wieder reingehängt -> alles geht.

🖖
117471
117471 31.08.2020 um 14:50:31 Uhr
Goto Top
Hallo,

doch richtig. Wenn er den Uplink DNS nicht erreicht ist, reißt der mit genau diesem Fehler die Hufe. Vergleiche sämtliche einschlägigen Erfahrungen face-wink

Ergo: Entweder DNS per DHCP betanken oder manuell, dafür aber vollständig konfigurieren.

Gruß,
Jörg
Dr.Bit
Dr.Bit 31.08.2020 um 14:57:07 Uhr
Goto Top
Nee, den DNS auf dem ASUS darf er von einem Client aus gar nicht per default ansprechen. Da sollte nur der DC drinstehen, so der denn den DNS Server macht. Und wenn der keine Antwort bekommt, sollte der DC dem Client antworten und nicht der ASUS. Zumindest lese ich das so als wenn der ASUS antwortet. Daher ja der Verdacht auf IPv6. Wenn er nämlich den Router upgedatet hat, kann ich mir gut vorstellen, das der den integrierten IPv6 DHCP Server per default eingeschaltet.

🖖
117471
117471 31.08.2020 um 15:09:34 Uhr
Goto Top
Hallo,

weißt Du was? Du hast Recht und ich habe meine Ruhe face-smile

Gruß,
Jörg
Dr.Bit
Dr.Bit 31.08.2020 um 15:12:40 Uhr
Goto Top
Zitat von @117471:

Hallo,

weißt Du was? Du hast Recht und ich habe meine Ruhe face-smile

Gruß,
Jörg
😛 face-smile

🖖
bugzzz
bugzzz 31.08.2020 aktualisiert um 21:55:44 Uhr
Goto Top
So, hier die Configs entschuldigt die lange Wartezeit face-smile

server.conf
daemon ovpn-server1
topology subnet
server 172.16.4.0 255.255.255.0
proto udp
port 1194
dev tun21
txqueuelen 1000
ncp-ciphers AES-128-GCM:AES-128-CBC:AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC
cipher AES-128-CBC
auth SHA256
compress lz4-v2
keepalive 15 60
verb 6
client-config-dir ccd
client-to-client
push "redirect-gateway def1"  
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
verify-client-cert none
username-as-common-name
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up 'ovpn-up 1 server'  
down 'ovpn-down 1 server'  
status-version 2
status status 5

# Custom Configuration
client-config-dir /jffs/scripts/ccd
topology "subnet"  
push "topology subnet"  

#push "dhcp-option DNS 185.95.218.42" 
#push "dhcp-option DNS 185.95.218.43" 


client.conf
client
dev tun
proto udp
remote my.ddns.net 1194
resolv-retry infinite
nobind
float
ncp-ciphers AES-128-GCM:AES-128-CBC:AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC
cipher AES-128-CBC
auth SHA256
compress lz4-v2
keepalive 15 60
auth-user-pass
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----
MIIETzCCAzegAwIBAgIUNbb0fcvcUknYuR8+qOhbtZcaA8IwDQYJKoZIhvcNAQEF
BQAwcDELMAkUVzELMAkGA1UECBMCVFcxDzANBgNVBAcTBlRhaXBl
aTENMAsGA1UEChMEQVNVUzERMA8GA1UEAxMIUlQtQUM4NlUxITAfBgkqhkiG9w0B
CQEWEm1lQG15aG9zhOLH60i4CG
//w+
-----END CERTIFICATE-----
</ca>

Ich erreiche vom Client nichts, kann nur pingen.

Aktuell bekommen die Clients eigentlich den DNS per DHCP, hier setze ich den ASUS als DNS und den CCC DNS (204.152.184.76) bzw. den von Digitale Gesellschaft CH (185.95.218.42).

Mit einem nslookup krieg ich einen Timeout.
117471
117471 31.08.2020 um 21:54:34 Uhr
Goto Top
Hallo,

O.K.; auch wenn ich mich aufgrund zunehmender Schwurbelei (siehe oben) aus diesem Thema heraushalten wollte, ein letzer Versuch face-smile

Es ist, wie ich bereits geschrieben habe: Der DNS auf dem ASUS *muss* laufen. Der funktioniert nur, wenn der ASUS selber via WAN einen DNS kennt und erreichen kann, an die er Anfragen für fremde Domains weiterleiten kann. Das kann z.B. ein Domaincontroller, dein Router oder sonstwas sein.

Mit anderen Worten: Solange der ASUS niemanden hat, der seine DNS-Anfragen beantwortet, wird sein interner DNS-Server nicht funktionieren.

Sobald der DNS auf dem ASUS läuft, pusht Du diesen in der OpenVPN-Konfiguration vom Server zu den Clients.

Bitte vermeide, einen anderen DNS als den ASUS durch den Tunnel zu pushen. Zum Einen fehlt Dir dann die DNS-Domain vom ASUS "an sich", zum Anderen ist das sicherheitstechnisch ausgesprochen fragwürdig und auch nicht besonders "zukunftssicher". Sprich: Es fliegt Dir beim nächsten Update um die Ohren. Der ASUS sitzt immer als eine Art "Proxy" dazwischen.

Gruß,
Jörg
bugzzz
bugzzz 31.08.2020 aktualisiert um 22:14:06 Uhr
Goto Top
Komisch, aber wenn ich über WLAN auf dem ASUS bin dann bekomme ich auch einen funktionierenden DNS zugewiesen?! Dürft dann auch nicht funktionieren oder?

Den push von DNS Servern habe ich mal probiert, um zu schauen ob der Client dann die Anfragen durchkriegt aber geht einfacht nicht.

ifconfig
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 172.16.4.3 netmask 255.255.255.0 destination 172.16.4.3
inet6 fe80::f756:7d9d:a349:4af2 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 8134 bytes 5711679 (5.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6426 bytes 476481 (476.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.111.197.237 netmask 255.255.255.252 broadcast 10.111.197.239
ether 02:1e:10:1f:00:00 txqueuelen 1000 (Ethernet)
RX packets 96567 bytes 109086714 (109.0 MB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 48829 bytes 5031825 (5.0 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
117471
117471 31.08.2020 um 22:17:01 Uhr
Goto Top
Hallo,

wenn Du via WLAN mit dem Router verbunden bist, bekommen deine Clients den DNS von deinem DHCP-Server zugewiesen.

Wenn Du via OpenVPN verbunden bist, behalten die OpenVPN-Clients grundsätzlich erst einmal den DNS-Server in dem Netz, in dem sie sich befinden. Es sei denn, Du pusht einen DNS-Server durch die OpenVPN-Serverkonfiguration. Siehe oben.

Was sollte daran "komisch" sein?

Welchen DNS welches Gerät wann und wofür benutzt, kannst Du übrigens mit nslookup überprüfen. Letztendlich siehst Du ja, von wo aus die Antworten kommen bzw. ausbleiben.

Hilfreich ist auch "ipconfig /all" - das zeigt Dir ebenfalls an, welche DNS-Server konfiguriert sind.

Gruß,
Jörg

Übrigens: Wenn Du den DNS von der digitalen Gesellschaft direkt pusht, müsste es bei externen Domains tatsächlich funktionieren; allerdings fehlt Dir dann dein natürlich gesamtes lokales Geraffel (NAS usw.).
bugzzz
bugzzz 31.08.2020 aktualisiert um 22:58:51 Uhr
Goto Top
Also mit nslookup bekomme ich für lokale wie auch externe Adressen ein Timeout.

Habe nun die IP vom Router gepusht als DNS, aber hat nichts gebracht und ich erreiche auch mit dem öffentlichen DNS, wenn gepusht ist, nichts.

Es sieht so aus, als ob er nicht mal mit dem Push den DNS mitbekommt. Die Routen sehen glaub recht vernünftig aus, zumindest funktioniert auch der Ping überall hin. Vermute irgendwie die Config von dem ASUS WRT hat es irgendwie zerhauen...

ipconfig /all -> nmcli dev showt
GENERAL.DEVICE:                         ttyUSB0
GENERAL.TYPE:                           gsm
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     O2 o2 MMS
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/137
IP4.ADDRESS[1]:                         10.213.197.237/30
IP4.GATEWAY:                            10.213.197.238
IP4.ROUTE[1]:                           dst = 10.213.197.236/30, nh = 0.0.0.0, mt = 700
IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = 10.213.197.238, mt = 20700
IP4.DNS[1]:                             62.109.121.17
IP4.DNS[2]:                             62.109.121.18
IP6.GATEWAY:                            --

GENERAL.DEVICE:                         tun0
GENERAL.TYPE:                           tun
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     tun0
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/138
IP4.ADDRESS[1]:                         172.16.4.3/24
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 172.16.4.0/24, nh = 0.0.0.0, mt = 0
IP4.ROUTE[2]:                           dst = 0.0.0.0/1, nh = 172.16.4.1, mt = 0
IP4.ROUTE[3]:                           dst = 128.0.0.0/1, nh = 172.16.4.1, mt = 0
IP6.ADDRESS[1]:                         fe80::dea2:7704:467a:4b49/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE[2]:                           dst = fe80::/64, nh = ::, mt = 256

GENERAL.DEVICE:                         eth0
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         C8:5B:76:9E:D2:66
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               off

GENERAL.DEVICE:                         wlan0
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         F0:D5:BF:A0:D2:2D
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --

GENERAL.DEVICE:                         lo
GENERAL.TYPE:                           loopback
GENERAL.HWADDR:                         00:00:00:00:00:00
GENERAL.MTU:                            65536
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         127.0.0.1/8
IP4.GATEWAY:                            --
IP6.ADDRESS[1]:                         ::1/128
IP6.GATEWAY:                            --
lines 24-68/68 (END)
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 172.18.0.0/16, nh = 0.0.0.0, mt = 0
IP4.ROUTE[2]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP6.GATEWAY:                            --

GENERAL.DEVICE:                         wlan0
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         F0:D5:BF:A0:D2:2D
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --

GENERAL.DEVICE:                         lo
GENERAL.TYPE:                           loopback
GENERAL.HWADDR:                         00:00:00:00:00:00
GENERAL.MTU:                            65536
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         127.0.0.1/8
IP4.GATEWAY:                            --
IP6.ADDRESS[1]:                         ::1/128
IP6.GATEWAY:                            --

/etc/resolv.conf
nameserver 127.0.0.53
options edns0

netstat -rn
0.0.0.0         172.16.4.1      128.0.0.0       UG        0 0          0 tun0
0.0.0.0         10.213.197.238  0.0.0.0         UG        0 0          0 wwan0
10.213.197.236  0.0.0.0         255.255.255.252 U         0 0          0 wwan0
79.244.118.13   10.213.197.238  255.255.255.255 UGH       0 0          0 wwan0
128.0.0.0       172.16.4.1      128.0.0.0       UG        0 0          0 tun0
172.16.4.0      0.0.0.0         255.255.255.0   U         0 0          0 tun0
117471
117471 01.09.2020 um 07:15:08 Uhr
Goto Top
Hallo,,

warum versteifst Du dich so sehr auf das OpenVPN?

Das DNS auf dem Router läuft offenbar immer noch nicht.

Solange der Router nicht sauber im Netzwerk angebunden ist, kannst Du dir das Gebastel am OpenVPN sparen.

Richte den Router so ein, dass der Router den DNS fragt der dein NAS kennt. Das ist der elementare erste Schritt.

BTW: Bist Du wirklich Festnetzkunde bei O2?

Gruß,
Jörg
Dr.Bit
Dr.Bit 01.09.2020, aktualisiert am 02.09.2020 um 08:30:30 Uhr
Goto Top
Zitat von @117471:

Hallo,

O.K.; auch wenn ich mich aufgrund zunehmender Schwurbelei (siehe oben) aus diesem Thema heraushalten wollte, ein letzer Versuch face-smile

Jaja, face-smile Mir war nicht klar, das der ASUS der einzige DNS ist, ging für mich bisher nicht aus den Posts hervor. Wenn dem so ist, bin ich vollkommen bei Dir.

🖖
bugzzz
bugzzz 01.09.2020 aktualisiert um 08:33:52 Uhr
Goto Top
Moin,

du sagst wenn ich einen öffentlichen DNS pushe müsste es gehen, tut es aber nicht.

Es geht nicht nur um mir mein NAS, sondern auch um öffentliche Adressen.

Also wenn ich über SSH auf den ASUS gehe, dann kann er alle Namen auflösen. Habe den DNS des Routers unter WAN und für DHCP gesetzt weitere Möglichkeiten sehe ich nicht. Außer ihn über den OpenVPN server zu pushen.

Ich kann den DNS auch pingen, aber die Namensauflösung packt er nicht.

OT: Mobilfunk. Teste das mit meinem Notebook aus dem Mobilfunknetz, verbinde mich dann über VPN ins Netz.
117471
117471 01.09.2020 aktualisiert um 17:18:31 Uhr
Goto Top
Hallo,

O.K. - wenn der ASUS in der SSH alle Namen auflösen kann, ist das eine ziemlich relevante Information, die hier schlichtweg gefehlt hat.

Vielleicht gibt es Filterregeln, die das verhindern bzw. es fehlt eine Filterregel, die das erlaubt?!? face-smile

In deiner Konfiguration steht "server 172.16.4.0 255.255.255.0" - das ist das Netz, dass OpenVPN als Transportnetz verwendet. Also ein anderes Netz als deine Geräte zu Hause und ein anderes Netz als der Standort, an dem dein Client steht. Insofern macht so ein "exotisches" Netz tatsächlich sehr viel Sinn.

Dein OpenVPN-Server bekommt in diesem Netz immer die erste IP, also die 172.16.4.1

D.h., vom Client aus solltest Du nach dem Verbindungsaufbau mit "nslookup www.administrator.de 172.16.4.1" eine Antwort bekommen. Wenn das nicht der Fall ist, dann solltest Du via SSH direkt auf dem ASUS überprüfen, ob Du da eine Namensauflösung über localhost funktioniert: "nslookup www.administrator.de 127.0.0.1"

Ist das nicht der Fall, dann liegt etwas in der Routerkonfiguration "im Argen". D.h., der DNS-Server auf dem Gerät startet aus irgend einem Grund nicht.

Funktioniert es, dann blockiert vermutlich etwas den Zugriff von den Clients auf den DNS-Server:
  • der DNS-Server hat eine ACL oder Sicherheitsfunktionen, in denen Netzte freigeschaltet werden müssen
  • es gibt eine Firewallregel, die das blockiert
  • es gibt keine Firewallregel, die das erlaubt

Die Regel an sich - muss bildlich - gesprochen "erlaube Port 53 eingehend TCP und UPD aus dem Netz 172.16.4.0/24 auf mich selber bzw. auf 172.16.4.1" lauten.

Gruß,
Jörg
bugzzz
bugzzz 01.09.2020 um 18:46:59 Uhr
Goto Top
Weiterhin Timeout, wenn ich den hier mache "nslookup www.administrator.de 172.16.4.1", aber kein Problem wenn ich über SSH den hier "nslookup www.administrator.de 127.0.0.1" ausführe.

Komischerweise, hat das Setup vor dem Update ohne eine solche Regel funktioniert.
117471
Lösung 117471 01.09.2020 aktualisiert um 19:44:57 Uhr
Goto Top
Hallo,

dann blockt irgend etwas den Zugriff aus dem OpenVPN-Netz auf den DNS-Server.

Vielleicht hat ASUS neue Sicherheitsfunktionen eingeführt oder bestehende Sicherheitsfunktionen / Filterregeln zurückgesetzt?

Gruß,
Jörg
bugzzz
bugzzz 01.09.2020 aktualisiert um 20:22:19 Uhr
Goto Top
Vermutlich, im Changelog steht was im Zusammenhang mit DNS und OpenVPN. Kann schlecht beurteilen inwiefern das Auswirkungen auf die Problematik hat.

https://www.snbforums.com/threads/release-asuswrt-merlin-384-19-is-now-a ...

Mit der Version scheinen mehrere Probleme gehabt zu haben.
bugzzz
bugzzz 01.09.2020 aktualisiert um 23:44:29 Uhr
Goto Top
Keine Ahnung wie der OpenVPN-Server seine Einstellungen vornimmt, wenn "<<LAN only | Internet only | Both>>" gewählt wird. Komischerweise habe ich nun mit LAN only Zugriff auf Internet + LAN. Vermutlich werden auch die DNS-Anfragen mit diesen Einstellungen geblockt.

Hätte mich ja bei einem eigenen OpenVPN-Server an @aqui's Guide gehalten, aber leider wird die config hier mit jeder Änderung im WebUI überschrieben.

LAN only hat nun eine Route ins private Netz gepusht und den redirect-gateway rausgenommen. Nicht so ganz durchschaubar was der Router für eine Config generiert. Wenn mich der Server nochmal soviel Nerven kostet, dann wird er gleich auf dem NAS aufgesetzt.

Nochmals danke an eure Unterstützung.
117471
117471 02.09.2020 um 11:13:57 Uhr
Goto Top
Hallo,

eigentlich solltest Du das positiv sehen - letztendlich hast Du ja eine Menge gelernt.

Z.B. systematisch nach Fehlern zu suchen und Patchnotes zu lesen face-smile

Gruß,
Jörg
bugzzz
bugzzz 02.09.2020 aktualisiert um 22:49:07 Uhr
Goto Top
Das stimmt. face-smile

Mach das hier nochmal auf und zwar, das hat gestern zwar funktioniert. Also wenn ich von extern ins VPN Netz verbinde konnte ich alles erreichen (LAN-Clients, VPN-Clients und das Internet). Problem, ich habe einen Client der sich aus dem LAN ins VPN-Netz verbindet (einfach um Datenübertragung zu encrypten) und genau dieser Client hatte nun das Problem, dass er keine Geräte mehr erreicht hat.

Habe nun eine weitere Einstellung probiert (LAN only | Internet only | Both) und so funktioniert für den internen Client alles, aber von extern habe ich nun ein anderes Problem. Verbinde ich mich von extern auf den Server, kann dieses mal ein nslookup durchführen, kann die WebInterfaces erreichen und kann über SSH auf die Maschinen, aber ich kann keine Seiten im Internet aufrufen.

Ich kann das einfach nicht nachvollziehen, was der für Einstellungen vornimmt. Ich setze mir den glaub auf meinem G8 auf.
117471
117471 03.09.2020 um 05:06:44 Uhr
Goto Top
Hallo,

der Client im LAN wird sicher ein Gateway nutzen; und das benötigt eine Route ins VPN-Netz.... face-wink

Gruß,
Jörg