DNS-Weiterleitung // Absendeadressen

[wecs]

Hallo zusammen

Ich habe ein Problem mit dem DNS-Forwarding. Ein 1821n baut über ADSL / T-Online eine Verbindung ins Internet auf, über die gleiche Verbindung werden 2 VPN-Tunnel jeweils einem Intranet-Netzwerk aufgebaut. Das eigene Netz sei 172.25.10.*, die beiden VPN-Netze 172.25.11.* bzw. 12.*.

Der 1821n arbeitet als DHCP- und DNS-Server. Mein Problem ist nun folgendes. DNS-Anfragen für das Internet werden richtig geforwarded und erfolgreich aufgelöst. Für 2 Domänen, für die ein DNS-Forward an DNS-Server in den VPN-Netzen (11 und 12) eibgerichtet wird, funktioniert der Forward nicht. Der Trace zeigt zwar, dass die Forward-Rule erkannt wurde und der richtige Weiterleitungsserver ausgewählt wurde, bei dem kommt aber die Anfrage nicht an (Query-Log und Packet Dump). Ein Ping auf in die Netze 11 und 12 (von den Arbeitsstationen laufen alle Verbindungen, die die Firewall zulässt), kommt auch nicht durch, ausser ich gebe per -a die Adresse des 1821n im 172.25.10.* Netz an.

Ich vermute einmal, dass der Router seine Anfragen (und die Pings) standardmässig mit einer anderen Adresse verschickt, z.B. seiner Internetadresse. Damit läuft natürlich weder die DNS-Anfrage im VPN noch der Ping.

1. Kann das sein? Wie kann ich den Router dazu bringen, bei Anfragen in die VPN-Netze seine interne Adresse zu verwenden?
2. Welche Rolle spielt die Firewall bei Zugriffen routerinterner Dienste (z.B. DHCP, DNS, NTP, etc.)

Zudem funktioniert die NTP-Anfragen ins Internet (z.B. PTB) nicht.

3. Kann das die gleiche Ursache wie o.g. Problem haben?
4. Kann ich den NTP-Client irgendwie tracen?
5. Beim NTP-Client kann ich anscheinend die Absendeadresse angeben. Wie kann ich hier angeben, dass der Router seine Internetadresse verwenden soll, die bei jeder Einwahl ändert?

Danke für Eure Tipps!!

Gruss
Wolfgang

---

PS. Es sind nach mehreren Jahren Cisco und Bintec meine ersten Lancoms. Die Wartung habt ihr ziemlich durchdacht implementiert und die Teile laufen wirklich stabil. Hut ab!!

[wecs]

Hallo zusammen

Hat den wirklich niemand eine Idee ?!

Vielleicht hilft es, die Frage etwas einzuschränken:

Wie bestimmen die Lancom-eigenen Dienste PING, DNS-Forward, NTP-Client, welche Absendeadresse für die Anfragen verwendet werden, wenn nichts angegeben wurde (bei ping ohne -a, bei DNS-Forward an IP-Adresse kann man nichts angeben)?

Danke und Gruss
Wolfgang

[Lars]

Ich habe hier gerade das exakt gleiche Problem. dns Anfragen in ein VPN Netzwerk werden nach (für mich) nicht nachvollziehbaren Regeln bezüglich der Absendeadressen durchgeführt. Gibt es dazu irgendeine Dokumention die ich übersehen habe? Oder ein Konfigurationsmöglichkeit.

Persönlich würde ich erwarten, dass der Lancom entweder als Absendeadresse eine fest einstellbare verwendet oder die Adresse aus dem Netzwerk aus dem die Anfrage stammt. Beides scheint aber nicht der Fall zu sein?

Mit freundlichen Grüßen, Lars

[Bernie137]

Moin,

Du hast die DNS Server über Kommunikation -> Gegenstellen -> "Eintrag für VPN-172.25.11.* Gegenstelle" konfiguriert?

Gruß Heiko

[backslash]

Hi,

Das LANCOM nimmt die Adresse, die es auf dem Interface hat, das dem Ziel am nächsten liegt. Hat es dort keine - wie i.A. bei VPN-Tunneln - dann nimmt es die des ersten LAN-Interfaces, das zum Routing-Tag des Ziel-Interfaces paßt... Wird es dort nicht fündig, wird die Adresse des ersten LAN-Interfaces genommen...

Um der VPN-Verbindung eine IP-Adresse zu verpassen, mußt du nur einen Eintrag in der IP-Parameterliste (Kommunikation -> Protokolle -> IP-Parameter) aufnehmen.

Gruß
Backslash

[Lars]

Um der VPN-Verbindung eine IP-Adresse zu verpassen, mußt du nur einen Eintrag in der IP-Parameterliste (Kommunikation -> Protokolle -> IP-Parameter) aufnehmen.

Einträge an der Stelle scheinen leider keinen Effekt zu haben.

Die Reihenfolge der Netzwerke dagenen schon. Hirerbei scheint das Routing Tag, das VLan Tag und der Name eine Rolle zu spielen...

[diemoories]

Hallo und Moin,

nur mal so als Hinweis: In Sachen DNS Weiterleitung ist Einiges seitens der Lancom Entwickler getan worden:
LCOS Änderungen von 8.80.xx ► 8.82.xx

Neue Features:

DNS ist pro ARF-Netzwerk konfigurierbar


Änderungen:

