[Sammelthread] Sophos UTM-Sammelthread

Ekka schrieb:
Moin Moin, wir hatten an 2 Standorten Probleme mit den neuen Skype Versionen und der UTM.
Scheint an einer Änderung im Anrufaufbau von Skype zu liegen: Beide Teilnehmer sehen sich online, können Anrufe zwar starten aber die jeweiligen Gegenstellen erhalten keinen Anruf. Minuten später erschien dann aber ein verpasster Anruf :shake:
Wir konnten dies auf die Schnelle nur mit einem Downgrade von Skype auf Version 7.13.0.101 beheben.
Zum Vergrößern anklicken....

Danke dir, habe dazu nun auch was im Skype Forum gefunden werde es mal probieren.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
paulianer schrieb:
Die UTM lief bei mir auf monatelang unter Hyper-V genau so unauffällig wie unter ESXi. Server 2012 R2 als Host.
Zum Vergrößern anklicken....

Wie hast du die NICs eingerichtet? Ich würde gerne Passthrough einrichten (Extra eine Dual Port NIC verbaut)
 
Läuft bei ebenfalls unter Hyper-V 2016. Keine Probleme.
Eine NIC ist mit der Fritzbox verbunden, die andere geht zum Switch. 3 + 4 sollen mal für DMZ herhalten. Zumindest eine.
 
Olaf16 schrieb:
Wie hast du die NICs eingerichtet? Ich würde gerne Passthrough einrichten (Extra eine Dual Port NIC verbaut)
Zum Vergrößern anklicken....
Was meinst du genau mit Passthrough? Durchreichen per VT-d?

Ich habe einfach mehrere virtuelle Switche erstellt und es so auf meine zwei NICs verteilt:
NIC1: LAN und diverse VLANs für das WLAN
NIC2: WAN zum Modem
 
Habe gestern zum ersten Mal eine eMail von der UTM (VM) bekommen, mit dem tollen Betreff
[utm.domain.tld][CRIT-026] License usage: EXCEEDING 110% OF USER COUNT on Sophos UTM

In meinem Netzwerk sind maximal 25 IP´s unterwegs, die aber nicht alle gleichzeitig vorhanden sein müssen.
Spielt das überhaupt eine Rolle? Werden da nur akt. IP´s berücksichtig oder alle die die UTM jemals gesehen hat?

Habe jetzt das Netz danach befragt und folgende Lösungen haben nichts gebracht:
- Reboot der Maschine
- ändern der DHCP Lease-Time
- nochmaliges Downloaden der Lizenz-File aus dem My-Sophos und einspielen in die UTM

Weiterhin habe ich folgendes probiert:
per Konsole folgendes eingegeben:
cc set licensing active_ips =[]
cc set licensing user_limit_exceeded 0

Dies hat die Liste der outside scope zwar reduziert aber in der Liste der inside scope standen wohl immer noch 50 IP´s.
Nach einem Reboot ist die Liste zwar wieder leer aber was kann ich tun wenn das wieder hoch kommt?

Ich hatte zuvor einen Netzwerk-Scan nach einem Gerät durchgeführt, dessen feste IP ich nicht dokumentiert hatte.
Da scheint dann ein solches Phänomen hervorzurufen, aber wenn die Lease-Time der "angepingten" IP´s beim Scan abläuft soll das angeblich wieder verschwinden.
Nur blöd, dass ich die Lease-Time vorher auf eine Woche gesetzt hatte.
 
bacon schrieb:
Habe gestern zum ersten Mal eine eMail von der UTM (VM) bekommen, mit dem tollen Betreff
[utm.domain.tld][CRIT-026] License usage: EXCEEDING 110% OF USER COUNT on Sophos UTM

In meinem Netzwerk sind maximal 25 IP´s unterwegs, die aber nicht alle gleichzeitig vorhanden sein müssen.
Spielt das überhaupt eine Rolle? Werden da nur akt. IP´s berücksichtig oder alle die die UTM jemals gesehen hat?

Habe jetzt das Netz danach befragt und folgende Lösungen haben nichts gebracht:
- Reboot der Maschine
- ändern der DHCP Lease-Time
- nochmaliges Downloaden der Lizenz-File aus dem My-Sophos und einspielen in die UTM

