Netzwerkproblem

[uwe-beach]

Hallo,

ich nutze OPNSense 26.7.1 mit folgender Netz-Konfig :

Fritzbox (192.168.177.1) --> OPNSense WAN (192.168.177.2) --> OPNSense LAN (192.168.178.1)
In der OPNSense ist ein weiteres Interface mit Namen Backup (192.168.180.2) definiert.

Von einem TrueNas-Gerät (192.168.180.10) komme ich nicht auf das LAN-Interface und dadurch auch nicht auf Geräte im LAN.
Für das Interface Backup gibt es eine Regel, mit Source 'Backup Network', Destination 'LAN-Network', Protocol TCP, alle Ports auf ANY.

Ausgabe eines traceroute auf dem Truenas :

traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  192.168.178.1 (192.168.178.1)  0.133 ms  0.102 ms  0.054 ms

traceroute 192.168.178.100
traceroute to 192.168.178.100 (192.168.178.100), 30 hops max, 60 byte packets
 1  192.168.180.2 (192.168.180.2)  0.120 ms  0.095 ms  0.100 ms

Ein ping, ausgeführt auf dem OPNSense-Interface Backup (192.168.180.2), auf eine IP aus dem LAN funktioniert.
Ein ping vom Truenas auf das LAN-Interface funktioniert nicht.
Von der Truenas kommt man ins Internet.


Hat jemand eine Idee ?

[viragomann]

Hallo,

Ausgabe eines traceroute auf dem Truenas :

traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  192.168.178.1 (192.168.178.1)  0.133 ms  0.102 ms  0.054 ms

Könnte es sein, dass du dein NAS multi-homed betreibst? Also dass es in beiden Subnetzen eine IP hat.

Eigentlich würde ich mir erwarten hier als ersten Hop die Gateway IP des NAS zu sehen, also 92.168.180.2.

Ein anderer möglicher Grund könnte ein Layer 2-Leck zwischen den beiden Netzwerksegmenten sein.
Einfach nachzuweisen, indem du am NAS die ARP-Tabelle anzeigst. 192.168.178.1 dürfte da nicht aufscheinen, wenn es in Ordnung ist.

[uwe-beach]

Das NAS ist nur im Netz 192.168.180.0/24.
Die Arp-Tabelle sieht so aus :
arp -a
? (192.168.180.2) at c4:00:ad:ba:27:55 [ether] on enp1s0

[viragomann]

D.h. vermeintlich alles in Ordnung.
Warum dann Traceroute als erstes eine IP im anderen Subnetz hinter dem Router ausgibt, ist mir nicht klar.

Für das Interface Backup gibt es eine Regel, mit Source 'Backup Network', Destination 'LAN-Network', Protocol TCP, alle Ports auf ANY.

Okay, bevor du weitersuchst, mache erst mal die Regel weiter auf. Erlaube alle Protokolle, dann versuch es mit einem Ping oder Traceroute.

Wenn nur TCP erlaubt ist, kommen Pings (ICMP) nicht drüber.
Auch würde ich Source und Destination zur Fehlersuche auf any setzen. Wenn du bspw. eine falsche Subnetzmaske gesetzt hättest, könnte Quelle oder Ziel aus dem Netzwerk fallen.

Wenn dann immer noch nichts geht, mach ein Packet Capture, erst am eingehenden Interface, wenn ok, am ausgehenden. Kommt da schon gar nichts rein oder auch das Richtige raus, kannst du OPNsense als Fehlerursache ausschließen.

[trixter]

Kurze Info:

Das Netz 192.168.178.x ist das Default-Netz jeder Fritzbox.
Daher ist es nicht ratsam genau dieses "extern" zu verwenden.

[drosophila]

Genau so verhielte es sich, wenn auf TrueNAS die Subnetzmaske nicht /24, sondern /16 wäre. Allerdings müßte sich die Sensebox dann für den ersten Traceroute auch bei den LAN-Adressen auf dem Backupnetz angesprochen fühlen, was zwar nicht sein sollte, aber ggfs. trotzdem sein könnte (ARP). So sähe es aber auch aus, wenn die Sensebox alle Pakete vom Backupnetz ins LAN stattdessen an sich selber umleitete, was dann ein Routenproblem wäre.

[knebb]

Moin,

an dem Setup ist nichts falsch- fast keiner der bisherigen Antwortenden hat das erkannt.

1. Die Regel erlaubt nur TCP. `tcpdump` ist aber UDP. Und `ping` ist ICMP. Kann nicht gehen, werden beide auf dem Hinweg blockiert.
2. Der erste `tcpdump` auf das LANGw der OpnSense ist erfolgreich, weil die Sense das Paket zuerst einmal als "eingehend" erkennt (und nicht als weiteleiten an LAN) und bereits antwortet, bevor die Regeln angewendet werden. Das liegt daran, dass sie selbst ja das LLAN-Gateway ist und damit ist ihr auch egal, in welchem Netz das LAN-Gw hängt. DEshalb antwortet sie auch mit ihrer LAN-IP. ISt also auch richtig soweit.
 3. Die IP-Ranges (/24er Maske angenommen) passen, auch wenn das LAN das normalerweise verwendete LAN der Fritz! ist. Sofern das sauber durchkonfiguriert ist, gibt es keinen Grund, das nicht zu werwenden.


Also: Regel um TCP&ICMP ergänzen, dan nerneut testen. Sollte eigentlich danach schon funktionieren.

[viragomann]

an dem Setup ist nichts falsch- fast keiner der bisherigen Antwortenden hat das erkannt.

Auf Basis der hier vorliegenden Informationen über das Setup würde ich das nicht beschwören. Diese lassen noch viel Spielraum für eventuelle Fehler.

Die Regel erlaubt nur TCP. `tcpdump` ist aber UDP. Und `ping` ist ICMP. Kann nicht gehen, werden beide auf dem Hinweg blockiert.

Wenn du den Thread aufmerksam gelesen hättest, hätte dir auffallen müssen, dass ich bereits darauf hingewiesen hatte.

Der erste `tcpdump` auf das LANGw der OpnSense ist erfolgreich, weil die Sense das Paket zuerst einmal als "eingehend" erkennt (und nicht als weiteleiten an LAN)

Es geht hier um Tracerout. Vermutlich aber nur eine Verwechslung und dann dennoch gut erkannt. Die erste Antwort liefert der nächste Router, aber...

Das liegt daran, dass sie selbst ja das LLAN-Gateway ist und damit ist ihr auch egal, in welchem Netz das LAN-Gw hängt. DEshalb antwortet sie auch mit ihrer LAN-IP. ISt also auch richtig soweit.

Hast du da noch eine verständlichere Erklärung, bitte?

Aber wie auch immer, für den TO kommt sie vermutlich zu spät. Der hat offenbar schon vor mehr als 2 Wochen das Interesse an dem Thread verloren. Wahrscheinlich hat sein Problem längst gelöst, aber kein Interesse, die Lösung hier zu teilen. :-)

[knebb]

Moin,

Du hast recht, ich bin in manchen Bereichen über's Ziel hinausgeschossen. Und ja, es war `traceroute`gemeint, nicht `tcpdump`. Mein Fehler.

Und ja, der OT ghostet uns wohl- aber deshalb hatte ich das ja auch noch ergänzt. Um die (ziemlich sichere) Lösung für das Problem zu posten.

/KNEBB