Fehler: sonewconn

[esquire1968 0]

Hallo zusammen!

Habe plötzlich unzählige Log-Einträgen wie diesen:

sonewconn: pcb 0xfffff80120006cb0: Listen queue overflow: 193 already in queue awaiting acceptance (3646 occurrences)

Was bedeutet das. Ich habe bis dato nichts gefunden.

Danke vorab.

Gruß
Thomas

[JeGr]

@esquire1968-0 said in Fehler: sonewconn:

sonewconn

Wenn die Meldung auftaucht, feuer mal ein

netstat -Lan

auf der Konsole ab und zeige den Output.

[esquire1968 0]

Bitte sehr.

LG
Thomas

[JeGr]

Was auch immer bei dir auf 8443 läuft, es haut mit zu viel Verbindungen drauf -> 193 / 128 ist ein ... bisschen ... zu viel ;)

Du kannst ggf. wenn das so sein "muss" den Wert

kern.ipc.somaxconn

in den adv. Settings auf 256 oder 512 erhöhen um das abzufangen. Aber wenn das bspw. pfBlockerNGs Website ist, dass eine Seite geblockt wurde, würde ich mich eher fragen, warum da fast 200 offene Verbindungen draufhageln.

[esquire1968 0]

Vielen Dank für die Aufklärung!

Ich habe ein Update von pfBlockNG auf die ‚devel‘ Version gemacht und damit war der Fehler behoben. Jetzt schaut der Output so aus:

tcp4 3/0/128 *.8443
tcp4 0/0/128 *.8081

Beste Grüße
Thomas

[JeGr]

Hört sich fast so an, als ob da die Verbindungen zum Dummy Webserver für die "Stop" Seite offen geblieben sind. IMHO würde ich selbst aber eher umleiten auf 0.0.0.0 statt auf eine IP und dann eine Seite anzeigen, da das bei HTTPS eh schon in die Hose geht - außer du bist in einem kleinen Netz oder kannst Firmenweit deine eigene CA ausrollen. TLS aufbrechen ist aber eh schon eine miese Nummer und bevor sich die Leute dann beschweren weil bei https://bad-domain.tld dann eine SSL Warnung kommt bevor dann die Stopseite kommt leite ich die lieber auf 0.0.0.0 -> was von DNS als sofortiger Error/unauflösbar quittiert wird und somit auch keine Timeouts oder Nachladezeiten verursacht :)

[esquire1968 0]

OK. Wie leite ich auf 0.0.0.0 um?

[esquire1968 0]

Zu früh gefreut! Trotz neuer pfBlockNG Version ist der Fehler wieder da.

tcp4 193/0/128 *.8443
tcp4 46/0/128 *.8081

Gruß,
Thomas

[esquire1968 0]

Wenn ich als virtuelle IP-Adresse 0.0.0.0 stat 10.10.10.1 einstelle, startet DNSBL nicht mehr. Das funktioniert nicht.

Irgendeine Idee wie ich den Fehler wegbekomme?

Gruß
Thomas

[JeGr]

Dann hast du mich mißverstanden. Ich meine nicht die VIP auf 10.10.10.1 zu setzen, das bringt nichts, denn die ist nur dazu da, den Webserver dran zu binden und diese Error Seite auszuliefern. Ich rede davon gar nicht erst die Fehlerseite auszuliefern bzw. den Webkram ganz abzuschalten und als DNS Antwort 0.0.0.0 zu liefern, nicht den Webserver auf 0.0.0.0 zu binden :)

Um eine Domain zu blackholen musst du im entsprechenden Listeneintrag beim DNSBL unter dem Abschnitt "Settings" das Logging auf "disabled" setzen (dort steht auch die Erklärung, dass disabled die Adresse auf "0.0.0.0" setzt statt auf die VIP).
Dann gibt es natürlich keine Log Hits mehr auf der Firewall weil der Client dann direkt schon die Anfrage einstellt statt eine Verbindung mit der Firewall aufzubauen.

[esquire1968 0]

Danke für Antwort! Ich finde die Einstellung nicht - sorry!

Ich kann unter "Firewall / pfBlockerNG / DNSBL im Abschnitt DNSBL IPs Logging ausschalten - da steht aber die angeführte Erklärung nicht!

[JeGr]

Ah Okay, du schaust an der falschen Stelle. Gehe in den Reiter DNSBL Feeds -> Dort gibts als letzte Spalte "Logging" und schalte das auf disabled. Wenn du den Feed editierst (ganz unten) findest du die Option und Beschreibung auch nochmal:

Ich habe allerdings auch pfBlockerNG-devel installiert, falls das ein Unterschied sein sollte.

Grüße
Jens

[esquire1968 0]

OK, alles klar jetzt hab ich es. D. h. ich muss dieses Setting für jede „DNSBL Source Definition“ machen!?

Beste Grüße
Thomas

[JeGr]

Was meinst du für jede? Wenn du im Feed Summary (erstes Bild) bist, kannst du einfach alle Feeds auf Disabled im Dropdown stellen, Save drücken und gut :) Wenn du aus dem Category Tab (UT1 oder Shalla) noch was hast, dann dort ggf. auch. Sollte aber fix gehen.

[esquire1968 0]

Alles klar! Dachte ich muss auf jeden Eintrag gehen - es genügt ja auch überall bei Logging disable einzutragen.

Leider zeigt "netstat -Lan" wieder offenen Verbindungen auf Port 8443 an und die Zahl steigt laufend an.

Kann das auf ein falsches Setting im Resolver zurückzuführen sein?

[JeGr]

Der Resolver hat eigentlich keinerlei Aktien an der Umleitung an Port 8443. Du solltest aber - wenn du in allen DNSBL Regeln das "Logging" abgeschaltet hast ggf. auch die NAT Redirection Regeln auf diese Ports löschen bzw. abschalten. Da müssten es als Outbound NAT auf dem LAN IF ja Regeln geben, die abgehenden Traffic dann auf die im Blocker hinterlegte IP Adresse und 8080/8443 redirecten. Ansonsten wäre es seltsam, wie die Clients überhaupt darauf kommen, dahin eine Verbindung aufzubauen.

Grüße

[esquire1968 0]

Hi und nochmals danke!

Ich kann unter NAT / Port Forward die beiden Regeln löschen bzw. deaktivieren.

Unter NAT / Outbound sind für WAN die beiden Ports unter ‚Automatic Rules‘ hinterlegt, die kann ich nicht ändern. Gibt es eine Möglichkeit pfBlockerNG daran zu hindern diese anzulegen.

Wozu dienen diese Einstellungen wenn durch Ausschalten des Logging ohnehin nicht auf 10.10.10.0 sondern 0.0.0.0 umgeleitet wird?

Gruß
Thomas

[JeGr]

Müsste ich nochmal nachsehen ob man das Redirecting ganz abschalten kann. BBCan ist da sehr eifrig dabei, Funktion einzubauen aber schießt manchmal ein wenig übers Ziel hinaus. Die ganze VIP Definition finde ich suboptimal. Für ein Single System geht es, im Cluster wenig schön. Muss ich mal sehen, eigentlich sollte man das abklemmen können.