Netzwerkdrucker - Drucken von einem VLAN in ein anderes funktioniert nur bedingt

[Tanduvil]

Hallo allerseits,

ich habe eine Jetway-Appliance mit OPNsense laufen. Auf selbiger habe ich zwei VLANS eingerichtet, mit folgender Konfiguration:

VLAN 100 auf igb1, Netzwerk 192.168.100.0/24, DNS ist 192.168.100.253
Gerät ist ein PC mit Windows 10 Pro, Rechner-IP: 192.168.100.100,
Gateway und DNS sind die 192.168.100.253, Internetzugang funktioniert.

VLAN 110 auf igb2, Netzwerk 192.168.110.0/24, DNS ist 192.168.110.253
Gerät ist ein Brother HL-L2370DN Netzwerkdrucker (RJ45-Buchse), Printer-IP: 192.168.110.110,
DNS und Gateway ist die 192.168..110.253, gedruckt werden soll über das RAW-Protokoll, ist im Druckertreiber des PC so angegeben. Gateway wollte ich erst gar keins einrichten, damit das Ding nicht rausfunken kann, aber dann geht überhaupt nichts. So habe ich ihm nur den Kontakt zum DNS und zum PC erlaubt, alle anderen privaten Netze als auch alle öffentlichen sind geblockt.

Beide Geräte stecken an einem Cisco SG250-08HP, einem 8 Port-Management-Switch:
An Port 1 (dem VLAN 100 zugeordnet) steckt der Rechner, an Port 2 steckt der Drucker, dieser Port ist dem VLAN 110 zugeordnet. Beide sind Access-Ports.

Ich habe in der Firewall des VLANS 100 folgende Ports für das VLAN 110 freigegeben:
TCP: 9100 TCP (Raw), 445
UDP: 137, 138, 139, 161, 162

Das Kuriose: Der Drucker druckt ordnungsgemäß, wenn ich von VLAN 100 nach 110 alle TCP/UDP Ports freigebe (any)
Gebe ich die o. g. Ports an, nimmt der Drucker den Job entgegen, wartet ca. 3 Minuten, danach werden 2 Exemplare des Dokuments gedruckt, jedoch nicht vollständig (ca. eine Vierteilseite).

Mein erster Weg war in die Firewall Protokoll-Live-View um zu sehen, welche Pakete auf welchen Ports von VLAN 100 nach 110 gehen, wenn ich einfach alles durchlasse. Aber es gehen nur 9100 TCP, also Raw, und 53 UDP, also DNS vom Rechner zum Drucker.

Ansonsten läuft noch Zenarmor (Sensei) auf der OPNsense, das wurde temporär deaktiviert, bis der Fehler klar ist.

Habt ihr irgend eine Ahnung, woran das liegen kann? Der Drucker wurde gelöscht und re-installiert.

Hab die letzten zwei Tage nach der Ursache gesucht und bin quasi fast ergraut .

Lieben Dank und Grüße,
Christian

 

[honky-tonk]

evtl kommuniziert der drucker auch zurück zum sender und das kommt nicht durch?!

 

[Tanduvil]

Vielen Dank für die Antwort. Ich habe dem Printer zum Rechner auch schon die genannten Ports freigeschalten. Sorry, hatte ich vergessen, zu erwähnen. Da hat sich auch nichts geändert.

Wenn alles vom Rechner zum Drucker offen ist, und dem Drucker nur DNS gestattet wird, funktioniert alles.

 

[Raijin]

Ich habe dem Printer zum Rechner auch schon die genannten Ports freigeschalten. Sorry, hatte ich vergessen, zu erwähnen. Da hat sich auch nichts geändert.

Das ist aber nicht entscheidend. Eine Netzwerk-/Internetverbindung hat stets 2 Sets an IP+Port, und zwar Quelle und Ziel. Ziel ist hierbei die 192.168.110.110 : 9100 (TCP) und die Quelle ist 192.168.100.100 : {der dynamische Quell-Port, den Windows ausgesucht hat}

Im Klartext: Der PC schickt das Dokument an TCP 9100, aber er schickt es nicht von TCP 9100, sondern mutmaßlich von TCP 49152-65535 und dahin müsste der Drucker die Antwort schicken, nicht an TCP 9100.

Also zB so:

PC (TCP 54321) -----------> (TCP 9100) Drucker
und
PC (TCP 54321) <----------- (TCP 9100) Drucker

