Traffic aus selben VLAN verkehrt nach Gerätewechsel von VM

[Koda]

Ich sehe den Wald vor lauter Bäumen nicht oder stehe komplett auf dem Schlauch.
Ich hoffe ich kann die Situation einigermassen erklären.

Vereinfachte Infrastruktur:
VLANs
9: Management
10: Client
11: IoT

Geräte
Die Firewall und ein Webserver läuft auf Proxmox als VM.
Opensense: VLAN 9
Webserver: VLAN 11
Client 1: VLAN 10 per WLAN
Client 2: VLAN 11 per WLAN

Wenn ich auf den Webserver Port 8080 Zugriff, sehe ich im Log eine Verbindung von meinem Client 1 Gerät auf den Webserver mit Port 8080 als Out Verbindung, beim Client 2 kein Eintrag aber die Verbindung klappt.

Also alles gut.
Nun habe ich den Webserver auf einem Physischen Gerät Installiert und am Switch an das VLAN gehängt.

Mit Client 1 kann ich wie bisher Zugreifen und sehe auch den Logeintrag.

Client 2 welcher sich im selben VLAN befindet macht nun ebenfalls ein Standart Deny. Mich erstaunen dabei zwei dinge:
1. Weshalb ein Deny wenn alle IP Adressen die selben sind. Fahre ich die VM hoch und schalte den Physischen aus geht alles.
2. in der Deny Rule sehe ich nun eine In Verbindung. Source ist dabei mein Webserver, und Destination ist mein Client 2.

Es ist klar das es wohl ein Konfigurationsfehler sein muss, verstehe aber nicht wo suchen da es mit der VM geht und die Netzeinstellungen gleich sind.

[viragomann]

Client 2 welcher sich im selben VLAN befindet macht nun ebenfalls ein Standart Deny. Mich erstaunen dabei zwei dinge:
1. Weshalb ein Deny wenn alle IP Adressen die selben sind. Fahre ich die VM hoch und schalte den Physischen aus geht alles.
2. in der Deny Rule sehe ich nun eine In Verbindung. Source ist dabei mein Webserver, und Destination ist mein Client 2.

Klick mal auf das "i" rechts im Log Eintag, um die Details anzuzeigen und schaue, welches Flag das Paket hat.
Ich vermute, es ist nicht SYN. Das würde auf asymmetrischen Routing hindeuten.

Als erstes würde ich dann die Netzwerkkonfiguration des Webservers kontrollieren, speziell die Subnetzmaske.

Und dann noch die VLAN Konfiguration der involvierten Geräte (Switch). Da könnte ein Leck sein.

[Koda]

Hallo

Danke für deine Antwort.

Das Paket hat die folgenden Flags
ipflags   DF
tcpflags   SA

>>speziell die Subnetzmaske
Und gena das war es auch. Vielen Dank. Diese war aus einem unerfindlichen Grund auf 255.255.255.255

[Patrick M. Hausen]

TCP-Flags SYN/ACK bedeutet das ist das zweite Paket und damit das erste Antwort-Paket in einem initialen Three-Way-Handshake. Offensichtlich hat die Firewall das initiale SYN vom Client an den Server nicht gesehen.

Das kann an asymmetrischem Routing liegen. Wenn der Client den Server direkt erreicht, der Server aber meint, die Antworten über die Firewall schicken zu müssen, dann passiert sowas.

[viragomann]

Wie erwähnt, überprüfe die Subnetzmaske des Webservers.
Offenbar meint dieser, dass die Client IP außerhalb seines Subnetzes liegt und schickt die Antwort and das Default Gateway, also OPNsense. Die weiß damit aber keine passende Verbindung dafür, weil das zugehörige SYN-Paket nicht darüber gelaufen ist.

[Koda]

Danke euch. Sorry mein Edit war wohl zu spät :)

>>speziell die Subnetzmaske
Und gena das war es auch. Vielen Dank. Diese war aus einem unerfindlichen Grund auf 255.255.255.255