Weiterhin habe ich folgendes probiert:
per Konsole folgendes eingegeben:
cc set licensing active_ips =[]
cc set licensing user_limit_exceeded 0

Dies hat die Liste der outside scope zwar reduziert aber in der Liste der inside scope standen wohl immer noch 50 IP´s.
Nach einem Reboot ist die Liste zwar wieder leer aber was kann ich tun wenn das wieder hoch kommt?

Ich hatte zuvor einen Netzwerk-Scan nach einem Gerät durchgeführt, dessen feste IP ich nicht dokumentiert hatte.
Da scheint dann ein solches Phänomen hervorzurufen, aber wenn die Lease-Time der "angepingten" IP´s beim Scan abläuft soll das angeblich wieder verschwinden.
Nur blöd, dass ich die Lease-Time vorher auf eine Woche gesetzt hatte.
Zum Vergrößern anklicken....
Ich hab hier hin Faden Mal ne kleine umgehungslösung gepostet, ich finde sie mitmachen Handy nur grade nicht

Gesendet von meinem ZTE A2017G mit Tapatalk
 
Hallo zusammen,

ich versuche schon den ganzen Tag, eine RED-Verbindung zwischen 2 Sophos Home herzustellen.
Ich bin nach folgender Anleitung vorgegangen. https://community.sophos.com/kb/de-de/120157
Die RED-Verbindung kommt zustande, aber ich kann auf Geräte der Gegenseite nicht zugreifen.
Kann mir einer weiterhelfen oder einen Tipp geben?
Grüße Higgs

Hat sich erledigt....
 
Zuletzt bearbeitet:
zu frü gefreut, wieder sagt mir die UTM dass ich mehr IP´s verwende wie erlaubt.
Hilft da möglicherweise eine komplette Neuinstallation?
Oder wird das auf den Sophos Server mit meiner Lizenz verknüpft?
 
oOHiggsOo schrieb:
Die RED-Verbindung kommt zustande, aber ich kann auf Geräte der Gegenseite nicht zugreifen.
Grüße Higgs
Zum Vergrößern anklicken....

Meine Glaskugel sagt ..... ne im Ernst. Du musst schon mit etwas mehr Infos über die Dörfer kommen. Was für IPs hast du vergeben, kannst du die IPs der Sophos jeweils auf den RED Interfaces anpingen? (Hast du neue Interfaces mit der virtuellen RED Hardware angelegt?)
 
Moin zusammen,

hat hier wer seit kurzen auch immer öfter das Problem das TCP 80/443 Traffic nicht mehr durch den transparenten Proxy geht? Ist egal von welchem Endgerät oder Anwendung der Traffic kommt, läuft dann natürlich im Paketfilter auf wo es geblockt wird. Hat wer eine Idee?

Grüße
 
Dann hat sich eventuell der Proxydienst aufgehängt. Was passiert, wenn Du den Webfilter deaktivierst und wieder aktivierst (womit der entsprechende Dienst gestoppt und wieder gestartet wird)? Welche Firmware hast Du installiert, und wann hast Du diese Firmware installiert? Gibt es da vielleicht einen Zusammenhang, also dass die Probleme angefangen haben, nachdem Du die Firmware aktualisiert hast?
 
Eye-Q schrieb:
Dann hat sich eventuell der Proxydienst aufgehängt. Was passiert, wenn Du den Webfilter deaktivierst und wieder aktivierst (womit der entsprechende Dienst gestoppt und wieder gestartet wird)? Welche Firmware hast Du installiert, und wann hast Du diese Firmware installiert? Gibt es da vielleicht einen Zusammenhang, also dass die Probleme angefangen haben, nachdem Du die Firmware aktualisiert hast?
Zum Vergrößern anklicken....

Firmware ist die aktuelle 9.409-9, der Proxy läuft ja an sich. Es passiert nur bei speziellen Anwendung (Desktop) oder Apps (Mobil), wo hier auch natürlich Updates in den letzten Wochen veröffentlicht worden sind und installiert wurden.

Das Phänomen das nicht immer alles an TCP 80/443 an den Proxy geht ist mir schon vorher mal aufgefallen aber nur sehr vereinzelt. Nun ist es aber so das auch wirklich mal etwas nicht funktioniert. Und die Ports wieder so zu öffnen ist leider auch nur bedingt möglich.
 
