Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Windows 11 Domain Logon bei 2 Minuten im VLAN ..

Hallo,

ich habe hier ein seltsames Phänomen.

In einer Windows Domain (192.168.2.0/24, Zone LAN) braucht ein Windows 11 Client für den User Logon zwischen 2-3 Sekunden.
Nun habe ich ein VLAN3 (172.17.3.0/24) mit der ZONE VLAN3 erstellt, der DHCP Server im VLAN3 vergibt die IP´s und die DNS Server aus der Zone LAN.

Sobald sich jetzt der User am Windows 11 Client anmeldet, dauert die Anmeldung etwa 2 Minuten, danach sieht alles gut aus.

Ich hab in der XG 19.5.1 über die CLI ein drop-packet-capture 'dst host 172.17.3.25' und ein  drop-packet-capture 'src host 172.17.3.25 gesetzt.
Blockiert wird hier nichts, es scheint als ob der Traffic über andere F/W Regeln geführt wird oder ähnliches.

Da ich hier eine neue Zone VLAN3 gewählt habe, gehe ich davon aus, das in keiner anderen Regel Traffic 'abgegriffen' wird.

Die VLAN3 Regeln wie folgt.

Gibt es hier eine Option in der CLI oder im Log Viewer zu sehen, wie der Traffic geroutet wird?

Ich hatte auch ein tcpdump erstellt und sehe sehr viele 

  • tcp retransmission
  • DUP ACK
  • RST ACK

Danke schon mal im Voraus...



This thread was automatically locked due to age.
Parents
  • Kannst du alles andere ausschließen?
    Ich hatte so ein Problem auch mal. Bei mir lag es an einer GPO, die die Drucker verteilt hat. 

  • Danke für die Rückmeldung.

    Alles natürlich nicht ...

    Ohne GPO´s dauerts jetzt tatsächlich 4-5 Sekunden ... (für normale User und nen Admin).
    Auch ohne die "eine" Drucker GPO gehts in 7 Sekunden (hier greifen sicher 10-12 GPO´s).
    Gestern kam auch der erste neue Windows 11 PC (noch kein User oder Drucker drauf) und alle Drucker konnten nicht genutzt werden..

    Alle Druckertreiber sind jetzt auf dem Client installiert und trotzdem dauert es noch ca 2 Minuten.

    Mir ist das aber ein Rätsel, das VLAN3 wird nicht gefiltert.

    Vermutlich macht die Drucker GPO irgendwas merkwürdiges...

  • Wie wird denn zwischen den beiden Netzen geroutet?

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • Kann ich nicht sagen,
    das macht ja die Sophos XGS automatisch ...

  • Hallo Jürgen,

    ich schliesse aus den bisherigen Angaben, dass in beiden Netzen die XGS das Default Gateway ist, korrekt?

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • Ist in beiden das Default Gateway.

    Aktuell konnte ich das Problem eingrenzen.

    Eine GPO verteilt die Drucker, mit den Lexmark, Brother gibt es keine Probleme.
    Sobald der Sharp Drucker MX-3071 in den GPO´s enabled ist klemmt es.

    Alle Drucker kommen vom gleichen Printserver aus dem Netz (192.168.2.0/24, Zone LAN)  

    Update

    Sobald der Drucker mit der Option "Run in logged-on user's security context (user policy option" aktualisiert wird, klemmts im VLAN3.

    Warum ist mir unklar... 

    PS

    Ich hab jetzt WMI Filter auf die GPO´s definiert, so läuft die GPO nur im passenden VLAN.

  • ich nehme an, irgendwo klemmt die Kommunikation aus dem 172 ins 192er Netz. Gut möglich, dass das Application Control oder IPS reingrätscht. Im 192er Netz konnten Clients und Drucker ohne Firewall miteinander kommunizieren.

    Das kann sowohl Windows Firewall als auch Sophos Firwall verursachen.

    Windows Firewall erlaubt einige Dienste standardmäßig im "local subnet". Die brauchen dann keine extra Regel.

    Solltest du recht einfach mit einem Netzwerkdump testen können. Lass den in einer anderen Windows session laufen und melde den User mit der GPO in einer anderen Session an.

Reply
  • ich nehme an, irgendwo klemmt die Kommunikation aus dem 172 ins 192er Netz. Gut möglich, dass das Application Control oder IPS reingrätscht. Im 192er Netz konnten Clients und Drucker ohne Firewall miteinander kommunizieren.

    Das kann sowohl Windows Firewall als auch Sophos Firwall verursachen.

    Windows Firewall erlaubt einige Dienste standardmäßig im "local subnet". Die brauchen dann keine extra Regel.

    Solltest du recht einfach mit einem Netzwerkdump testen können. Lass den in einer anderen Windows session laufen und melde den User mit der GPO in einer anderen Session an.

Children
No Data