Korrekte DNS Weiterleitung für VPN Clients

[GeeEmm]

Hallo zusammen,

unsere lokalen Netze verwenden alle lokale DNS Server, die via "DNS Weiterleitung" genutzt werden, also.:

Netz 1: Domäne * |Routing Tag Netz 1 | IP DNS Server 1 & IP DNS Server 2 (aus Netz 1)
Netz 2: Domäne * |Routing Tag Netz 2 | IP DNS Server 1 & IP DNS Server 2 (aus Netz 2)
Netz 3: Domäne * |Routing Tag Netz 3 | IP DNS Server 1 & IP DNS Server 2 (aus Netz 3)
....

Die VPN Clients sind via IKEv2 angebunden und bekommen alle IP Adressen aus Netz 1 sowie die Lancom Router IP aus Netz 1 als DNS Eintrag. Leider scheint jedoch hier die Weiterleitung nicht zu greifen, die Clients können die lokalen Domänen nicht auflösen und nutzen scheinbar weiterhin den Lancom Router, nicht jedoch die DNS Server, an die weiterleitet werden soll.

Nach mehren Tests konnte ich feststellen, dass ein Routing Tag "0" in der DNS Weiterleitungskonfiguration das Problem löst.

Ist das denn richtig? Sollte der Tag 0 nicht für alle Netze verwendet werden, was hier aufgrund von Segregation nicht gewünscht ist (bisher hat ja jeds Netz seine eigene lokale Weiterleitung)? Oder fehlt den VPN Clients an anderer Stelle ein Parameter?

Vielen Dank für eure Hilfe!
GeeEmm

[GrandDixence]

Für Einwahlverbindungen muss die DNS-Serverkonfiguration per IKE Config vom VPN-Server an die VPN-Clients verteilt werden. Siehe dazu die Angaben zu:

LCOS-Menübaum > Setup > VPN > IKEv2 > IKE-CFG > IPv4

unter:

fragen-zum-thema-vpn-f14/windows-phone- ... tml#p86774

fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

https://www.lancom-systems.de/docs/LCOS ... 6_7_1.html

Auf Windows-Rechnern mit:

# ipconfig /all

kontrollieren, ob IKE Config korrekt die DNS-Serverkonfiguration über den VPN-Clients an die Windows-Rechner verteilt.

Soll die DNS-Weiterleitung vom LANCOM-Router die weitergeleitete DNS-Anfrage mit einem (VLAN-)Tag versehen, muss mit "@<(VLAN-)Tag>" gearbeitet werden. Siehe Screenshot:

DNS-Weiterleitung zu einem DNS-Server im LAN.png

Da aber die DNS-Weiterleitung vom LANCOM-Router die Anwendung von DNSSEC und eine Namensauflösung per TCP (Serverport: TCP 53 statt UDP 53) blockiert, vermeide ich nach Möglichkeit die Nutzung der Funktion "DNS-Weiterleitung" im LANCOM-Router. Und nutze für DNS entsprechende Firewallregeln (Serverport TCP 53+UDP 53), welche die (VLAN-)Tags korrekt ersetzen (Tag VPN-Client -> VLAN-Tag DNS-Server).

[GeeEmm]

Hallo @GrandDixence,

vielen Dank für deine Antwort. Ich bin mir jedoch nicht sicher, ob ich das richtig verstanden habe .

Unter "LCOS-Menübaum > Setup > VPN > IKEv2 > IKE-CFG > IPv4" wird die IP des Lancom Routers für das Netz 1 erfolgreich mitgegeben.

Unter "LCOS-Menübaum > Setup > IPv4 > DNS > Weiterleitungen" befindet sich ebenfalls ein Eintrag:

* | Tag Netz 1|IP DNS Server 1 & DNS Server 2 aus Netz 1 (ohne @)

Diese Weiterleitung funktioniert für die Clients aus Netz 1 tadellos. Ein Eintrag mit "Tag 0" bei den Weiterleitungen würde sich doch auch auf die anderen Netze 2, 3, ... etc auswirken, oder?

Verstehe ich dich richtig, dass ich eine Firewallregel benötige, die explizit "Quelltag 0" für die VPN Clients mit "Routing Tag Netz 1" benötigt, damit die Clients die VPN Server aus der Weiterleitung in Netz 1 erreichen können, auch ohne "Tag 0 Weiterleitungseintrag" unter "LCOS-Menübaum > Setup > IPv4 > DNS > Weiterleitungen"?

Viele Grüße,
GeeEmm

[GeeEmm]

Hallo,

noch ein Nachtrag:

Wird die DNS-Weiterleitung für VPN-Clients umgangen, indem unter

„LCOS-Menübaum > Setup > VPN > IKEv2 > IKE-CFG > IPv4“

anstelle der IP des LANCOM-Routers direkt die IPs der beiden DNS-Server aus dem jeweiligen Netz angegeben werden, nutzen auch die VPN-Clients die gewünschten DNS-Server – allerdings ohne DNS-Weiterleitung.

Zusammengefasst bedeutet das:

1. Es sind sechs Netze vorhanden. Jedes Netz nutzt ein eigenes Routing-Tag X und VLAN X mit einer Default-DNS-Weiterleitung mit Routing-Tag X zu den jeweiligen DNS-Servern im eigenen Netz X über die LANCOM-Router-IP aus Netz X.
→ Alles funktioniert wie gewünscht.