Eye-Q schrieb:
:confused: Was denn nun? "Egal von welchem Endgerät oder Anwendung" und "passiert nur bei speziellen Anwendungen (Desktop) oder Apps (Mobil)" schließen sich gegenseitig aus...
Zum Vergrößern anklicken....

Mh ok schlecht ausgedrückt. Also das Endgerät ist egal aber die Anwendung ist dann immer "die" gleiche auf dem Desktop eine Software und Mobil denn 2 Apps die sich so verhalten.
 
Mahlzeit!

Mal ne Frage in die Runde, wenn ich ein Board kaufe was einen mPCIe Anschluss hat und ich dort zB. die 7260.HMWWB.R benutze, erkennt die UTM die Karte als AP in der WirelessProtection?

Die Kabel würde ich von der Karte nach außen an zwei Antennen führen.
Als Alternative würde ich einen "echten" AP benutzen, gibt es alternativen zu den Sophos AP's die günstiger sind und 802.11a/b/g/n/ac simultan können und natürlich über die UTM konfiguriert werden können.
 
Und eine 3te NIC + AP deiner Wahl ist keine Option? Der traffic läuft dann ja über die UTM, nur der AP ist halt nicht direkt in der UTM konfigurierbar.
 
paulianer schrieb:
Was meinst du genau mit Passthrough? Durchreichen per VT-d?

Ich habe einfach mehrere virtuelle Switche erstellt und es so auf meine zwei NICs verteilt:
NIC1: LAN und diverse VLANs für das WLAN
NIC2: WAN zum Modem
Zum Vergrößern anklicken....



Will irgendwie nicht bei mir starten. Zumindest nicht mit "discrete device assignment"... Irgendwie muss ich mir das mit der PowerShell nomal anschauen :/
 
??? Wenn Du eine NIC hart an eine VM durchreichst brauchst du keine virtuellen Switches mehr. Dann kommt übrigens auch der Host da nicht mehr dran.
 
Ist mir schon klar. Ich mache das durchreichen schon immer unter ESXi - Bisher (Bis auf Festplatten) aber noch keine Erfahrung unter Hyper-V sammeln können diesbezüglich. Der Umstand, dass dies nur mit PowerShell Kommandos geht und ich diese kaum kenne hilft mir aber grad nicht weiter :fresse:
Muss mich mal im Hyper-V Fred umschauen :)
 
Ich halte persönlich wenig davon, Geräte - vor allem NICs - per Passthrough durchzureichen wenn es nicht ausnahmsweise gewichtige Gründe dafür gibt (wie eben zum Beispiel einen HBA um einer Storage-VM den direkten Zugriff auf die Hardware zu ermöglichen).

Bei NICs halte ich das eher für unnötig/Unsinn - die Verwaltung kann man getrost dem Host (unter ESXi wie Hyper-V) überlassen und wenn man aus "Sicherheitsgründen" den Host nicht in diesem Netz haben will, geht das auch mit Bordmitteln. Die richtigen NICs sind genau dafür gemacht mit SR/IOV, remoteDMA & Co., da wirfst Du Performance eher inne Tonne als das es irgendwas bringt. Dafür spricht auch, dass PCIe-Passthrough bei den beiden großen Virtualisierern (wieder ESXi und Hyper-V) häufig nicht (voll) supported ist bzw. andere Features wegfallen, die man eigentlich gerne hätte.
 
Sacht mal, seit WANN muss man bei einer WAF Freigabe eines Webservers nach außen hin für die Kommunikation der UTM zum internen Webserver eine Firewall Regel auf der UTM schreiben???
Ich hab gestern nicht schlecht geguckt, eine vorhandene WAF Freigabe oder besser gesagt, 2x davon über zwei externe URLs mit 2x verschiedenen Forms für die Anmeldung (wegen zwei verschiedenen AD-Backends/zwei übergebenen Domains) -> extern auf die UTM public IP via HTTPS, intern am Webserver auf TCP9001 via HTTPS und alles ist schick... Nun war das Problem, dass aus 1x interner Webserver 2x derer werden sollten, welche auf der gleichen internen IP lauschen, aber verschiedene Ports nutzen.

