(IP-IP): connection refused

[plumpsack]

Was bedeutet das?

Nach dem "alten Schema" steht bei mir folgender Alarm:

Code: Alles auswählen

LOCAL3 	Alarm 	Dst: xxx.xxx.xxx.xxx {ROUTER}, Src: yyy.yyy.yyy.yyy (IP-IP): connection refused

Die Firmware ist immer noch, 10.50.1077, aktuell.

Danke schon einmal für die Info.

[gzata]

Was bedeutet das?

Nach dem "alten Schema" steht bei mir folgender Alarm:

Code: Alles auswählen

LOCAL3 	Alarm 	Dst: xxx.xxx.xxx.xxx {ROUTER}, Src: yyy.yyy.yyy.yyy (IP-IP): connection refused

Die Firmware ist immer noch, 10.50.1077, aktuell.

Danke schon einmal für die Info.

Hallo und guten Abend

Wenn ich das auf dem FTP richtig sehe, ist Deine Version Beta
LANCOM-Beta/LCOS/LCOS 10.50/BUIL1077/

aktuelle Lancom Releases sind:

a) auf der 10.50er Schiene die 10.50.1107 RU10
(gem. Release Notes: "Wenn ein Netzwerk-Teilnehmer im lokalen Netzwerk des Routers eine DNS Anfrage zu schnell wiederholt, wird eine zweite DNS-Anfrage mit dem gleichen Quell-Port an den Backup-DNS-Server geschickt. Nach Erhalt der Antwort eines der beiden DNS-Server wird der Port geschlossen. Erhält der Router anschließend auch noch die Antwort des zweiten DNS-Servers, wird
diese abgelehnt.
Dadurch wurde die Meldung „connection refused“ im Syslog aufgezeichnet
(Priorität ‚Alarm‘). Durch dieses Verhalten konnte es vorkommen, dass im
Syslog viele ‚False Positive‘-Meldungen aufgezeichnet wurden. Die Priorität
der Meldung „connection refused“ wurde jetzt auf ‚Info‘ geändert, sodass
diese in der Standard-Konfiguration nicht im Syslog aufgezeichnet wird)"

b) auf der 10.70 Schiene die LCOS-10.72.0092 SU2
(gem. Release Notes: "→ „Connection Refused“-Meldungen werden nun im Syslog mit Level ‚Info‘ statt „Alarm“ angezeigt. Dies führt dazu, dass diese Meldungen nicht mehr im Syslog der WEBconfig im Default angezeigt werden.
Das Verhalten kann durch eine Konfigurationsänderung angepasst werden,")

Also vermutlich liegt es an der Beta Version -
.... und wenn ich mich recht erinnere ist das Thema schon in einem andern Thread ausführlich abgehandelt worden.

Viele Grüße


"

[plumpsack]

Wenn ich das auf dem FTP richtig sehe, ist Deine Version Beta
LANCOM-Beta/LCOS/LCOS 10.50/BUIL1077/

aktuelle Lancom Releases sind:

A) Das sind keine "Beta-Versionen":

Code: Alles auswählen

https://ftp.lancom.de/T-Systems-Releases/LC-R883-plus/

LC-R883-plus-10.50.1077.upx

Code: Alles auswählen

https://ftp.lancom.de/T-Systems-Releases/LC-R883VAW/

LC-R883VAW-10.50.1077.upx

Code: Alles auswählen

https://ftp.lancom.de/T-Systems-Releases/LC-R884VA/

LC-R884VA-10.50.1077.upx

Und B)

Was bedeutet die Meldung IP-IP ?

.... und wenn ich mich recht erinnere ist das Thema schon in einem andern Thread ausführlich abgehandelt worden.

Wo steht was "(IP-IP): connection refused" bedeutet?

[backslash]

genau das ist dert Grund, weshalb das in der 10.72 auf Info herbgsetuft wurde.

Es wurde dir auch schon mehrfach erklärt!

[LoUiS]