2. Dieselbe Logik funktioniert nicht für VPN-Clients. Diese erhalten zwar eine IP-Adresse inklusive LANCOM-Router-IP als DNS Server aus Netz X,
→ die DNS-Weiterleitung funktioniert hier jedoch nicht.

3. Es gibt zwei Lösungsansätze, damit die VPN-Clients die gewünschten DNS-Server nutzen:

1) In der DNS-Weiterleitungsliste wird ein Eintrag mit Routing-Tag 0 hinzugefügt.
Da sich dieser Eintrag global auswirkt, wird auch die Weiterleitung aus den anderen lokalen Netzwerken beeinflusst.
→ VPN-Clients OK, jedoch unerwünschte Auswirkungen auf andere lokale Netzwerke hinsichtlich der DNS-Weiterleitung.

2) Anstelle der LANCOM-Router-IP werden den VPN-Clients direkt die IPs der DNS-Server aus Netz X zugewiesen.
→ VPN-Clients OK, kein Einfluss auf die getrennten DNS-Weiterleitungen der sechs separaten lokalen Netzwerke.

Da ich aus der Dokumentation nicht ganz schlau werde, stellt sich für mich die Frage:
Ist der zweite Lösungsansatz für VPN-Clients der richtige?

Bisher hatte ich immer verstanden, dass (zumindest für lokale Clients) die DNS-Weiterleitung der direkten Zuweisung via DHCP über
„LCOS-Menübaum > Setup > IPv4 > DHCPv4 > DHCP-Netzwerke > DNS-Server 1/2“
vorzuziehen ist.

Was sind eure Erfahrungen?

Viele Grüße
GeeEmm

[GeeEmm]

Hallo zusammen,

wie im vorherigen Post beschrieben, scheint die DNS Weiterleitung für die IKEv2 Clients nicht zu funktionieren, das Setzen der DNS Server Ziel IPs in „LCOS-Menübaum > Setup > VPN > IKEv2 > IKE-CFG > IPv4“ hingegen funktioniert.

Möchte man nun jedoch mit Hilfe der „LCOS-Menübaum > Setup > VPN > Allgemein > Netzwerk-Regeln > IPv4 Regeln" die Verbindung nur auf das spezische lokale Netz (inkl. der DNS Server) begrenzen, funktioniert die Domain Auflösung wieder nicht - die Requests landen nicht mal in der Firewall .

Was sind die Empfehlungen von Lancom? Ich werde aus der ganzen DNS Thematik für die VPN Clients nicht schlau...

[backslash]

Hi GeeEmm,

die Weiterleitung funktioniert dann wenn die VPN-Verbindung auch im korrekten Routing-Kontext steht. Dazu mußt du in der Tag-Tabelle (Kommunikation -> Gegenstellen -> WAN-Tag-Tabelle) der IKE-Verbindung ein Routing-Tag zu weisen. Dann kannst du in der DNS-Weiterleitungs-Tabelle beliebige Domains (auch "*") anhand des Tags an verschiedene DNS-Server weiterleiten. Den Weiterleitungszielen kannst du dann ggf. selbst per @xxx ein Tag verpassen, wenn der DNS-Server in einem anderen Kontext steht

Gruß
Backslash

[backslash]

Hi GeeEmm,

in der Tag-Tabelle kannst du i.Ü. Wildcards nutzen um Clients zusammenzufassen, z.B. wenn die Clients user_xxx@firma1, user_xxx@firma2, etc. heißen, dann kannst du mit *@firma1 bzw. *@firma2 alle Clients der jeweiligen Firmen in den passenden Kontext zwingen...

Gruß
Backslash

[GeeEmm]

Hallo backslash,

vielen Dank, das war sehr hilfreich - nun funktioniert die DNS Weiterleitung auch für die IKEv2 VPN Clients und der Router kann weiterhin als DNS Server den VPN Clients als IPv4 Konfiguration zugeteilt werden !

Das Routing-Tag in der VPN Verbindungsliste scheint sich somit nur auf den ausgehenden Traffic auszuwirken, wohingegen das Schnittstellen Tag in der WAN-Tag-Tabelle den eingehenden Traffic markiert.

Was mich gewundert hat: das Setzen von Routing-Tags in den VPN Firewallregeln hat wohl keinen Effekt, ich hätte vermutet, dass dies auch funktionieren sollte für den Traffic "Quelle VPN -> Service DNS -> Ziel: Router IP im Zielnetz".

Vielen Dank für eure Unterstützung!

Gruß,
GeeEmm

[backslash]

Hi GeeEmm

Das Routing-Tag in der VPN Verbindungsliste scheint sich somit nur auf den ausgehenden Traffic auszuwirken,

Nein, das Routing-Tag in der VPN Verbindungsliste gibt an, welche Route genutzt werden soll, um das entfernte Gateway zu erreichen - es geht also um die IKE-Pakete und die verschlüsselten Datenpakte.

wohingegen das Schnittstellen Tag in der WAN-Tag-Tabelle den eingehenden Traffic markiert.

Korrekt, das Tag in der WAN-Tag-Tabelle gibt an, in welchen Kontext auf dem VPN empfangene Pakete (also die entschlüsselten!) verarbeitet werden.

Du hast auf jeder Ebene eine eigene Virtualisierung des Routers...

Gruß
Backslash

[GeeEmm]

Hallo backslash,

alles klar, vielen Dank nochmal!

Viele Grüße,
GeeEmm