Ich also zwei neue "Real Webserver" angelegt, jeweils mit der IP und entsprechenden Ports (TCP9010 + TCP9011), weiterhin via HTTPS und die beiden WAF Freigaben 1:1 nur umgeboten... Dann getestet, nix!???
-> via Telnet von der Konsole versucht, TCP9010 und TCP9011 zu öffnen -> nix
-> via Telnet TCP9001 -> also die alte Verbindung probiert -> geht
-> nach Firewall Rules auf der UTM geschaut -> keine!! vorhanden, also NUR die default Drop Rule
-> mein Netzwerker zusammen geschissen, warum die UTM noch nicht via TCP9010/9011 zum Webserver kommt -> gecheckt, alles sauber eingetragen, gesniffert, kommen gar keine Pakete an
-> wieder UTM, Firewall Livelog und siehe da, Verbindungen von der UTM internen Interface IP zum Real Webserber mit TCP9010 und TCO9011 weden geblockt, sowohl IPv4 als auch v6... Es blockt die default Drop Rule!?
Was zur Hölle läuft da schief??

-> UTM ist die neueste Version von gestern, hab extra nochmal ein Update drüber geschoben... Vorher die 9.405, damit gings aber auch nicht.
-> Booten hilft nicht, sprich bringt keine Besserung... TCP9001 geht (ist aber schon Monate dort als WAF drin), die neu eingerichteten TCP9010 und TCP9011 NICHT??

Ist das ein Bug? Oder ist das gewollt??




besterino schrieb:
Bei NICs halte ich das eher für unnötig/Unsinn - die Verwaltung kann man getrost dem Host (unter ESXi wie Hyper-V) überlassen und wenn man aus "Sicherheitsgründen" den Host nicht in diesem Netz haben will, geht das auch mit Bordmitteln. Die richtigen NICs sind genau dafür gemacht mit SR/IOV, remoteDMA & Co., da wirfst Du Performance eher inne Tonne als das es irgendwas bringt. Dafür spricht auch, dass PCIe-Passthrough bei den beiden großen Virtualisierern (wieder ESXi und Hyper-V) häufig nicht (voll) supported ist bzw. andere Features wegfallen, die man eigentlich gerne hätte.
Zum Vergrößern anklicken....

Nunja, es dürfte in der Tat eher das Thema Sicherheit sein... Du gibst dein Vertrauen halt dem Networkstack des Hypervisors, durchgereicht zur VM liegt das Vertrauen halt bei der VM -> und dessen Networkstack/Treibern.
Relevant wird das genau an der Stelle, wenn über diesen Link potentiell das System angreifbar ist/wird... Durchgereicht an die VM = weg vom System = nicht angreifbar über diesen Weg.

Ob einem das nun den Spaß wert ist, muss selbst gewusst werden... Denn andersrum, potentiell angreifbar ist auch der Weg über die VM, durch den Virtualisierungslayer -> zumindest bei kapitalen Sicherheitsproblemen in Software. Rein aus dem Bauchgefühl herraus, bei einem Hyper-V aka MS Windows Based -> NICs durchreichen :fresse:, bei einem Unix/Linux based Hypervisor -> kann man das auch weglassen :wink:
 
Zuletzt bearbeitet:
fdsonne schrieb:
Ob einem das nun den Spaß wert ist, muss selbst gewusst werden... Denn andersrum, potentiell angreifbar ist auch der Weg über die VM, durch den Virtualisierungslayer -> zumindest bei kapitalen Sicherheitsproblemen in Software. Rein aus dem Bauchgefühl herraus, bei einem Hyper-V aka MS Windows Based -> NICs durchreichen :fresse:, bei einem Unix/Linux based Hypervisor -> kann man das auch weglassen :wink:
Zum Vergrößern anklicken....

Ein durchgereichtes PCIe Gerät ist eine offene Tür zum Host. VMware selbst rät vom Einsatz in kritischen Bereichen ab.
 
Anmelden, um zu antworten.

Ähnliche Themen

R
[User-Review] Lesertest zur Synology DiskStation DS224+
Antworten
0
Aufrufe
6K
_roman_
R
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh