Coova + IPFire: IP wird blockiert, die es nicht geben dürfte

Hallo.
Nochmal eine Rückfrage zum Coova bzw zum IPFire. Hier tauchen im IPFire wiederholt seltsame Meldungen auf. Ich habe da IP-Adressen drin, die es hier gar nicht geben dürfte :fearful:

Konkret sieht das so aus:


Dabei ist die 172er Adresse der coovachilli. Die Ziel-Adresse bzw dieses Subnetz benutzen wir hier aber gar nicht. Ich frage mich jetzt natürlich, wie ich das eingrenzen kann? Die Meldungen kommen nur aus blau (WLAN) – zudem sind da um diese Zeit alle AccessPoints abgeschaltet, so dass die Anfrage offenbar wirklich direkt vom Coovachilli stammen muss. Schaut man sich die Ports an, findet man:

 "Ports used for Captive Portal: 
6080 for NT LAN Manager (NTLM) authentication, 
6081 for Captive Portal in transparent mode, and 
6082 for Captive Portal in redirect mode."

Gefunden habe ich auf dem coova lediglich die Datei

/etc/freeradius/modules/ntlm_auth

Die IP-Adresse aus dem 192er Netz konnte ich aber nirgendwo auf dem coova finden. Habt ihr das bei euch auch drin? Ich wüsste ja doch gerne, welche Ziel-Adresse das sein soll – oder ob da ggf. ein Gerät irgendwo hängt, das falsch konfiguriert ist?!

Hallo Michael,

Konkret sieht das so aus:

https://ask.linuxmuster.net/uploads/default/original/1X/845612a411f4dfd0bc7179bb52ee082f2c2206f0.png

Dabei ist die 172er Adresse der coovachilli. Die Ziel-Adresse bzw dieses
Subnetz benutzen wir hier aber gar nicht.

… das sieht aber nach dem WLAN Netz aus?
Welches Netz nutzt ihr da?
Welche Netzwerkmaske?

Ich frage mich jetzt
natürlich, wie ich das eingrenzen kann? Seltsamerweise kommen die
Meldungen /nur/ aus blau/WLAN – zudem sind da um diese Zeit alle
AccessPoints abgeschaltet, so dass die Anfrage offenbar wirklich
/direkt/ vom Coovachilli stammen muss. Schaut man sich die Ports an,
findet man:

|„Ports used for Captive Portal: 6080 for NT LAN Manager (NTLM)
authentication, 6081 for Captive Portal in transparent mode, and 6082
for Captive Portal in redirect mode.“|

Habt ihr das bei euch auch drin? Ich wüsste ja doch gerne, welche
Ziel-Adresse das sein soll – oder ob da ggf. ein Gerät irgendwo hängt,
das falsch konfiguriert ist?!
zu welcher Netzwerkkarte gehört den die MAC?

LG

Holger

Die üblichen Schwierigkeiten bei der Namensgebung in Blau: der coova-chilli ist alleine in Blau und hat die o.g. Adresse. Er dient als Gateway für alle Clients im WLAN, die bei uns im Bereich 172.20.x.y liegen.
Ich kann auch anhand der MAC-Adr bestätigen, dass die geblockte Anfrage von oben der coova-chilli ist.
Mir ist aber nicht klar, wie da diese IP im 192.168.118er Netz rein kommt. Unter /etc ist nichts dergleichen zu finden. Und ob NTLM für den Betrieb überhaupt notwendig ist, ist ebenfalls offen :slight_smile:

Hallo Michael,

Die üblichen Schwierigkeiten bei der Namensgebung in Blau: der
coova-chilli ist alleine in Blau und hat die o.g. Adresse.

… das war mir schon klar.
Aber er ist eben auch ein Router, und wenn etwas aus dem „AP Netz“
kommendes nicht in sein Subnetz paßt, dann routet er das weiter.

Er dient als
Gateway für alle Clients im WLAN, die bei uns im Bereich 172.20.x.y liegen.

das wollte ich wissen: es hätte ja sein können, dass es innerhalb eures
„Clientnetzes“ liegt.

Ich kann auch anhand der MAC-Adr bestätigen, dass die geblockte Anfrage
von oben der coova-chilli ist.

gut: also ist es wahrscheinlich,d ass da außerhalb etwas sitzt, was
diese Anfrage startet.

Mir ist aber nicht klar, wie da diese IP im 192.168.118er Netz rein
kommt. Unter /etc ist nichts dergleichen zu finden. Und ob NTLM für den
Betrieb überhaupt notwendig ist, ist ebenfalls offen :slight_smile:

meine Vermutung: es ist einer deiner Accesspoints, der da versucht
irgend was ab zu fragen.

Du hast geschrieben, dass das auch auftritt, wenn die APs „Funkstille“
haben: wie machst du das?
Werden die vom Strom getrennt?
Oder haben die alle intern eine WLAN Uhr aktiviert?

Sind die alle vom selben Hersteller?

Jetzt solltest du in den logs des Coova schauen, wo die Anfrage den her
kam: so bekommst du vielleicht eine MAC und die kannst du dann mal suchen.
Am Ende ist es vielleicht doch ein Printserver der an einer Blauen Dose
hängt oder es ist einer der Switches im Blauen Netz.
Hast du nicht mit SNMP rumgemacht?
Kann das nicht auch gegen Windowsserver aktivieren?

LG

Holger

Also unsere APs schalten sich alle am Wochenende um nachmittags ab. Da läuft nichts mehr (von Unifi). Ansonsten gibt es da auch keinen anderen AP (von unifi). Wenn da jemand einfach irgendwo einen “wilden” AP aufgehängt hat, müsste der ja im Netzwerk auffindbar sein?? Wenn er tatsächlich eine 192.168.118er Adresse hat, kann er ja mit dem Rest nicht kommunizieren und wäre eh zwecklos…
Mich wundert der Port 6080 weiterhin. NTLM? Braucht man das wirklich??

Was die Herkunft des Paketes angeht: ich denke weiterhin, dass der Coova selbst die Anfrage schickt. Eine derartige Adresse hat er aber wie gesagt nicht konfiguriert.

Was SNMP angeht: nur im Switch-Netz (VLAN.2). Das ist von diesem hier völli getrennt. Ich habe es auch nur auf den Switches und dem linuxmuster-Server aktiviert.

Die APs schalten sich übrigens über mPower-Steckdosen ab. Die sind alle ebenfalls eindeutig über eine IP im 172.20er Netz erreichbar. Wildwuchs gibt es da also meines Wissens nicht…