Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 3150 views
  • Users 0 members are here
Options
Suggested
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

Firewall Probleme nach Update auf 9.103-5 - SSL-VPN

GuyFawkes
Hi Forum,
hier das erste Problem nach Update auf die aktuellste Version.

Ich habe ein AD und AD-Benutzer sind in einer VPN Gruppe (nicht primäre Gruppe des Benutzers).
Alle User werden über diese Gruppe authentifiziert, damit diese VPN aufbauen können und auf das Netzwerk zugreifen. Funktioniert einwandfrei.

Allerdings, sobald ich jetzt neue Benutzer (nach Update auf 9.103-5) in diese AD Gruppe hinzufüge, können diese zwar erfolgreich eine VPN Verbindung aufbauen, aber können nicht auf das Netz zugreifen.

Prüfe ich den Benutzer, wird auch sofort erkannt, dass dieser Benutzer in der richtigen Gruppe enthalten ist.

Beispiel:

Benutzer "Test" ist in der AD Gruppe und diese Gruppe ist auch für VPN zugelassen: GL_SSL-VPN
Alle Benutzer können arbeiten, Benuzter Test kann VPN Client herunterladen, installieren und das VPN aufbauen, aber hat kein Zugriff ins Netzwerk.
Füge ich die lokal angelegten (mit Backend Auth) unter "SSL - Profile - Benutzer und Gruppen" expliziet hinzu, funktioniert es.
Nehme ich Benutzer Test wieder aus den zugelassen "Gruppen und Benutzern" wieder heraus, kann VPN aufgebaut werden, aber kein Zugriff ins Netzwerk - Firewall droppt alle Pakete, obwohl die Gruppe GL_SSL-VPN eingetragen ist.


Hat noch jemand dieses Problem oder ein ähnliches Problem?



Nice greetings


This thread was automatically locked due to age.
  • 0
    Ist meines Wissens bekannt. Du hast vermutlich "Automatic firewall rule" beim SSL-VPN aktiv!?
    Deaktivier das und mach stattdessen manuelle Regeln. Es gibt da derzeit ein Problem mit den automatischen Regeln und AD-basiertem SSL-VPN.

    edit: Gerade in den Known Issues nachgeschaut, sollte eigenlich mit 9.101 behoben sein. Einen Versuch ist's trotzdem wert...

    ----------
    Sophos user, admin and reseller.
    Private Setup:

    • XG: HPE DL20 Gen9 (Core i3-7300, 8GB RAM, 120GB SSD) | XG 18.0 (Home License) with: Web Protection, Site-to-Site-VPN (IPSec, RED-Tunnel), Remote Access (SSL, HTML5)
    • UTM: 2 vCPUs, 2GB RAM, 50GB vHDD, 2 vNICs on vServer (KVM) | UTM 9.7 (Home License) with: Email Protection, Webserver Protection, RED-Tunnel (server)
  • 0
    Hatte ich auch gedacht, aber leider nicht der Fall.
    Auch das manuelle anlegen der Richtlinien funktioniert nicht. Pakete werden trotzdem gedroppt.

    Nice greetings
  • 0 in reply to GuyFawkes
    Poste bitte mal einen Auszug aus dem vollständigen Firewall Log (nicht Live Log), am Besten ein paar Zeilen, wo ein bisheriger User durchkommt und dann ein paar Zeilen, wo ein neu konfigurierter User gedroppt wird.

    ----------
    Sophos user, admin and reseller.
    Private Setup:

    • XG: HPE DL20 Gen9 (Core i3-7300, 8GB RAM, 120GB SSD) | XG 18.0 (Home License) with: Web Protection, Site-to-Site-VPN (IPSec, RED-Tunnel), Remote Access (SSL, HTML5)
    • UTM: 2 vCPUs, 2GB RAM, 50GB vHDD, 2 vNICs on vServer (KVM) | UTM 9.7 (Home License) with: Email Protection, Webserver Protection, RED-Tunnel (server)
  • 0 in reply to scorpionking
    Klingt irgendwie nach konfiguriertem Interface an der network Definition.

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

  • 0
    Gerade einmal nachgestellt.

    User war direkt eingetragen, alles kein Problem. Habe User entfernt - VPN neu aufgebaut und direkt haben wir ein paar DNS Anfragen, die gedroppt werden - Ping etc. wird alles gedroppt. 

    Hier mal ein Log Eintrag:
    2013:07:15-05:26:25 utm-1 ulogd[4508]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth0" outitf="tun0" srcmac="0:c:29:xx:xx:xx" dstmac="0:1a:8c:yy:yy:yy" srcip="192.168.x.12" dstip="10.242.8.10" proto="6" length="48" tos="0x00" prec="0x00" ttl="127" srcport="46960" dstport="135" tcpflags="SYN"


    10.242.8.0 - Standard VPN Netz
    192.168.x.0 - LAN

    Nice greetings
  • 0
    Was kommt bei einer manuellen Regel?

    Wie sind die Definitionen eingestellt ?
     
    Die Interface Konfig der Definition sollte auf any stehen.

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

  • 0 in reply to maygyver
    Was kommt bei einer manuellen Regel?

    Wie sind die Definitionen eingestellt ?
     
    Die Interface Konfig der Definition sollte auf any stehen.



    Genau dieselben Drops bzw. dieselben Log Einträge...
    Auch wenn ich in der Firewall der "User Netzwerk" nehme, oder  "VPN Pool (SSL)". 

    In den Definitionen ist Schnittstelle immer >

    Sorry [:(]

    --> auch hier, Call
    Danke schonmal! Wenn weitere Ideen, immer her damit

    Nice greetings
  • 0 in reply to GuyFawkes
    Wie ist das de Stand?

    Ich hatte gerade die Problematik in einem SSL Profile, dass es nur auf einen bestimmten Host verbinden soll. 

    Da die DNS Einstellungen für Remote Access aber nicht Profile based sind, sondern global eingestellt werden, hatte der Client keinen DNS Zugriff. 

    Dann DNS von den internen DNS Servern auf die Astaro umgestellt und im DNS Service das VPN Netz hinzugefügt. Geht trotzdem nicht. Das Profile muss, um den Astaro DNS Service zu erreichen, auch die interne IP der Astaro in der Verbindung konfiguriert haben.

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

  • 0
    Aktueller Status ist, dass der Call direkt bei Sophos liegt.
    Vermutung: BUG

    Weitere Infos habe ich noch nicht.
    Aber was du beschreibst habe ich auch auf dem System.

    Nice greetings
  • 0 in reply to GuyFawkes
    Was mir bei deinem Logauszug komisch vorkommt, es ist ein Paket internes Netz nach VPN Netz für den Service 135 (also Windows Networking), hast du dafür auch eine Regel erstellt?

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

Cookie Information Banner