Ignorier den Troll doch einfach. Wenn Ihr Ihm auch noch antwortet kriegt er nur unnoetig Aufmerksamkeit.

[tstimper]

Zurück zum eigentlichen technischen Sachverhalt

aktuelle Lancom Releases sind:

a) auf der 10.50er Schiene die 10.50.1107 RU10
(gem. Release Notes: "Wenn ein Netzwerk-Teilnehmer im lokalen Netzwerk des Routers eine DNS Anfrage zu schnell wiederholt, wird eine zweite DNS-Anfrage mit dem gleichen Quell-Port an den Backup-DNS-Server geschickt. Nach Erhalt der Antwort eines der beiden DNS-Server wird der Port geschlossen. Erhält der Router anschließend auch noch die Antwort des zweiten DNS-Servers, wird
diese abgelehnt.

Sind wir wirklich alle der Meinung, das hier das Verhalten von LCOS korrekt ist?
Also wenn ein Client " zu schnell" (was ist eigentlich "zu schnell", gibt es da einen Parameter, den man sehen oder setzen kann?)
die DNS Anfrage wiederholt, sollte da nicht zumindest dann,
wenn LCOS diese Anfrage an den im LCOS konfigurierten Backup DNS Server schickt, dem zuzusagen ausgehend ein anderer Quellport zugeordnet werden? Wie gesaht, die Anfrage geht ja auch noch an eine ganz anderer IP Adresse, also natürlich hat so eine Anfrage ein anderen Quellport zu haben.


Warum kann das nicht innerhalb LCOS geeignet behandelt werden?

Dadurch wurde die Meldung „connection refused“ im Syslog aufgezeichnet
(Priorität ‚Alarm‘). Durch dieses Verhalten konnte es vorkommen, dass im
Syslog viele ‚False Positive‘-Meldungen aufgezeichnet wurden. Die Priorität
der Meldung „connection refused“ wurde jetzt auf ‚Info‘ geändert, sodass
diese in der Standard-Konfiguration nicht im Syslog aufgezeichnet wird)"

Its es wirklich die richtige Vorgehensweise, den Syslog auf "Info" zusetzen,
um die Admins nicht zu nerven?

Dadurch geht ja die Sicht auf die „connection refused“ Meldungen, die ggf interessieren würden, verloren.

Ich hab mal kurz RFCs gegoogled

https://datatracker.ietf.org/doc/html/r ... ection-4.1

Code: Alles auswählen

The following address and port mapping behavior are defined:

      Endpoint-Independent Mapping:

         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to any
         external IP address and port.  Specifically, X1':x1' equals
         X2':x2' for all values of Y2:y2.


Address-Dependent Mapping:

         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to the same
         external IP address, regardless of the external port.
         Specifically, X1':x1' equals X2':x2' if and only if, Y2 equals
         Y1.

Address and Port-Dependent Mapping:

         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to the same
         external IP address and port while the mapping is still active.
         Specifically, X1':x1' equals X2':x2' if and only if, Y2:y2
         equals Y1:y1.

REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.

Also wenn ich das richtig verstehe:

Code: Alles auswählen

REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.

MUSS LCOS (wenn es der RFC für NAT folgen will) für die zweite Anfrage, die es an den Backup DNS Server schickt, einen separaten Quellport öffnen
und auch die Antwort vom Backup DNS Server an den internen Client weiterleiten.

Es wäre also falsch, das durch Ändern des Loglevels für ALLE "connection refused" Meldungen von Alarm auf Info zu setzen.

Das könnte man allerhöchstens für diesen speziellen Fall machen, wo eine Anfrage kurz hintereinander an Primary und Backup DNS geschickt wird.

Richtiger wirds dadurch nicht.

Richtig wäre: es ist eine neue ausgegende Verbindung seitens LCOS aun eine neue IP Adresse, deshalb neuer Quellport und korrektes Weiterleiten der Antwort an den fragenden Client


Viele Grüße

ts

[backslash]

Hi tstimper

Code: Alles auswählen

