Wenn Sie im Paketfilter einen Drop: (Default Drop) sehen, kommen die Pakete schon einmal bei der UTM an und werden entpackt.

Hier stimmt jetzt noch etwas mit der Regel nicht, bei der Meldung Default Drop wurde für das Datenpaket keine gültige Regel gefunden.

Bsp
Wg-RW Netz >> Internes Netz >> icmp ...

Moin

im Changelog zur v14.1.3  wird von einen Problem bei der AD-Authentifizierung berichtet.

Dort ist auch ein Workaround beschrieben.
https://wiki.securepoint.de/UTM/Changelog

Ich hab SSLVPN mal bei Ubuntu mit den nativen VPN des Betriebssystems eingerichtet.

Hier musste ich in der Verbindung explizit AES-256-GCM hinterlegen, damit es klappt.

Ansonsten kann ein Blick in das Log der Verbindung helfen.

Moin

Hierzu hat Lauritz im letzten Monat etwas geschrieben.
Die Antwort ist weiterhin aktuell


viewtopic.php?p=35912

In den genannten Logmeldungen ist keine direkte Ursache ersichtlich.

Sind die Zertifikate vielleicht noch mit sha1 erstellt?
Ist das Routing für die genutzte Schnittstelle in Ordnung?

Erstellen Sie doch ein Ticket zu diesen Thema, dann schauen wir uns den Fall zusammen an.

Hier muss ich natürlich ziemlich raten, das kann auch gut falsch sein.

Prüfen Sie einmal, ob es nicht zu einen IP Adress Konflikt zB mit einen Netz hinter einen SSLVPN Tunnel und der internen IP kommt.
Oder ob eine Route komplett falsch ist.

Jede Route kann nur einmal funktionieren, einen Konflikt ...

Shift + PageUp

Hier kann ich nur mit "es kommt drauf an" antworten.

Für das Problem, welches wir in der v14.0.4 gefixt haben, sind keine Ausnahmen im Proxy mehr notwendig.

Für andere Problem bzw Inkompatibilitäten kann es notwendig sein, eine Ausnahme zu setzen.

Das ist zur Zeit noch nicht möglich.

Wenn Sie dieses Feature zukünftig benötigen, können Sie uns dies in der Wunschbox mitteilen.
https://www.securepoint.de/fuer-partner ... /wunschbox

Die Anzahl der Verbindungen in Phase zwei sollte hier keinen Einfluss haben.

Hier sollten Sie einmal die Gegenstelle prüfen, ob die IPs auch dort korrekt hinterlegt sind.

Auch ein Blick ins Log (Loglevel: Ausführlich) könnte einen Hinweis geben

Hier könnten Sie auch unseren neuen VPN Client nutzen.
Dieser nutzt eine andere Technik im Hintergrund.

https://wiki.securepoint.de/VPN/VPN-Client

Das Verhalten mit den Bietertool ist ein eigenständiges Problem 
Dies wurde in der v14.0.4 gelöst. 



https://wiki.securepoint.de/UTM/Changelog

Auf Grund des Logs lässt sich leider erst einmal wenig sagen.
Hier kommt schlicht keine Antwort vom Server zurück.

Am Besten Sie schauen mal in der UTM auf das Log>>SSLVPN Meldungen.
Gibt es hier Einwahlversuche mit der externen IP des Clients (meist in grün angezeigt)?

Wenn nicht, prüfen Sie den ...

Einmal die Gretchenfrage:
Mit welchen Port rufen Sie das Webinterface auf? 11115?
 
Ansonsten landen Sie auf den Benutzerinterface statt den Admin-Interface.

Da lohnt sich ein Blick ins Wiki.
Genau dieser Anwendungsfall ist hier Beschrieben:
https://wiki.securepoint.de/UTM/APP/Nameserver

Hat das Client-Zertifikat evtl die Server-Flag?

Es kann auch helfen, den SSLVPN Dienst einmal richtig zu Stoppen und zu Starten (statt nur Neuzustarten)

Bitte schauen Sie ins Log >> Applikations- und Kernelmeldungen und suchen Sie nach "dyndns_client"

ggf müssen Sie den SPDyn auf der Schnittstelle deaktivieren/aktivieren um Logdaten zu bekommen.


Welche Meldung kommt da?

Nein, wenn das Homebildschirm-Layout deaktiviert wird, sollte dieser auf den Gerät wieder Bedienbar sein. 
  

Wenn es hier zu Seltsamkeiten kommt eröffnen Sie doch bitte ein Ticket mit den Details (zb Kunde/Gerät/Profil), dann können wir dies direkt prüfen.

Die Bearbeitung  des Homebildschirms ist nicht möglich, wenn ein Homebildschirm-Layout genutzt wird. 
Dies umfasst auch das manuelle Löschen von Apps. 
 
Wenn der Homebildschirm bearbeitet werden soll, darf kein festes Layout genutzt werden. 
 

Im Wireguard Widget lassen sich die aktuelle Verbindungen ansehen.

Ein größeres Log für Wireguard gibt es auf der UTM nicht.

Bitte stellen Sie sicher, dass Wireguard auf den Cluster Spare deaktiviert ist. 

Damit gab es mal Probleme, von den beschriebenen Symptomen könnte es passen

 

2024-09-03 11:37:41 UDPv4 link remote: [AF_INET]192.168.11.100:1194 
 
Das ist eine private IP. 
Hier müsste die öffentliche IP des Anschlusses stehen. 

Entweder steht die falsche IP in der Konfig oder der dynDNS löst falsch auf

Das hat nichts mit dem Beta VPN zu tun.
Ich beobachte diesen Fehler seit dem April - Update von Windows.

Lösungen:
In der .ovpn die Option "route-delay 5" setzen

oder

Die Verbindung statt mit UDP mit TCP aufbauen lassen

Prinzipiell lässt sich sagen, dass zu jeder Route auch eine Regel erstellt werden muss

Mir ist leider nicht bekannt, dass man bei WhatsApp für das Cloudbackup den Cloudanbieter wechseln könnte.

Spontan fällt mir dazu nur ein, manuelle Backups zB per Apple Configurator durchzuführen, um die iCloud zu vermeiden.

Und wenn man die iCloud nutzen muss, sollte man verwaltete Apple IDs ...