Aus diesem Grunde gibt es in Firewalls mit connection tracking den connection state "established", der im Prinzip alle Antwort-Ports von erfolgreich hergestellten Verbindungen umfasst, egal welche Nummer sie haben, da Windows den Absendeport dynamisch wählt (49152 - 65535), wenn die Anwendung nicht explizit einen Absendeport anfordert.

Wenn alles vom Rechner zum Drucker offen ist, und dem Drucker nur DNS gestattet wird, funktioniert alles.

Das wiederum impliziert, dass der Rückweg nicht das Problem ist - evtl gibt es ja bereits eine established-Regel oder die Firewall ist in die andere Richtung (VLAN 110-->100) generell offen. Es deutet allerdings darauf hin, dass ein Port vom PC in Richtung Drucker noch fehlt. Hier gilt es also, das Logging bzw. mittels Packet capture zu prüfen, was genau denn nun fehlschlägt. Das kann trotzdem die Antwort vom Drucker an den PC betreffen, je nachdem wie du nun in der Firewall die vermeintlichen Regeln für den Drucker konkret definiert hast.

 

[Tanduvil]

Hammer, vielen Dank für eure Antworten!! @Raijin , vielen Dank für deine Zeit und deine detaillierten Erklärungen, ich werde es mir morgen früh gleich mit frischem Geiste ansehen!

Wünsche euch einen gute Nacht

 

[Crazyhorse]

Druckertreiber wollen oft noch den Tinten/Tonerstand ermitteln also SNMP ist hier dann oft mit dabei. TCP-UDP/161, schaue mal ob es im FW Log aufläuft.
Was die zerstückelten Dokumente angeht, hier würde ich mal beim Treiber ansetzen.
Gibt es da ggf. einen Universaltreiber?

 

[Tanduvil]

Hallo allerseits,

nun hat es doch ein wenig länger gedauert. Ich hatte nun endlich Zeit, das packet capture auf der OPNsense durchzuführen und habe das Ergebnis mit Wireshark ausgewertet. Alle TCP/UDP Ports zwischen dem Rechner- und dem Druckernetz waren beim Mitschnitt in der Firewall offen.

Der Mitschnitt des Drucker-Interfaces als auch des Rechner-Interfaces an der OPNsense ergab:

- die Kommunikation vom Rechner zum Drucker lief nur über RAW (9100 TCP). Keine UDP-Ports, keine anderen TCP Ports waren involviert.

- Fehlermeldung in den Capture-Daten des Rechner-Interfaces, von der OPNsense DNS/Gateway IP 192.168.100.253/24 zur Rechner:-IP 192.168.100.100/24 :
"TCP Out-Of-Order", das kommt ca. 10 mal, und in der letzten Zeile steht "TCP Retransmission"

- Selbige Fehlermeldung bekomme ich in den Capture-Daten des Drucker-Interfaces angezeit, von der Rechner-IP 192.168.100.100/24 zur Drucker-IP 192.168.110.110/24, jedoch ohne das "TCP Retransmission".

Wenn ich in der Firewall nicht mehr alles zwischen den Netzen offen lasse, sondern die Kommunikation auf die o. g. Ports beschränke (es wird ja auch nur auf RAW/9100 TCP kommuniziert), dann hat er ein Problem und druckt nicht. Falls jemand einen Denkanstoß hat, woran es liegen könnte, wäre ich sehr dankbar.

LG
Christian

 

[Raijin]

Ich verweise nochmal auf #4. Es ist eben nicht nur TCP 9100 involviert, weil das lediglich der Port am Drucker ist und eben nicht der Port am PC. Wenn du Witeshark mal genau betrachtest, müsstest du eigentlich sehen, dass der Absende-/Quell-/Antwort-Port auf der IP des PC ein anderer ist und tendenziell auch bei jedem Druck um +1 erhöht wird. Dieser Port muss in Richtung PC in der Firewall offen sein.

Da es sich jedoch um einen dynamischen Port handelt, der sich bei jeder Verbindung ändert, muss wie beschrieben eine ESTABLISHED/RELATED Regel in der Firewall definiert werden. Damit gibt die Firewall stets genau jenen dynamischen Port frei, der bei Verbindungsaufbau als Quell-Port verwendet wurde.



Eine typische Firewallkonfiguration sieht daher so aus:

1. drop invalid
2. accept established/related
3. accept dst port x
4. accept src ip y
5. drop all