MUSS LCOS (wenn es der RFC für NAT folgen will) für die zweite Anfrage, die es an den Backup DNS Server schickt, einen separaten Quellport öffnen
und auch die Antwort vom Backup DNS Server an den internen Client weiterleiten.

Das DNS-Forwarding ist kein NAT...

Und daß der Port geschlossen wird, wenn eine Antwort kommt, dient dazu, DNS-Cache-Poisoning per DNS-Spoofing zu verhindern... siehe dazu auch https://www.heise.de/security/meldung/M ... 84975.html

Gruß
Backslash

[tstimper]

Hi tstimper
Das DNS-Forwarding ist kein NAT...

ok, da LCOS von der Public IP aus den DNS Request sendet

Und daß der Port geschlossen wird, wenn eine Antwort kommt, dient dazu, DNS-Cache-Poisoning per DNS-Spoofing zu verhindern... siehe dazu auch https://www.heise.de/security/meldung/M ... 84975.html

Dss gild bei DNS Anfragen an DENSELBEN DNS Server, nicht für DNS Anfragen an VERSCHIEDENE DNS Server.

Viele Grüße

ts

[gzata]

Guten Abend

Das DNS-Forwarding ist kein NAT...

Und daß der Port geschlossen wird, wenn eine Antwort kommt, dient dazu, DNS-Cache-Poisoning per DNS-Spoofing zu verhindern... siehe dazu auch https://www.heise.de/security/meldung/M ... 84975.html

Vielen Dank Backslash und tstimper für Eure Ausführungen und den Link (den Artikel kannte ich noch nicht).

von tstimper » Heute, 18:04

Zurück zum eigentlichen technischen Sachverhalt

- hier noch zum Sachverhalt (IP - IP) -

Nur interessehalber,
könnte es sich bei der Src um ein mobiles Endgerät handeln, und (IP-IP) als Hinweis auf ein fehlerhaftes Tunneling deuten?
(siehe auch IP in IP encapsulation, RFC 1853).

Vielleicht liege ich auch komplett falsch - insoweit bitte um Nachsicht, ich stecke da nicht so tief drin.

Viele Grüße
.

[backslash]

Hi gzata

Nur interessehalber,
könnte es sich bei der Src um ein mobiles Endgerät handeln, und (IP-IP) als Hinweis auf ein fehlerhaftes Tunneling deuten?
(siehe auch IP in IP encapsulation, RFC 1853).

ja, in der Klammer steht das Protokoll - hier also IPv4-in-IP. Mehr ist da aber nicht rauszuholen... "connection refused" sagt halt nur, daß da ein Paket an die IP des LANCOMs gerichtet war, für das das LANCOM keinen Listener hat.

Gruß
Backslash

[tstimper]

Hi gzata

Nur interessehalber,
könnte es sich bei der Src um ein mobiles Endgerät handeln, und (IP-IP) als Hinweis auf ein fehlerhaftes Tunneling deuten?
(siehe auch IP in IP encapsulation, RFC 1853).

ja, in der Klammer steht das Protokoll - hier also IPv4-in-IP. Mehr ist da aber nicht rauszuholen... "connection refused" sagt halt nur, daß da ein Paket an die IP des LANCOMs gerichtet war, für das das LANCOM keinen Listener hat.

Gruß
Backslash

Hi Backslash,

das erklärt gut die vermutete Implementation.

Bekommt LCOS eine DNS Anfrage von einem interen Client, schickt es die an den ersten konfiguriuerten oder per DHCP vom Provider übergebenen DNS Server und öffnete dazu einen Listener.

Bekommt LCOS "kurz dannach" (ist diese Zeit irgendwo spezifiziert?) eine weitere DNS Anfrage von demselben internen Client,
so schickt LCOS eine DNS Anfrage über an den Backup DNS Server und nutzt dafür denselben Listener, ohne im mitzuteilen, das er auf zwei
Antworten und auch noch von verschiedenen DNs Servern hören soll.

Kommt jetzt eine Antwort auf eine der beiden Anfragen, vermutlich egal von welchem DNS Server,
dann schliesst der Listener und die zweite Antwort wird verworfen.

