shit ... shit ... supershit ... zumindest im Vergleich zur Sophos UTM ... (meine persönliche Meinung)
[Sammelthread] Sophos UTM-Sammelthread
- Ersteller XTaZY
- Erstellt am
shit ... shit ... supershit ... zumindest im Vergleich zur Sophos UTM ... (meine persönliche Meinung)
Lese ich auch oft...aber WARUM? Welche Argumente gibt es....weil vielleicht gibt es eine Konstellation, wo man mit der neuen XG besser unterwegs ist....z.B. wenn man RED und Endpoint Protection nicht benötigt.
Also bitte mal richtige Argumente gegen die XG nennen.
What9000
Urgestein
- Mitglied seit
- 15.01.2011
- Beiträge
- 4.415
Ich muss leider die Hardware-Diskussion nochmal aufflammen lassen, da meine jetzige UTM den Geist aufgegeben hat.
Gibt es einen Barebone/Mini-PC für eine Home UTM in z.B. der Größe eines Mac Minis? Voraussetzung wären 2 GBit-LAN-Ports oder ein Interface zur Erweiterung eines zweiten Ports. Verwaltet werden sollen 4-5 Clients im LAN und 2-3 Clients im WLAN ohne Webserver usw..
Gibt es einen Barebone/Mini-PC für eine Home UTM in z.B. der Größe eines Mac Minis? Voraussetzung wären 2 GBit-LAN-Ports oder ein Interface zur Erweiterung eines zweiten Ports. Verwaltet werden sollen 4-5 Clients im LAN und 2-3 Clients im WLAN ohne Webserver usw..
da ist ja schon fast ein standartrouter ausreichend 
affabanana
Enthusiast
- Mitglied seit
- 16.10.2011
- Beiträge
- 275
Contra Xg
Snat hab ich nicht hinbekommen. Habe aber auch nicht allzulange geübt
Die besseren Durchsätze der xg zur Sg kommen will daher, das die xg einfach alles durchläst.
Meine persönliche Meinung
Snat hab ich nicht hinbekommen. Habe aber auch nicht allzulange geübt
Die besseren Durchsätze der xg zur Sg kommen will daher, das die xg einfach alles durchläst.
Meine persönliche Meinung
das hört sich ja mal gar nicht gut an. wollte mir so einen zulegen: Jetway JBC311U93W-2930-B (Intel Bay Trail-M) Â [ Jetway (Intel) ]
ist das mit dem vorgaukeln, weil nur originale sophos aps unterstützt werden?
ich hatte mal ein altes Netbook (also eins der ersten überhaupt - eeepc)
dort hatte ich erst mit USB nic getestet (nicht so gut)
dann aber den wlan adapter rausgenommen und dafür ein mini pcie auf gbit intel lan adapter reingebaut
und das Kabel mit der LAN Buchse nach aussen geführt
darauf lief dann auch sophos, allerdings hatte ich später IPfire drauf installiert, da der uralte single atom für die utm zu schwach ist.
das ding hat nun mein nachbar, läuft
und wenn console gebraucht wird, einfach bildschirm hochklappen
der braucht ca. 6w
und für die 6 clients reicht der
will damit sagen, dass diese mini pcie lan adapter echt gut sind, und man alte note/net-books oder miniplatinen (die nur eine nic, aber einen steckplatz haben) nachrüsten kann, mit 1 oder 2 extra NICs
es gibt doch diese mini PC von zotac oder intel nuc
oder wie ich das j1900er Board (was aber schon mini itx ist - also grösser als zb. NUC) + gehäuse
von jetway die platinen sind nett, da gibt es eine super kleine mit 4 nics, aber umso kleiner, umso teurer
so ein zotac PC gibts schon für ca. 100,-
hdd und ram muss man eh meist extra rechnen
und dazu die mini pcie nic
ich denke RAM ist bei der UTM recht wichtig, seit dort die url listen im RAM abgelegt werden
von meinen 4GB werden immer 3gb benutzt
cpu max 20% (einzig die realtek nics sind nicht so schön), aber hatte da auch schon überlegt ne intel dual server nic nachzurüsten
Gruß Ingo
dort hatte ich erst mit USB nic getestet (nicht so gut)
dann aber den wlan adapter rausgenommen und dafür ein mini pcie auf gbit intel lan adapter reingebaut
und das Kabel mit der LAN Buchse nach aussen geführt
darauf lief dann auch sophos, allerdings hatte ich später IPfire drauf installiert, da der uralte single atom für die utm zu schwach ist.
das ding hat nun mein nachbar, läuft
und wenn console gebraucht wird, einfach bildschirm hochklappen
der braucht ca. 6w
und für die 6 clients reicht der
will damit sagen, dass diese mini pcie lan adapter echt gut sind, und man alte note/net-books oder miniplatinen (die nur eine nic, aber einen steckplatz haben) nachrüsten kann, mit 1 oder 2 extra NICs
es gibt doch diese mini PC von zotac oder intel nuc
oder wie ich das j1900er Board (was aber schon mini itx ist - also grösser als zb. NUC) + gehäuse
von jetway die platinen sind nett, da gibt es eine super kleine mit 4 nics, aber umso kleiner, umso teurer
so ein zotac PC gibts schon für ca. 100,-
hdd und ram muss man eh meist extra rechnen
und dazu die mini pcie nic
ich denke RAM ist bei der UTM recht wichtig, seit dort die url listen im RAM abgelegt werden
von meinen 4GB werden immer 3gb benutzt
cpu max 20% (einzig die realtek nics sind nicht so schön), aber hatte da auch schon überlegt ne intel dual server nic nachzurüsten
Gruß Ingo
Hier ein Link zu dem Thema, mit den hier genannten Wifi Adaptern scheint es bei einigen zu funktionieren
Sophos Forum
Die Sache ist die, dass die meisten Meinungen zu XG direkt aus der Anfangsphase stammen. Und laut Sophoswebsite sind ja die meisten wichtigen Features mittlerweile eingebaut. Dazu ist halt die lizensierungssache um einiges besser als bei der UTM.
Frage an die Profis:
Suche eine Möglichkeit bei der Sophos UTM Home Edition die WebProxy Errorpages Pages zu customizen. Leider geht das ja nicht via WebGUI in der Home Edition.
Habe schon versucht die Templates per SSH auf dem Filesystem zu verändern, jedoch ohne Erfolg.
Pfade welche ich nehme:
/var/storage/chroot-http/etc/templates
/var/storage/chroot-http/etc/templates/defaults
Entweder geht das wirklich nicht, oder ich bearbeite die falschen Templates im Filesystem..?
Edit:
Es geht nun. Der korrekte Dateisystem Pfad ist:
/var/storage/chroot-http/etc/templates
Trick dabei ist, damit die Änderungen an den HTML Templates aber sofort übernommen werden, muss man sich im WebGUI als Admin ein- und wieder ausloggen.
Nun wäre es interessant herauszufinden, in welche Dateien er die Templatevariabeln ablegt ( z.B. <?company_logo?> <?company_text?> <?image_path?> )
Suche eine Möglichkeit bei der Sophos UTM Home Edition die WebProxy Errorpages Pages zu customizen. Leider geht das ja nicht via WebGUI in der Home Edition.
Habe schon versucht die Templates per SSH auf dem Filesystem zu verändern, jedoch ohne Erfolg.
Pfade welche ich nehme:
/var/storage/chroot-http/etc/templates
/var/storage/chroot-http/etc/templates/defaults
Entweder geht das wirklich nicht, oder ich bearbeite die falschen Templates im Filesystem..?
Edit:
Es geht nun. Der korrekte Dateisystem Pfad ist:
/var/storage/chroot-http/etc/templates
Trick dabei ist, damit die Änderungen an den HTML Templates aber sofort übernommen werden, muss man sich im WebGUI als Admin ein- und wieder ausloggen.
Nun wäre es interessant herauszufinden, in welche Dateien er die Templatevariabeln ablegt ( z.B. <?company_logo?> <?company_text?> <?image_path?> )
Zuletzt bearbeitet:
Sind deine Änderungen nicht beim nächsten Neustart bzw. Update wieder futsch? Ich meine mal etwas davon gehört zu haben. Sonst könnte man ja einfach den "Only for Homeuse" Banner entfernen.
Sacht mal, hat hier Jemand die WAF im Einsatz?
Ich versuche gerade einen WSUS Server über die Reverse Proxy Funktionalität public zu stellen... Hintergrund ist der, ich habe ne ganze Menge Windows Server weltweit stehen, diese sollen sich die Updates an definierter Stelle abholen und dort gleich auch die Update Reports lassen, denn es hat einfach den Vorteil, dass somit an zentraler Stelle die Patches freigegeben werden können (oder eben auch abgelehnt) und man gleichsam einen Überblick über den Patchstand der Systeme auf einen Blick hat.
Soweit sogut.
Mein Problem an der WAF ist, wenn ich die WAF Freigabe via HTTP auf Port 80 lauschen lasse, dann geht das grundsätzlich erstmal. Der real Webserver ist über 8530 respektive 443 mit SSL erreichbar. Die WAF "dreht" die angefragten URLs sauber um, zumindest scheint es mir so. Das Problem ist allerdings, wenn ich die WAF auf SSL stelle, sprich HTTPS über TCP 443, dann geht das Reporting sowie die Initialanfrage noch sauber (im Log erkennbar), allerdings packt es die WAF nicht, die Kontent URLs sauber umzudrehen. -> Jeder Client fragt die Patches über den gleichen Namen an, wie die WAF intern den WSUS erreicht.
-> nutze ich als real Webserver http://wsus01.domain.tld und für die WAF Freigabe HTTP auf TCP Port 80, läuft es
-> nutze ich als real Webserver http://wsus01.domain.tld und für die WAF Freigabe HTTPS auf TCP Port 443 -> fragt der Client seine Patches IMMER von http://wsus01.domain.tld an. -> wsus01.domain.tld sind dabei allerdings ausschließlich intern bekannt (auflösbar am AD/DNS Server, den auch der WSUS selbst nutzt). Die externen Clients können damit nix anfangen... -> entsprechend geht der Download der Patches in die Hose und nix passiert.
Ich habe mir nun schon damit geholfen, dass ich einen statischen DNS Eintrag auf der UTM hinterlegt habe, der genau so heißt, wie die public URL, welche auf die WAF zeigt. Sprich die Clients fragen https://public.example.com an und die WAF nutzt die selbe URL um auf den WSUS zu kommen.
Allerdings scheint die WAF damit immer noch nicht in der Lage zu sein, aus HTTP nun HTTPS zu machen. Sprich die Clients versuchen trotzdem ausschließlich http://public.example.com/content/... anstatt eben HTTPS.
Gibts dazu nen Schalter auf der WAF? -> ReWrite HTML, dieser Pass Outlook Anywhere und auch der "Never change HTML during static URL hardening or form hardening." wirken natürlich nicht. Die WAF bringt es einfach nicht fertig.
Ein Quertest komplett ohne WAF ergibt, dass der Client dort HTTPS nutzt. Ergo die WAF ist das Problem. Auch wurde andersrum schon ausgeschlossen, dass exakt die URL genutzt wird, welche der WAF intern zum Ansprechen des Real Webservers hinterlegt ist. Denn dreht man diese -> fragt der Client auch diese gedrehte URL an. (deswegen der Workarround mit gleichem public und private Namen) Nur eben ist es scheinbar total egal, ob man dort HTTP oder HTTPS beim Real Webserver wählt -> sobald dort eine Portumsetzung zwischen intern und extern erfolgt, gehts nur mit HTTP weiter und damit in die Hose.
Was kann ich noch machen? Jemand ne Idee?
-> der MS TMG 2010 konnte das im übrigen noch... Schade das Sophos es bis heute irgendwie nicht gebacken bekommt
Ich versuche gerade einen WSUS Server über die Reverse Proxy Funktionalität public zu stellen... Hintergrund ist der, ich habe ne ganze Menge Windows Server weltweit stehen, diese sollen sich die Updates an definierter Stelle abholen und dort gleich auch die Update Reports lassen, denn es hat einfach den Vorteil, dass somit an zentraler Stelle die Patches freigegeben werden können (oder eben auch abgelehnt) und man gleichsam einen Überblick über den Patchstand der Systeme auf einen Blick hat.
Soweit sogut.
Mein Problem an der WAF ist, wenn ich die WAF Freigabe via HTTP auf Port 80 lauschen lasse, dann geht das grundsätzlich erstmal. Der real Webserver ist über 8530 respektive 443 mit SSL erreichbar. Die WAF "dreht" die angefragten URLs sauber um, zumindest scheint es mir so. Das Problem ist allerdings, wenn ich die WAF auf SSL stelle, sprich HTTPS über TCP 443, dann geht das Reporting sowie die Initialanfrage noch sauber (im Log erkennbar), allerdings packt es die WAF nicht, die Kontent URLs sauber umzudrehen. -> Jeder Client fragt die Patches über den gleichen Namen an, wie die WAF intern den WSUS erreicht.
-> nutze ich als real Webserver http://wsus01.domain.tld und für die WAF Freigabe HTTP auf TCP Port 80, läuft es
-> nutze ich als real Webserver http://wsus01.domain.tld und für die WAF Freigabe HTTPS auf TCP Port 443 -> fragt der Client seine Patches IMMER von http://wsus01.domain.tld an. -> wsus01.domain.tld sind dabei allerdings ausschließlich intern bekannt (auflösbar am AD/DNS Server, den auch der WSUS selbst nutzt). Die externen Clients können damit nix anfangen... -> entsprechend geht der Download der Patches in die Hose und nix passiert.
Ich habe mir nun schon damit geholfen, dass ich einen statischen DNS Eintrag auf der UTM hinterlegt habe, der genau so heißt, wie die public URL, welche auf die WAF zeigt. Sprich die Clients fragen https://public.example.com an und die WAF nutzt die selbe URL um auf den WSUS zu kommen.
Allerdings scheint die WAF damit immer noch nicht in der Lage zu sein, aus HTTP nun HTTPS zu machen. Sprich die Clients versuchen trotzdem ausschließlich http://public.example.com/content/... anstatt eben HTTPS.
Gibts dazu nen Schalter auf der WAF? -> ReWrite HTML, dieser Pass Outlook Anywhere und auch der "Never change HTML during static URL hardening or form hardening." wirken natürlich nicht. Die WAF bringt es einfach nicht fertig.
Ein Quertest komplett ohne WAF ergibt, dass der Client dort HTTPS nutzt. Ergo die WAF ist das Problem. Auch wurde andersrum schon ausgeschlossen, dass exakt die URL genutzt wird, welche der WAF intern zum Ansprechen des Real Webservers hinterlegt ist. Denn dreht man diese -> fragt der Client auch diese gedrehte URL an. (deswegen der Workarround mit gleichem public und private Namen) Nur eben ist es scheinbar total egal, ob man dort HTTP oder HTTPS beim Real Webserver wählt -> sobald dort eine Portumsetzung zwischen intern und extern erfolgt, gehts nur mit HTTP weiter und damit in die Hose.
Was kann ich noch machen? Jemand ne Idee?
-> der MS TMG 2010 konnte das im übrigen noch... Schade das Sophos es bis heute irgendwie nicht gebacken bekommt
Ja klar 
EDIT: nur zur Vollständigkeit, auch die Source IPs sind natürlich definiert und auf der Firewall hinterlegt (externe public Firewall). Sprich da kommt auch Niemand anderes ran, außer von den genannten Source IPs.
EDIT: nur zur Vollständigkeit, auch die Source IPs sind natürlich definiert und auf der Firewall hinterlegt (externe public Firewall). Sprich da kommt auch Niemand anderes ran, außer von den genannten Source IPs.
Zuletzt bearbeitet:
@fdsonne
Was mir auffällt:
Du gibst ja explizit http:// als real Webserver an, da musst du schon https:// nehmen. Mit dem korrekten Port vom WSUS (https = 8531)
Ich würde da kein SSL offload machen, sondern immer das gleiche Protokoll nehmen.
Dann:
Solltest du https://public.example.com nicht auf dem AD DNS eröffnen, das ist ja dein haupt-DNS für die internen Clients/Server.
Was mir auffällt:
Du gibst ja explizit http:// als real Webserver an, da musst du schon https:// nehmen. Mit dem korrekten Port vom WSUS (https = 8531)
Ich würde da kein SSL offload machen, sondern immer das gleiche Protokoll nehmen.
Dann:
Solltest du https://public.example.com nicht auf dem AD DNS eröffnen, das ist ja dein haupt-DNS für die internen Clients/Server.
Schön wärs, wenn es so einfach wäre. Es macht schlicht keinen Unterschied. Weder HTTP auf TCP 80 noch HTTPS auf TCP 443 als real webserver lassen den Client dort auf HTTPS seinen Kontent anfragen. Es ist auch explizit NUR der Kontent das Problem! Report und Status laufen auf genau dem Port rein, wie beim Client in der Registers eingereiht wird.
Auf der WSUS Maschine sind natürlich die IIS Bindings entsprechend gesetzt. Er hört aktuell sowohl auf den beiden Standardports, als auch 80 und 443 inkl. richtigen Zertifikaten bei den SSL Sachen...
Mich wundert an der Stelle halt, dass die WAF das nicht hinbekommt. Denn offenbar muss die WAF dem Client den Spaß ja mitteilen. Sonst würde ich nicht analog der URL welche als real webserver genutzt wird, im WindowsUpdate.log der Clients Kontentanfragen sehen. Das geht sogar soweit, dass der Client auf der 8530 oder 8531 TCP versucht, den Kontent zu laden (was natürlich nicht geht, wenn die WAF darauf nicht hört, logisch), wenn dies der genutzte Port des real webservers ist. (neben der URL natürlich -> die halt auch nur an der public IP der WAF ankommt, wenn es der public Name wäre, daher der Workaround)
Das Protokoll ignoriert er aber scheinbar...
Rein für mein Verständnis müsste die WAF eigentlich die Antworten vom WSUS zum Client so umschreiben, das der interne Server wie auch das Protokoll und der Port gegen genau dem ausgetauscht werden, was als virtueller Webserver in der WAF eingestellt ist. Machen tut die WAF offensichtlich aber genau das falsche, da sie auf die URL des real webservers umschreibt -> und dabei das Protokoll noch stur auf HTTP setzt.
Das kann es doch nicht sein, wozu brauch ich denn nen Reverse Proxy, wenn genau das irgendwie net lüppt??
Im Moment hab ich das nun so, das ich auf https://wsus.publicdomain.tld:443 anfrage, gleichzeitig der UTM als real webserver durch einen statischen Eintrag von wsus.publicdomain.tld auf die interne WSUS Server IP exakt den gleichen Namen vorgaukel (mit HTTPS auf TCP 443) und zusätzlich den Redirekt auf der WAF aktiviere.
Der Client fragt weiterhin auf http://wsus.publicdomain.tld/content/... an, wird aber auf die 443 redirectet. Damit geht es grundsätzlich erstmal. Aber schön ist anders... denn ich will eigentlich HTTP dort gar nicht sehen, geschweige denn JEDE Kontentanfrage redirecten.
PS: was meinst du mit dem DNS? Was ist mit eröffnen gemeint?
Das AD selbst nutzt zwar eine gekaufte Domain als Namen, ist aber nicht public in use. Die Anfragen auf der WAF kommen auf einem Eintrag rein, wo die Domain ausschließlich public in use ist. Grund ist eigentlich der, ich habe nur für die eine Domain öffentliche Zertifikate. Die UTM kann die AD Domain DNS seitig auflösen -> Forwarder zu einem internen DNS und löst ebenso die public Domain auf -> Forwarder zu unseren public Revolvern. Nur gibt der Revolver ja die public IP aus, nicht die interne WSUS IP, daher der statische Eintrag ich brauch den ja ausschließlich aufgrund des Workaround, siehe oben. Würde die Übersetzung sauber laufen, wäre das nicht notwendig.
Auf der WSUS Maschine sind natürlich die IIS Bindings entsprechend gesetzt. Er hört aktuell sowohl auf den beiden Standardports, als auch 80 und 443 inkl. richtigen Zertifikaten bei den SSL Sachen...
Mich wundert an der Stelle halt, dass die WAF das nicht hinbekommt. Denn offenbar muss die WAF dem Client den Spaß ja mitteilen. Sonst würde ich nicht analog der URL welche als real webserver genutzt wird, im WindowsUpdate.log der Clients Kontentanfragen sehen. Das geht sogar soweit, dass der Client auf der 8530 oder 8531 TCP versucht, den Kontent zu laden (was natürlich nicht geht, wenn die WAF darauf nicht hört, logisch), wenn dies der genutzte Port des real webservers ist. (neben der URL natürlich -> die halt auch nur an der public IP der WAF ankommt, wenn es der public Name wäre, daher der Workaround)
Das Protokoll ignoriert er aber scheinbar...
Rein für mein Verständnis müsste die WAF eigentlich die Antworten vom WSUS zum Client so umschreiben, das der interne Server wie auch das Protokoll und der Port gegen genau dem ausgetauscht werden, was als virtueller Webserver in der WAF eingestellt ist. Machen tut die WAF offensichtlich aber genau das falsche, da sie auf die URL des real webservers umschreibt -> und dabei das Protokoll noch stur auf HTTP setzt.
Das kann es doch nicht sein, wozu brauch ich denn nen Reverse Proxy, wenn genau das irgendwie net lüppt??
Im Moment hab ich das nun so, das ich auf https://wsus.publicdomain.tld:443 anfrage, gleichzeitig der UTM als real webserver durch einen statischen Eintrag von wsus.publicdomain.tld auf die interne WSUS Server IP exakt den gleichen Namen vorgaukel (mit HTTPS auf TCP 443) und zusätzlich den Redirekt auf der WAF aktiviere.
Der Client fragt weiterhin auf http://wsus.publicdomain.tld/content/... an, wird aber auf die 443 redirectet. Damit geht es grundsätzlich erstmal. Aber schön ist anders... denn ich will eigentlich HTTP dort gar nicht sehen, geschweige denn JEDE Kontentanfrage redirecten.
PS: was meinst du mit dem DNS? Was ist mit eröffnen gemeint?
Das AD selbst nutzt zwar eine gekaufte Domain als Namen, ist aber nicht public in use. Die Anfragen auf der WAF kommen auf einem Eintrag rein, wo die Domain ausschließlich public in use ist. Grund ist eigentlich der, ich habe nur für die eine Domain öffentliche Zertifikate. Die UTM kann die AD Domain DNS seitig auflösen -> Forwarder zu einem internen DNS und löst ebenso die public Domain auf -> Forwarder zu unseren public Revolvern. Nur gibt der Revolver ja die public IP aus, nicht die interne WSUS IP, daher der statische Eintrag
ich brauch den ja ausschließlich aufgrund des Workaround, siehe oben. Würde die Übersetzung sauber laufen, wäre das nicht notwendig.
Zuletzt bearbeitet:
Servus, Sorry hatte viel um die Ohren da erst jetzt gelesen.
Zum Thema 50 IPs, vor ca. 2 Jahren hatte ich mich damit beschäftigt. Kumpel und ich hatten als Nebenverdienst die Home Variante genutzt um WLANs im größeren Stil abzudecken (keine Sophos APs), hier war es der Sophos völlig egal in weit dies überschritten war. ( 4stellig) Des Weiteren konnte man via Shell die registrierten IPs reseten und dies via Cron immer wieder ausführen (ohne Leases zu stören etc). Ich möchte nicht ausschließen das hier mitlerweile seitens der FW etwas geändert wurde, aber ich schaue mal im Mailarchiv da müsste ich noch was finden. Mittlerweile mache ich Sophos ausschließlich im Business Bereich wo ich nicht mit der Shell rumspiele
Shell benötige ich im Prinzip nur um den privaten Key zu erstellen, um das SSL Zertifkat zwecks Userportal und Webadmin zu erstellen. Wer sich im Home Bereich dies einrichten möchte, kostenlose mit CA im jedem gängigen Browser gibt es bei WoSign.Ich schaue mal die Tage nach den Shell Befehlen und teste die mal kurz auf einer VM und poste dann das Ergebnis. Rein Interessenhalber, wie weit warst du überschritten und ab wann genau wurden keine Adressen mehr verteilt ? hast du mal die DHCP Log geprüft ? Könntest du mal die Log dazu posten ? Müsste noch in deinem Archiv sein da Default = 90 Tage
Danke für das Feedback.
Tatsächlich ist das bei mir schon länger her. Ich habe da recht großzügig alles, was bei drei nicht auf dem Baum war, angeschlossen. Wenn man zusätzlich zu den 2 Adapter bei 2 Rechnern jeweils eine 4 Port Karte einbaut und viel mit virtuellen Maschines rumspielt, macht man schon große Schritte auf die 50 zu, mit den ganzen anderen Klimbim, wie diverse Mediaplayer, handys, audiobridges, switches, receiver ...
Ich glaube mich zu erinnern, dass der DHCP nicht der einzige Flaschenhals war, sondern dass die Clients nicht mehr geNATtet wurden - also nicht mehr in in Inet kamen.
Bin mir aber nicht mehr sicher.
Huch - habe gerade mal nachgesehen, habe schon wieder 48 in Use.
Davon 8 alleine IPv6. Das sollte ich natürlich abstellen - dadurch ziehen die Geräte ja doppelt soviele IPs wie notwendig an.
Wie gesagt - eine praktikable Abhilfe ist zuächst, DHCP im Client zu deaktivieren und bei Geräten, die nicht nach aussen müssen, keine (oder eine falschen) Gateway einzutragen. Dann erscheinen Sie nicht auf der Zählung der UTM.
Der regelmäßige IP Reset per Cron wäre schon hilfreich, viele der Devices sind ja nicht wirklich dauernd sehr aktiv.
Tatsächlich ist das bei mir schon länger her. Ich habe da recht großzügig alles, was bei drei nicht auf dem Baum war, angeschlossen. Wenn man zusätzlich zu den 2 Adapter bei 2 Rechnern jeweils eine 4 Port Karte einbaut und viel mit virtuellen Maschines rumspielt, macht man schon große Schritte auf die 50 zu, mit den ganzen anderen Klimbim, wie diverse Mediaplayer, handys, audiobridges, switches, receiver ...
Ich glaube mich zu erinnern, dass der DHCP nicht der einzige Flaschenhals war, sondern dass die Clients nicht mehr geNATtet wurden - also nicht mehr in in Inet kamen.
Bin mir aber nicht mehr sicher.
Huch - habe gerade mal nachgesehen, habe schon wieder 48 in Use.
Davon 8 alleine IPv6. Das sollte ich natürlich abstellen - dadurch ziehen die Geräte ja doppelt soviele IPs wie notwendig an.
Wie gesagt - eine praktikable Abhilfe ist zuächst, DHCP im Client zu deaktivieren und bei Geräten, die nicht nach aussen müssen, keine (oder eine falschen) Gateway einzutragen. Dann erscheinen Sie nicht auf der Zählung der UTM.
Der regelmäßige IP Reset per Cron wäre schon hilfreich, viele der Devices sind ja nicht wirklich dauernd sehr aktiv.
Zuletzt bearbeitet:
Wird die UTM jetzt doch weiterentwickelt? Mich verwundert etwas dieser Blogbeitrag https://blogs.sophos.com/2016/02/02/heres-what-to-expect-from-the-upcoming-utm-elevated-9-4/
Dann wäre es cool wenn die Home-Lizenzierung auf Cores/RAM bei der XG dann auch auf die neuen Releases der UTM angewandt würde.
Dann wäre es cool wenn die Home-Lizenzierung auf Cores/RAM bei der XG dann auch auf die neuen Releases der UTM angewandt würde.
dermorph
Enthusiast
- Mitglied seit
- 27.10.2012
- Beiträge
- 1.977
Ich wollte heute auf einem ITX Board mit einem D2550 Sophos UTM in einer VM in Proxmox installieren. Leider hat die Installation eine ewigkeit gedauert. Und danach da Booten war noch langsamer. Ist der Prozessor dafür nicht geeignet?