Opnsense sendet Traffic an Host in nicht konfigurierten Netz

[diba]

Hallo zusammen,

mit ist durch das IDS der Opnsense aufgefallen, dass die Opnsense mit der IP Adresse des WAN Interfaces Traffic an Port 161 an eine IP Adresse (192.168.5.51) sendet, für die keine IP Netz konfiguriert ist. (siehe Anhang).

Ich habe schon die ganze Konfiguration durchforstet, habe aber nirgends die Ziel IP Adresse gefunden.

Version der Opnsens ist:

OPNsense 23.1.9-amd64
FreeBSD 13.1-RELEASE-p7
OpenSSL 1.1.1t 7 Feb 2023

Eingehende FW Rules oder Port Forwarding am WAN IF sind nicht konfiguriert.

Im LAN werden Unfi Switche betrieben. Aktuell ist nur die FW und ein PC angeschlossen.

Mir ist nicht ganz klar was die Opnsense hier macht. Evtl. hat jemand von euch eine Idee.

Vielen Dank schon mal vorab für die Hilfe.

Gruß

Dirk

[tiermutter]

161 UDP ist SNMP. Mal in dieser Richtung forschen was das ist und evtl. falsch konfiguriert ist...
Im Zweifel mal aufführen welche Dienste Du aktiv hast, die SNMP verwenden könnten.

[diba]

So ich habe mal ein Factory Reset  auf der Opnsense gemacht.

Folgende Dienste laufen:

DHCPv4 für das LAN IF
UNBOUND DNS Server (mit Standard Settings)

Ansonsten laufen keine Dienste.

Im Log sehe ich weiterhin die beschriebenen Meldungen

[tiermutter]

Du bist jedenfalls nicht der Erste... aber vielleicht der Erste der das Problem löst und die Lösung bekannt gibt...
https://forum.opnsense.org/index.php?topic=26239.0

[diba]

jup der von dir genannte Beitrag läuft leider ins Leere. Ich hab mal nen Bug Report auf GitHub aufgemacht.

https://github.com/opnsense/core/issues/6608

[Patrick M. Hausen]

Lass soch bitte mal das tcpdump aus dem anderen Thread laufen. Für alle internen Interfaces, falls du mehrere hast.

[diba]

Hallo zusammen,

ich konnte das Problem fixen. Der TCP Dump hat hier weitergeholfen.

Der ursprüngliche Verursacher des SNMP Request an die IP 192.168.5.51 (Destination aus meine Ursprungspost) ist die Monitoring SW für meinen Brother Scanner. Hier war noch die falsche IP (192.168.5.51) eingetragen.

Nach Korrektur der IP Adresse sehe ich keine Meldungen (wie im Ursprungspost beschrieben) im Firewall LOG.

Die IP Adresse liegt jetzt in einem auf der Firewall konfigurierten Netz.

Ich habe auch mal das Netz 192.168.5.0/24 auf der FW konfiguriert. Dann erhalte ich im LOG die Einträge mit der richtigen Source IP Adresse.

Ist das Netz nicht konfiguriert wird als Source IP Adresse des WAN IF verwendet.

Was mir nicht klar ist warum die Opnsense sich so verhält. Und kann man dieses Verhalten abstellen.

Gruß

Dirk

[Patrick M. Hausen]

Ein interner Rechner schickt aus LAN oder einem anderen lokalen Netz Pakete an 192.168.5.51. Dieses Netz ist lokal nicht vorhanden.

Was erwartest du, dass die OPNsense tut anstatt es zum Default Gateway zu schicken und ausgehend zu NATen?

Die RFC 1918 Netze sind routingtechnisch in keiner Weise speziell. Das ist eine Konvention, dass die nur lokal verwendet werden. Und Provider blocken sie - natürlich. Aber einem Router ist das erst mal völlig egal.

[diba]

Ok das mit der default route in Richtung WAN erklärt das Ganze. Und somit natürlich auch den LOG Eintrag.

Vielen Dank

[meyergru]

Deswegen habe ich folgende Floating-Regel:



Das ist einer der wenigen Fälle, wo eine "out"-Regel mal sinnvoll ist.

[Patrick M. Hausen]

Ich ziehe die Methode per Route vor.

[meyergru]

Stört das nicht die existierenden lokalen Routen?

Unter den Routen heißt es: "Do not enter static routes for networks assigned on any interface of this firewall. Static routes are only used for networks reachable via a different router, and not reachable via your default gateway." - deswegen habe ich mich nicht getraut, das zu nutzen.

Die Firewall-Methode hat den Vorteil, nichts zu ändern, außer, wenn RFC1918-IPs über das WAN nach außen gehen würden, wenn sie vorher nicht irgendwie verarbeitet werden. Letzteres schließt lokale Interfaces inkl. VPN-Routen ein - es bleibt einfach "der Rest" übrig.

[Patrick M. Hausen]

Tut es ja gerade nicht. Routen werden immer nach "longest prefix" ausgewertet. Jedes /24 aus 192.168/16 ist länger. Ebenso jedes /16 aus 172.16/12 oder jedes Subnetz von 10/8.

So macht man das auf Backbone-Routern, wenn man sich den Overhead des Paketfilters sparen will.

[chemlud]

Tut es ja gerade nicht. Routen werden immer nach "longest prefix" ausgewertet. Jedes /24 aus 192.168/16 ist länger. Ebenso jedes /16 aus 172.16/12 oder jedes Subnetz von 10/8.

So macht man das auf Backbone-Routern, wenn man sich den Overhead des Paketfilters sparen will.

...mein lokaler Netzwerk-Nerd hat's mir nochmal erklärt. Sehr coole Sache! :-D

Screenshots or it didn't happen! :-p

[JeGr]

Deswegen habe ich folgende Floating-Regel:



Das ist einer der wenigen Fälle, wo eine "out"-Regel mal sinnvoll ist.

Das ist das, was wir in Workshops auch immer wieder als Regel anführen. Floatings vermeiden (weil kann sonst sehr schnell chaotisch werden), aber eine Floating Regel (oder noch einfacher eine WAN OUT Regel - gleicher Effekt) um RFC1918 Destination zu rejecten mit denen man nichts anfangen kann, macht Sinn.

Route mag ein paar Mü performanter sein Ich mag aber bspw. nicht irgendwas irgendwohin zu routen, wo es nichts zu suchen hat - auch nicht an localhost

Aber bei Backbone Routern die notorisch untermotorisiert sind glaube ich das gern. Bei nem Cisco ASR reichte da schon für 5s das Logging auf Console an zu machen und die Kiste hing im Tilt mit CPU am Ende...