Jetzt stellt sich natürlich folgende Frage:

Trackt LCOS überhaupt mit, von welchen beiden DNS Servern es in dem Moment eine Antwort erwartet?
Kann eigentlich nicht sein, denn das ist ja eine 1:1 Beziehung.

Daraus ergibt sich die zweite Frage, wie prüft LCOS in diesem Fall, ob die Antwort vom richtigen DNS Serevr kam?

Oder würde LCOS in diesem Fall (Listener ist offen für DNS UNABHÄNGIG von der sendenden IP?) auf JEDES DNS Reply auf dieses Listener Port antworten?

Also eigentlich sehe ich hier nur zwei Varianten, wie es implementiert sein könnte:

Variante 1: das Reply auf die DNS Anfrage auf den Backup DNS Server wird IMMER verworfen
Variante 2: es wird immer das erste Reply auf die DNS Anfrage weitergeleitet und alle weiteren Replies werden verworfen

Variante 2 kann aus meiner Sicht nur funktionieren, wenn dabei die Quell IP, also der DNS Server, der das Reply schickt, nicht geprüft wird.

Begründung: Der Listener hört auf einem Port auf eine Antwort von einer spezifischen IP, er kennt keine Liste von IPs und einen Zähler von Requests, auf die es Replies geben könnte.

Hier benötigen wir wirklich eine Klarstellung.

Variante 1 wäre ein Bug.
Variante 2 wäre eine CVE, da die Antwort IP nicht beprüft wird

Ich hoffe auf Variante 1 ...

Viele Grüße
ts

[backslash]

Hi tsimper

Bekommt LCOS eine DNS Anfrage von einem interen Client, schickt es die an den ersten konfiguriuerten oder per DHCP vom Provider übergebenen DNS Server und öffnete dazu einen Listener.

korrekt

Bekommt LCOS "kurz dannach" (ist diese Zeit irgendwo spezifiziert?) eine weitere DNS Anfrage von demselben internen Client,
so schickt LCOS eine DNS Anfrage über an den Backup DNS Server und nutzt dafür denselben Listener, ohne im mitzuteilen, das er auf zwei
Antworten und auch noch von verschiedenen DNs Servern hören soll.

aber nur, wenn es auch eine Wiederholung ist, also, wenn der Client den Selben Quell-Port *UND* die selbe Transaction-ID verwednet - und der Listener weiss schin, daß es meherer Server gibt. Verlasse gedanklich bitte die Posix-Welt...

(ist diese Zeit irgendwo spezifiziert?)

das LANCOM wartet maximal 30 Sekunden auf eine Antwort, bevor der Listener definitiv wieder entfernt wird

Trackt LCOS überhaupt mit, von welchen beiden DNS Servern es in dem Moment eine Antwort erwartet?
Kann eigentlich nicht sein, denn das ist ja eine 1:1 Beziehung.

doch... Der Listener akzeptiert Antworten nur von den Serven, an die die Anfrage weitergeleitet wurde - und dann müssen natürlich in der Antwort auch Zielport und Transaction-ID sowie die DNS-Anfrage (Query) übereinstimmen.

Variante 1: das Reply auf die DNS Anfrage auf den Backup DNS Server wird IMMER verworfen
Variante 2: es wird immer das erste Reply auf die DNS Anfrage weitergeleitet und alle weiteren Replies werden verworfen

Variante 2

Variante 2 kann aus meiner Sicht nur funktionieren, wenn dabei die Quell IP, also der DNS Server, der das Reply schickt, nicht geprüft wird.

wie kommst du denn darauf?

Begründung: Der Listener hört auf einem Port auf eine Antwort von einer spezifischen IP, er kennt keine Liste von IPs und einen Zähler von Requests, auf die es Replies geben könnte.

Auf UDP-Ebene hört der Listener natürlich erstmal nur auf den Port... Sobald ein Paket ansteht, prüft er, ob es akzeptabel (Quell-IP, Quell-Port, Transaction-ID, Query) ist. Wenn nicht, kommt ein port unreachable zurück... Wenn es akzeptabel ist, wird der Listener geschlossen und das Paket an den Client im LAN weitergeleitet

Variante 2 wäre eine CVE, da die Antwort IP nicht beprüft wird

nein, denn die IP wird geprüft - und nich mehr...

Gruß
Backslash

[tstimper]

Hi tsimper

Bekommt LCOS eine DNS Anfrage von einem interen Client, schickt es die an den ersten konfiguriuerten oder per DHCP vom Provider übergebenen DNS Server und öffnete dazu einen Listener.

korrekt

Bekommt LCOS "kurz dannach" (ist diese Zeit irgendwo spezifiziert?) eine weitere DNS Anfrage von demselben internen Client,
so schickt LCOS eine DNS Anfrage über an den Backup DNS Server und nutzt dafür denselben Listener, ohne im mitzuteilen, das er auf zwei
Antworten und auch noch von verschiedenen DNs Servern hören soll.

aber nur, wenn es auch eine Wiederholung ist, also, wenn der Client den Selben Quell-Port *UND* die selbe Transaction-ID verwednet - und der Listener weiss schin, daß es meherer Server gibt. Verlasse gedanklich bitte die Posix-Welt...

(ist diese Zeit irgendwo spezifiziert?)

das LANCOM wartet maximal 30 Sekunden auf eine Antwort, bevor der Listener definitiv wieder entfernt wird

Trackt LCOS überhaupt mit, von welchen beiden DNS Servern es in dem Moment eine Antwort erwartet?
Kann eigentlich nicht sein, denn das ist ja eine 1:1 Beziehung.

doch... Der Listener akzeptiert Antworten nur von den Serven, an die die Anfrage weitergeleitet wurde - und dann müssen natürlich in der Antwort auch Zielport und Transaction-ID sowie die DNS-Anfrage (Query) übereinstimmen.

Variante 1: das Reply auf die DNS Anfrage auf den Backup DNS Server wird IMMER verworfen
Variante 2: es wird immer das erste Reply auf die DNS Anfrage weitergeleitet und alle weiteren Replies werden verworfen

Variante 2

Variante 2 kann aus meiner Sicht nur funktionieren, wenn dabei die Quell IP, also der DNS Server, der das Reply schickt, nicht geprüft wird.

wie kommst du denn darauf?

Begründung: Der Listener hört auf einem Port auf eine Antwort von einer spezifischen IP, er kennt keine Liste von IPs und einen Zähler von Requests, auf die es Replies geben könnte.

Auf UDP-Ebene hört der Listener natürlich erstmal nur auf den Port... Sobald ein Paket ansteht, prüft er, ob es akzeptabel (Quell-IP, Quell-Port, Transaction-ID, Query) ist. Wenn nicht, kommt ein port unreachable zurück... Wenn es akzeptabel ist, wird der Listener geschlossen und das Paket an den Client im LAN weitergeleitet

Variante 2 wäre eine CVE, da die Antwort IP nicht beprüft wird

nein, denn die IP wird geprüft - und nich mehr...

Gruß
Backslash

Hi Backslash,

vielen Dank für die klare Erklärung.

Frage 1 : Wenn der Listener nun schon die Info hat, das die Anfrage an zwei verschiedene DNS Serevr geschickt wurde, weil es ja die Anfrage von Client zweimal gab, wenn auch mit derselben Transaktions Nummer, warum schickt LCOS dann die Anfrage nicht auch zweimal an den Client?
Ggf. weil die Transaktionsnummer gleich war und das als dieselbe Aktion betrachtet wurde? Kann eigentlich nicht sein, immerhin wird die DNS Anfrage an unterschiedliche DNS Server geschickt.