Damit werden "kaputte" oder bewusst falsch konstruierte Pakete gleich als erstes geblockt bzw. ignoriert (zB auch bestimmte Netzwerkattacken), anschließend die Antwort-Ports bestehender Verbindungen erlaubt, bestimmte Ports bzw. IPs explizit zugelassen, während als letztes der gesamte Rest, der bisher noch nicht erlaubt wurde, ignoriert wird.

Wenn man hingegen ausschließlich Regel 3 und 5 einstellt, wobei letztere nicht zwingend als autarke Regel existiert, sondern ggfs als default policy der Firewall deklariert wird, geht eben nur der Port TCP 9100 Richtung Drucker, aber die Antwort bleibt in der Firewall hängen, weil sie zB an TCP 51532 geschickt wird und dementsprechend im default drop landet.

 

[Tanduvil]

Hallo @Raijin , vielen Dank mal wieder!

So wie von Dir für 1 und 2 beschrieben kenne ich das z. B. vom Ubiquiti Edgerouter X, die OPNsense bietet das in dieser Form, soviel ich weiß, nicht.

3 und 4 kann in einer Regel unterbringen, 5 sollte mit dem Implicit Drop der OPNsense auch greifen. Ich kann aber auch sicherheitshalber nochmal alles explizit droppen.

Ja, der Rechner öffnet einen High-Port zum Drucker, so um die 54000. Ist jedesmal ein anderer. Das darf er auch (Rechner TCP * auf Drucker TCP 9100).

Nun werde ich mal suchen, wie ich die Punkte 1 und 2 mit OPNsense realisieren kann.

Danke und Grüße,
Christian

 

[Raijin]

Das war auch nur ein Beispiel wie ein Regelset aussehen kann. Ich bin zZt im Urlaub und habe keinen Zugriff auf eine meiner *sense-Boxxen daheim, kann daher nicht nachschauen. Es kann allerdings sein, dass OPNsense diese Regel implizit hinzufügt.

Es kann durchaus einen Unterschied machen ob man direkt in iptables/nftables arbeitet oder mit einem Frontend, sei es zB UFW oder eine GUI. In letzteren werden häufig nur benutzerdefinierte Regeln angezeigt, nicht aber die impliziten Regeln im Hintergrund. In solchen Systemen werden üblicherweise zahlreiche Chains in iptables angelegt und es kann sein, dass nur einige davon in der GUI dargestellt werden. Das ist bei EdgeRoutern nicht anders. Nutzt man bei EdgeOS den Wizard für Portweiterleitungen, legt EdgeOS die Regeln für NAT+Firewall in für die GUI unsichtbare Chains an.

Wenn ich in der Firewall nicht mehr alles zwischen den Netzen offen lasse, sondern die Kommunikation auf die o. g. Ports beschränke (es wird ja auch nur auf RAW/9100 TCP kommuniziert), dann hat er ein Problem und druckt nicht. Falls jemand einen Denkanstoß hat, woran es liegen könnte, wäre ich sehr dankbar.

Aber du musst doch sehen welche Pakete konkret nicht mehr im tcpdump auftauchen, wenn du die Firewall aktivierst. Also 1:1 Vergleich zwischen Druckbefehl ohne Regeln/alles erlaubt und Druckbefehl mit aktiver Firewall. Das was bei letzterem im dump fehlt, ist das was geblockt wird.


Die TCP out of order / retransmission deuten im übrigen auf ein weiteres Problem hin. Üblicherweise tritt das dann auf, wenn es mehrere Pfade zwischen Quelle und Ziel gibt und einige Pakete einen längeren Weg nehmen. Eigentlich ist das durch die SequenzNr der Franes kein großes Problem, aber wenn das sehr häufig passiert, liegt irgendwas im Busch...


Was du abseits der Versuche mit der Firewall und direktem Zugriff auf den Drucker noch testen kannst, wäre ein DNAT, also eine Portweiterleitung. Am PC würdest du den Drucker dann mittels der IP der OPNsense anbinden und nicht mehr mit der Drucker-IP aus dem anderen VLAN. Ist nicht schön, aber wenn es anders nicht hinhaut, ist es eben so.

 

[Tanduvil]

Vielen Dank für die Tipps und dass Du aus Deinem Urlaub antwortest. Ich werde die Dumps nochmal machen und den Detail-Level hochschrauben und sie nochmals vergleichen.

Grüße

 

[Bob.Dig]

So habe ich ihm nur den Kontakt zum DNS und zum PC erlaubt,

Das ist bei einem Drucker nicht nötig, weder zum PC noch wird DNS benötigt.