Ein Eintrag in der DNS Weiterleitungstabelle wird auch ohne Neustart wirksam
Wurde der Internetgegenstelle kein DNS-Server zugewiesen, wird der DNS-Server unter
TCP/IP->Adressen verwendet.
Interne DNS-Anfragen werden von der Firewall nicht mehr geblockt, wenn die DNS-Regel
gezielt auf die Internetgegenstelle verweist.
DNS-Weiterleitungen werden bei mehreren getaggten ARF-Netzten mit der richtigen
Quelladresse verschickt.

Außerdem können jetzt für jeden Routing-Tag Kontext eigene Einstellungen des internen DNS-Servers hinsichtlich Aktivität, Antwortverhalten, DHCP, NetBIOS, Diensteweiterleitung und Stationsnamensauflösung festgelegt werden.


Das bedeutet, dass man nun für jedes Routing-Tag festlegen kann bzw. muss, wohin die Weierleitung (z.B. *.* oder *.intern) gehen soll. Das macht natürlich auch bei einigen bestehenden Konfigurationen Änderungen erforderlich, da bislang die Weiterleitung immer über Routing Tag 0 (interne Dienste) lief.

Nachtrag in diesdem Zusammenhang: Auch bei den Firewallregeln kann nun ein Quelltag Kontext angegeben werden, was zu einer weiteren Verfeinerung der ARF-Möglichkeiten führt.

Viele Grüße
Ralf

[diemoories]

Probleme mit Weiterleitungstabelle:

Ich habe mehrere DNS-Weiterleitungen mit Routing Tags definiert.
Bei meinen Scripten fiel mir schon auf, dass die Tabelle /2/17/9/ sich irgendwie merkwürdig verhält.
Daher habe ich das Aktionstabellen-Scripten komplett deaktiviert und über telnet untersucht, was mit dem neuen Feature los ist. Hier mein Ergebnis.

Mit dem Befehl
set /2/17/9/*.* 0 INTERNET1
wird ein Eintrag zur Liste hinzugefügt??
Ergebnis: Mir set wird immer der jeweils der "erstbeste" Eintrag überschrieben. Aber mit "erstbeste" definiert LCOS wie ich finde etwas eigensinnig:
z.B. in einer Rtg-Tag Liste 112, 111, 110, 82, 32, 31,0 führt
set /2/17/9/*.* 8 INTERNET1 zum Überschreiben des 82 Eintrages, was definitiv nicht gewünscht ist.

Mit dem Befehl
add /2/17/9/*.* 0 INTERNET1
wird ein Eintrag hinzugefügt??
Ergebnis: Mir add wird der Eintrag ergänzt bzw. falls vorhanden überschrieben

Könnte man (vorübergehend) mit leben, aber wie einen Eintrag löschen?

Mit dem Befehl
del /2/17/9/*.* 0 INTERNET1
wird der Eintrag aus der Liste gelöscht??
Ergebnis: del funktioniert genau einmal, wenn es exakt den Eintrag gibt. Ansonsten wird wiederum der "Nächstbeste" gelöscht.

Da ich DNS-Weiterleitungen über Actions steuere, wird mir so sukkzessive die ganze Tabelle gelöscht.
Das ist nicht so gut.
Behelfsweise add /2/17/9/*.* 0 "" führt leider auch nicht zum Erfolg, da das DNS-Modul einen Leereintrag als Ziel ganz unerwartet interpretiert.

Wie kann ich sicher und gezielt einen bestimmten Eintrag aus der Liste LÖSCHEN, ohne das LCOS andere löscht , wenn die Eintrag nicht existiert?

Viele Grüße und vielen Dank für Hilfe!
Ralf

[backslash]

Hi diemoories

Da ich DNS-Weiterleitungen über Actions steuere, wird mir so sukkzessive die ganze Tabelle gelöscht.
Das ist nicht so gut.
Behelfsweise add /2/17/9/*.* 0 "" führt leider auch nicht zum Erfolg, da das DNS-Modul einen Leereintrag als Ziel ganz unerwartet interpretiert.

Wie kann ich sicher und gezielt einen bestimmten Eintrag aus der Liste LÖSCHEN, ohne das LCOS andere löscht , wenn die Eintrag nicht existiert?

nun ja, da beissen sich nun die "Kofmfort-Funktionen" des CLI mit deinen Anforderungen...

Probier's mal damit, daß du vor dem Löschen des Eintrags diesen gezielt per add anlegst - denn dann existiert er ja und kann auch gezielt gelöscht werden. Du mußt dabei nicht befürchten, daß du damit die Tabelle auf einmal mit überflüssigen Einträgen flutest: Wenn "add" einen Eintrag findet, bei dessen Indexspalten exakt mit dem Parametern übereinstimmen, dann überschreibt add nur die "nicht-Indexpsalten" des Eintrags...

ist nicht shön, sollte aber funktionieren - und der Aktionstabelle ist es schließlich egal, wieviele Kommandos sie ausführen soll...

Gruß
Backslash

[diemoories]

Hallo Backslash!
Danke für die Info. Ich dachte schon, es wäre eine Fehlfunktion.
Ich werd's mal probieren und eine Weile laufen lassen:

"exec: add /2/17/9/*.* 0 DUMMY; del /2/17/9/*.* 0 DUMMY; # Eintrag RtgTag 0 loeschen"

Viele Grüße
Ralf