Frage 2 : Warum kommt es überhaupt dazu, das der Client den DNS Request mit demselben Quellport und derselben Transaktionsnummer mehrfach schickt?
Das frage ich deshalb, weil ich "gefühlt" lastabhängig genau solche DNS connection refused messages auf WLCs beobachte. Die kommen "aus heiterem Himmel" plötzlich vor und dann ist wieder eine Weile Ruhe.

Deswegen bin ich skeptisch, dieses Symtom mit Ändern des Loglevels zu behandeln, wenn vielleicht noch nicht klar ist, warum das denn wirklich passiert.

Nachdem, was ich beobachte, scheint das aufzutreten, wenn z.b. der WLC mit mehreren WLC Tunneln und / oder der LCOS Internet Router hohe CPU Last haben. Aber eindeutig ist es auch nicht.

Also was führt dazu, das der sendende Client der Meinung ist, das LCOS DNS Modul hat das Paket nicht empfangen und sendet mit derselben Transaktionsnummer nochmal. Zumal wenn wir ja z.B. beim Listenen 30 Sekunden Wartezeit auf Antworten haben.

Hast Du da Infos, welche Betriebssysteme / Geräte das betrifft?

Viele Grüße

ts

[backslash]

Hi tstimper

Frage 1 : Wenn der Listener nun schon die Info hat, das die Anfrage an zwei verschiedene DNS Serevr geschickt wurde, weil es ja die Anfrage von Client zweimal gab, wenn auch mit derselben Transaktions Nummer, warum schickt LCOS dann die Anfrage nicht auch zweimal an den Client?
Ggf. weil die Transaktionsnummer gleich war und das als dieselbe Aktion betrachtet wurde? Kann eigentlich nicht sein, immerhin wird die DNS Anfrage an unterschiedliche DNS Server geschickt.

gleiche Quell-IP, gleicher Quell-Port, gleiche Trabnsaction-ID = gleiche Anfrage - darauf darf es nur eine Antwort geben, zur Vermeidung von DNS-Cache-Poisoning per DNS-Spoofing...
OK, wie sinnvoll das ist, und ob man nicht sowieso gleich auf DNSSec setzen sollte, steht auf einem ganz anderen Blatt...

Frage 2 : Warum kommt es überhaupt dazu, das der Client den DNS Request mit demselben Quellport und derselben Transaktionsnummer mehrfach schickt?

nomalerweise macht das ein Client nur, wenn der Server nicht geantwortet hat - so nach 1..2 Sekunden.
Das LANCOM nutzt diese Wiederholungen, um festzustellen, ob ein Server nicht funktioniert und schaltet bei einer Wiederholung auf den nächsten Server weiter. Nach 5 Minuten wird wieder der erste Server aktiv

Ich hab aber schon Clients gesehen, die die Wiederholung so schnell raushauen, daß kein Server eine Chance hatte zu antworten. Ein solch kaputter Client triggert dann genau die "connection refused" Meldung.

Und nein, ich habe keine Ahnung, warum die Clients das machen - es passiert halt...

Nachdem, was ich beobachte, scheint das aufzutreten, wenn z.b. der WLC mit mehreren WLC Tunneln und / oder der LCOS Internet Router hohe CPU Last haben. Aber eindeutig ist es auch nicht.

Eine hohe CPU-Last erhöht auch die Latenzen - aber daß die soweit erhöht werden, das es mehrere Sekunden duaert, kann ich mir eigentlich nicht vorstellen.
Obwohl: Man kann ein Gerät an einem langsamen Internetanschluß aus dem LAN natürlich so zuballern, daß sich tausende Pakete in der Sendequeue sammeln...

Gruß
Backslash

[plumpsack]

Ignorier den Troll doch einfach. Wenn Ihr Ihm auch noch antwortet kriegt er nur unnoetig Aufmerksamkeit.

Hmm, wie soll ich Dich denn jetzt ansprechen wenn Du, als Admin hier im Forum, mich als Troll bezeichnest?


Ports wie u.A. UDP 389 sind dir bekannt?


Was soll das sein, wenn u.A. jemand von UDP Port :8 extern bei mir auf UDP Port :389 intern zugreifen will?

DNS-Fehler?