DNS Weiterleitung 'klemmt' nach ein paar Stunden

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Antworten
CyberChris
Beiträge: 53
Registriert: 21 Jul 2005, 22:13
Wohnort: Bremen

DNS Weiterleitung 'klemmt' nach ein paar Stunden

Beitrag von CyberChris »

Hallo Forum,

Folgende konfiguration: 1823 ist über einen VPN Tunnel mit einem 1711 in der firma verbunden. Der Tunnel ist permanent aufgebaut.

Firma hat "domainA.local". Mein Lancom "domainB.local"

In meinem Lancom habe ich eingestellt das DNS anfragen *.domainA.local" an den 1711 in der Firma weitergeleitet werden. Das hat auch sehr lange problemlos funktioniert.

Neuerdings habe ich aber das Problem das nach einiger Zeit Hostnamen wie z.b. RechnerA.domainA.local nicht mehr aufgelöst werden. Ein nslookup RechneA.domainA.local liefert einen TimeOut.

Ein Ping auf die IP Adresse des RechnerA funktioniert. D.h. der Tunnel steht und funktioniert.

Baue ich dann den VPN Tunnel ab und neu auf funktioniert auch die DNS Weiterleitung wieder ein paar Stunden.

Hat da jemand eine Idee woran das liegen könnte ?

Gruß,
Christian
froeschi62
Beiträge: 985
Registriert: 13 Dez 2004, 10:44

Beitrag von froeschi62 »

Hallo zusammen,

ich habe ebenfalls ein DNS Problem im VPN Tunnel. Allerdings führt bei mir der Lancom die DNS Anfragen durch. Aber auch nach mehreren Stunden funktioniert die DNS Auflösung plötzlich nicht mehr obwohl der VPN Tunnel nachwievor steht.

Viele Grüße
Dietmar
Lancom 1823 VOIP
backslash
Moderator
Moderator
Beiträge: 7132
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi CyberChris und froeschi62

was sagt denn ein DNS-Trace im Fehlerfall?

@CyberChris:

eine Domain "local" solltest du tunlichst *NICHT* verwenden - die beisst sich mit Apples Rendezvous-Protokoll. Nicht umsonst lautet die Vorbelegung im LANCOM "intern"

Gruß
Backslash
froeschi62
Beiträge: 985
Registriert: 13 Dez 2004, 10:44

Beitrag von froeschi62 »

Hallo Backslash,

sollte es wieder auftreten, werde ich diesen Trace ausführen.

Viele Grüße
Dietmar
Lancom 1823 VOIP
CyberChris
Beiträge: 53
Registriert: 21 Jul 2005, 22:13
Wohnort: Bremen

Beitrag von CyberChris »

backslash hat geschrieben: eine Domain "local" solltest du tunlichst *NICHT* verwenden - die beisst sich mit Apples Rendezvous-Protokoll. Nicht umsonst lautet die Vorbelegung im LANCOM "intern"
Danke für den Tipp werde ich in Zukunft berücksichtigen. In diesem Fall waren die Domains allerdings schon vor den Lancom's da ;) Und mal eben ein gewachsenes Firmennetzwerk umzubennennen geht ad hoc schlecht.

Den DNS Trace mache ich sobald ich das Problem wieder zu sehen bekomme.

Gruß,
Christian
CyberChris
Beiträge: 53
Registriert: 21 Jul 2005, 22:13
Wohnort: Bremen

Beitrag von CyberChris »

backslash hat geschrieben:Hi CyberChris und froeschi62
was sagt denn ein DNS-Trace im Fehlerfall?
So, ich hatte das Problem soeben mal wieder und habe ein trace gemacht.

Letzte mal hatte ich noch nicht erwähnt das auf beiden Seiten andere LCOS Versionen im Einsatz sind. Mein Lancom 1823, LCOS 7.26. Andere Seite 1711, LCOS 6.32

Auf meiner Seite sieht das DNS Trace so aus:

[DNS] 2008/02/24 13:10:31,710
DNS Rx (LAN-1, INTRANET): Src-IP 192.168.1.5
Query Request: STD A for RechnerA.domainA.local
DnsGetDest: Match found: forwarding RechnerA.domainA.local to route GATEWAY
Not found in local DNS database => forward to next server
NameQuery: Forward to route GATEWAY

Auf der B-Seite sehe ich in diesem Fall im trace nichts. Und mein nslookup bringt nach ein paar Sekunden die timeout Meldung.


Wenn ich nun den VPN Tunnel ab und wieder aufbaue und die gleiche Anfrage noch mal stelle funktioniert es und im trace finde ich:

Bei mir:

[DNS] 2008/02/24 13:28:57,840
DNS Rx (LAN-1, INTRANET): Src-IP 192.168.1.5
Query Request: STD A for RechnerA.domainA.local
DnsGetDest: Match found: forwarding RechnerA.domainA.local to route GATEWAY
Not found in local DNS database => forward to next server
NameQuery: Forward to route GATEWAY

Und auf der anderen Seite:

[DNS] 2008/02/24 13:29:02,150
DNS Rx (CYBERGATEWAY): Src-IP 192.168.1.1
Name Query: STD A for RechnerA.domainA.local
Address resolved to 192.168.0.5

Sieht für mich so aus als wenn im Fehlerfall die weitergeleitete DNS Anfrage im 1711 nicht ankommt.

Gruß,
Christian
backslash
Moderator
Moderator
Beiträge: 7132
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi CyberChris,

hast du zufällig am Maskierungstimeout für UDP gedreht? Der steht im Default nicht umsonst auf nur 20 Sekunden...
Mein Lancom 1823, LCOS 7.26. Andere Seite 1711, LCOS 6.32
passiert das auch, wenn du bei dir lokal die 7.28 einsetzt?

Gruß
Backslash
backslash
Moderator
Moderator
Beiträge: 7132
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi CyberChris

mir fällt gerade noch ein Grund für das Problem ein:
Andere Seite 1711, LCOS 6.32
du solltest auch hier eine 7.28 einsetzen, da die 6.32 aufgrund einen Bugs u.U. meinen könnte, die Sendequeue wäre zu lang - obwohl sie in Wirlichkeit leer ist...

Gruß
Backslash
CyberChris
Beiträge: 53
Registriert: 21 Jul 2005, 22:13
Wohnort: Bremen

Beitrag von CyberChris »

Hi,
passiert das auch, wenn du bei dir lokal die 7.28 einsetzt?
Gruß
Backslash
Sorry, da hatte ich mich versehen, ich habe hier schon die 7.28 im Einsatz. Am UDP Aging habe ich nichts gedreht. Das steht auf beiden Seiten auf 20 Sek.

Was für mich derzeit gegen den Update des 1711 auf die 7.28 spricht ist das ich dann wohl besser alle Lancoms die da noch Verbindungen haben auch gleich updaten sollte. Derzeit haben die 6.32 und das macht keine Probleme. Nur um das alles zu updaten muß ich erstmal einen Zeitfenster finden....

Das DNS Problem habe bisher nur ich.

Gruß & danke für die Tipps,
Christian
backslash
Moderator
Moderator
Beiträge: 7132
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi CyberChris
Derzeit haben die 6.32 und das macht keine Probleme. (...)
Das DNS Problem habe bisher nur ich.
OK, dnn müßte es doch irgendwie an der 7.28 liegen. OK schalten wir im Fehlerfall mal alle Traces an, an denen das Paket vorbei kommt:

trace # dns ip-router ip-masq vpn-packet

Achte dabei bitte darau, daß außer der DNS-Anfrage möglichst *nichts* anderes läuft, da der Trace sonst nicht auswertbar wird...

Da du ja sagst, daß ein Ping noch funktioniert: schicke bei den aktivierten Traces auch noch ein Ping durch das Gerät.

Gruß
Backslash
DirkG
Beiträge: 25
Registriert: 03 Mär 2006, 19:51

Beitrag von DirkG »

Hallo,

ich habe ein vergleichbares Problem mit der DNS-Auflösung seit der Firmware 7.28 beobachet, wobei ich als Gegenstelle den VPN-Advanced Client verwende.

Der VPN Tunnel besteht weiter, jedoch ist der Client nach einiger Zeit nicht mehr in der Lage, eine DNS-Auflösung vom LANCOM zu erhalten.
NSLOOKUP läuft hier auf einen Time-Out.

Interessant ist hierbei noch, dass der LANCOM lokal selbst keine Probleme mit der DNS-Auflösung hat, so dass sich das Problem auf den VPN-Tunnel reduzieren läßt.

Viele Grüße,
Dirk
froeschi62
Beiträge: 985
Registriert: 13 Dez 2004, 10:44

Beitrag von froeschi62 »

Hallo DirkG,

exakt mein Problem. Auch bei mir ist es wieder nach einiger Zeit aufgetreten. Plötzlich kein DNS trotz bestehendem Tunnel. Das scheint definitiv ein Bug der 7.28 zu sein. Ebenfalls lokal keine Probleme bei der DNS Auflösung. Hatte leider bisher noch keine Möglichkeit, einen DNS Trace durchzuführen und jetzt habe ich erst einmal Urlaub.

Viele Grüße
Dietmar
Lancom 1823 VOIP
DirkG
Beiträge: 25
Registriert: 03 Mär 2006, 19:51

Beitrag von DirkG »

Hallo,

zusätzlich zur Problematik mit der DNS-Auflösung habe ich heute auch beobachten können, dass bestehende VoIP-Verbindungen über den VPN-Tunnel parallel mit der einsetzenden Störung des DNS-Dienstes ebenfalls ausfallen.

Dies läßt vermuten, dass sich das Problem nicht ausschließlich auf den DNS-Dienst bezieht, sondern der VPN-Tunnel insgesamt nicht mehr vollständig funktionsfähig ist.

Viele Grüße,
Dirk
Benutzeravatar
hsudholz
Beiträge: 23
Registriert: 17 Jan 2008, 08:34
Wohnort: Oldenburg
Kontaktdaten:

Beitrag von hsudholz »

Hallo,
dem Thema füge ich noch weitere Sympthome hinzu. Reproduzierbar werden bei uns Internetverbindungen, welche lange Zeit stehen bleiben (z.B. Internetradio, aber auch lokale wie Webinterfaces [Nagios etc]) unterbrochen.
Auch im VPN (1724<->1722) geschehen seltsame Dinge. Z.B. der LC ist noch zu sehen - alles andere nicht.
Nach coldstart geht dann alles wieder.
Da das hier ein Produktivsystem ist, machen wir nun auf allen routern (7 Stück, alle LCOS 7.28 ) nachts um 2 einen coldstart. Hilft aber nur bedingt weiter.
Hilfe wäre echt nett.
Gruss, Horst
Antworten