Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.
Hallo, mehr zum Thema siehe hier: https://forum.vodafone.de/t5/Ger%C3%A4te/Bridge-Mode-funktioniert-pl%C3%B6tzlich-nicht-mehr-Technik-Support/m-p/3058330
Problem ist, dass ich scheinbar keine DHCP Antwort bekomme, wenn nicht in DHCP Option 60 was eingetragen ist. Das passt genau zu meinem aktuellen Verhalten der Box. Wie realisiert man das?
Hmmm - jetzt bin ich etwas verwirrt. DHCP-Optionen werden i.d.R. beim DHCP-Server eingetragen und nicht beim Client. Dieser wertet die Optionen -welche im bei der Anmeldung am Server übermittelt werden- lediglich aus, falls er diese benötigt (so gehört z.B. in die 60 der Vendor_Class_Identifier). Wenn die Sophos als DHCP-Server arbeitet, kann man diese Optionen dann selbstverständlich auch einstellen und nutzen aber wenn die Sophos z.B. am WAN-Anschluß nur als DHCP-Client arbeitet, kenne ich keine Möglichkeit hier irgenwelche DHCP-Optionen einzurichten. Diese wäre dann auf dem DHCP-Server Deines Providers einzutragenn, bzw. wenn deine Vodafonekiste für das Transfernetz Kiste -> Sophos als DHCP-Server arbeitet. Allerdings verstehe ich den Sinn des Gnazen noch nicht, die Sophos braucht die Option 60 nicht.
Guten Tag, scheinbar haben Sie den verlinkten Artikel nicht gelesen. Mir ist die Option gänzlich egal, aber Vodafone hat bei seinen CMTS das so integriert, dass es benötigt wird, sonst kommt keine Antwort auf eine DHCP-Anfrage und man kommt im Bridge Mode nicht online. Das kann man auch schön im TCPDump beobachten. Insofern stellt sich für mich die Frage nicht, ob ich das will oder nicht. Mein Provider sagt es braucht das und da werde ich als kleines Lichts eher nichts dran ändern...
Hallo K-M,
Im verlinkten Artikel wird immer nur vom "Router" gesprochen, wo diese Option einzutragen wäre. Ob das der ISP-Router oder der eigene (ASUS war das wohl) sein soll, kann ich nicht zu 100% feststellen.
Die Information, dass eine DHCP-Option bei der DHCP-Antwort und nicht bei der Anfrage gesendet wird, kenne ich auch nicht anders.
... und falls es so etwas doch gibt ... ist es mit hoher Sicherheit in der Sophos Firewall nicht implementiert.
Übrigens, seit wann vergibt Vodafone Adressen per DHCP ohne sich zu Authentifizieren? Haben Sie mal ein paar mehr Informationen zum Anschluss?
Dirk
Systema Gesellschaft für angewandte Datentechnik mbH // Sophos Platinum Partner
Sophos Solution Partner since 2003
If a post solves your question, click the 'Verify Answer' link at this post.
Funktionieren denn die "Basics", also der einfache Router-mode des ISP-Routers?
Was spricht gegen diesen?
Dirk
Systema Gesellschaft für angewandte Datentechnik mbH // Sophos Platinum Partner
Sophos Solution Partner since 2003
If a post solves your question, click the 'Verify Answer' link at this post.
Könnte man nutzen, allerdings Double NAT, das ist für mich keine Option. Sowas mache ich nur, wenn es gar nicht anders geht und da ist bei uns derzeit das einzige Beispiel Telekom Hybrid. Ansonsten braucht das kein Mensch...
Die Anpassung ist so minimal, dass es Sophos hinbekommen sollte. Ich habe schon einen Würgaround organisiert (Fake MAC Adresse etc.), das ist allerdings auch nichts für professionell und dauerhaft.
Effektiv unterstützt der SFOS DHCP Client das aber nicht. Weil es auch kaum praktische Anwendungszwecke dafür gibt.
DHCP Optionen als Client anzufragen ist etwas, was DHCP Clients häufig machen - Die Firewall ist per se auch nur im WAN (in der Regel) ein DHCP Client (wenn überhaupt). Sehr wenige ISPs benötigen dieses Flag, das macht aus der Großen Anzahl an "betroffenen Usern" nur einen kleinen Anteil.
Das der Router von Vodafone das beherrscht, liegt daran, dass es seine Aufgabe ist - Vodafone macht das (scheinbar?) so.
Siehe: https://linux.die.net/man/5/dhclient-options
option vendor-class-identifier string;This option is used by some DHCP clients to identify the vendor type and possibly the configuration of a DHCP client. The information is a string of bytes whose contents are specific to the vendor and are not specified in a standard. To see what vendor class identifier clients are sending, you can write the following in your DHCP server configuration file:
set vendor-string = option vendor-class-identifier;
This will result in all entries in the DHCP server lease database file for clients that sent vendor-class-identifier options having a set statement that looks something like this:
set vendor-string = "SUNW.Ultra-5_10";
The vendor-class-identifier option is normally used by the DHCP server to determine the options that are returned in the vendor-encapsulated-options option. Please see the VENDOR ENCAPSULATED OPTIONS section later in this manual page for further information.option vendor-encapsulated-options string;The vendor-encapsulated-options option can contain either a single vendor-specific value or one or more vendor-specific suboptions. This option is not normally specified in the DHCP server configuration file - instead, a vendor class is defined for each vendor, vendor class suboptions are defined, values for those suboptions are defined, and the DHCP server makes up a response on that basis.
Some default behaviours for well-known DHCP client vendors (currently, the Microsoft Windows 2000 DHCP client) are configured automatically, but otherwise this must be configured manually - see the VENDOR ENCAPSULATED OPTIONS section later in this manual page for details.
Aber dieser Eintrag wurde nie in SFOS implementiert.
__________________________________________________________________________________________________________________
Mag sein, ist aber eine "normale" in Deutschland beheimatete Business ISP Konfiguration bei einem der größten Provider. Insofern reden wir hier ja nicht davon, dass es ein regionaler Provider ist mit 5000 Kunden...
Das ist fast wie beim Thema LE. Da wird auch seitens Sophos immer erklärt warum das anders gut ist etc.
Ich bin der Meinung so funktioniert aber nicht die Entwicklung eines guten Produktes. Wenn es von Kundenseite einen sinnigen Grund oder auch Wunsch gibt, dann sollte man doch dem Kunden folgen, wenn es auf der eigenen Seite wenig technischen Deep Dive benötigt. Und ich vermute fast, dass es genau aus dem von dir beschriebenen Grund (Firewall ist eigentlich fast nur in diesem Fall DHCP Client) auch keinen großen Impact hat die Veränderung standardmäßig einzubauen.
Ich habe vor kurzem noch einen anderen Bug entdeckt, jetzt wurde mir schon gesagt, dass es auch sein kann, dass man statt dem Fehler zu beheben unter Umständen eher die ganze Funktion ausbaut. Das ist doch die Kapitulation vor dem Kunden und auch dem eigenen Produkt? Habe das letztlich auch schon beim Hotspot tatsächlich erlebt. Statt es ordentlich zu bauen (defekte Sortierung, nicht funktionierende Spalten) hat man lieber einfach die Sortierung nach anderen Kriterien als dem Ticket ganz ausgebaut und nur die eine Spalte notdürftig gefixt.
Mein Verständnis was ich als Kunde für mein Geld bekommen sollte (gerade bei Enhanced plus) ist scheinbar einfach anders, das habe ich leider bereits feststellen dürfen.
Ich kann das aufschlüsseln. Sophos hat über 500.000 Kunden weltweit. Dazu kommen noch entsprechend Home User. Diese Anzahl an Kunden und Home User haben entsprechend einen Bedarf an Features. Dieser Bedarf vom Markt wie auch Entwicklungen auf dem Markt in neue Technologien bildet eine Roadmap von Dingen, die Sophos erledigen möchte mit dem Produkt SFOS. Wenn nun ein Feature als Feature Request aufkommt, betrachtet man, woher der Bedarf kommt, wieviele potentielle Kunden das betrifft und wieviele "Neu Kunden" man damit auch erwerben könnte. Wie jeder (Software) Hersteller hat auch Sophos nur limitierte Ressourcen und Kapazitäten, um neue Features zu implementieren. Daher wird hier mit einer Priorität gearbeitet.
LetsEncrypt ist auf der Roadmap - Es ist nicht "ignoriert" sondern eben auf einer Roadmap mit einem wahren Wert dahinter - Das bedeutet Sophos sieht, dass Kunden (in der Regel kleiner Kunde mit einem bestimmten Use Case), dieses Feature anfragen.
Auf der Anderen Seite ist nun diese Thematik das erste mal, dass ich davon höre, dass es ein Kunde benötigt - Das bedeutet es ist Status = Creation of FR. Nach dem Erstellen eines FR wird automatisiert betrachtet, wieviele Kunden benötigen das Feature noch. Bis es dann vom Produkt Management als Feature auf die Roadmap oder den Backlog genommen werden kann.
Betrachten wir nun die Entwicklung eines neues Features. Egal um was es geht, es muss folgendes gemacht werden: Es muss ein PoC geschrieben werden, danach wird getestet, ob es überhaupt funktioniert. Sobald das grundsätzliche Feature funktionieren "könnte", wird der Code betrachtet, wie man diesen Implementieren kann. Dabei wird betrachtet, welche Organisationen in Sophos müssen mit inkludiert werden - Zum Beispiel muss es in den Webadmin oder CLI only? Nachdem das gemacht wurde, kann das Feature erst entwickelt werden. Nach der Entwicklung wird es vollständig getestet und in allen Q&A Prozesse mit eingegossen.
Bei so etwas wie diesem Feature, auch wenn es klein ist, könnte Sophos potentiell alle DHCP Client Konfigurationen zerstören. Man stelle sich vor, das Feature wird implementiert und die Migration von DHCP WAN Interfaces kann nicht korrekt migriert werden und alle Firewalls gehen danach offline. Gerade aus dem Grund wird aus so einem "einfachem Change" plötzlich ein Monster, was man nicht mal eben "zwischen zwei Kaffee Pausen" implementieren kann.
Es ist natürlich Schade, wenn ein Feature entsprechend im Produkt einen Fehler aufweist, zu betrachten ist da jedoch, wie es sich weiter entwickelt. Die Entscheidung, etwas nicht zu beheben oder komplett wieder zu entfernen, wird vom Produkt Management in der Regel getroffen, um die Roadmap nicht zu beeinflussen. Auch hier wird betrachtet, wieviele Kunden haben es gemeldet, wieviele Kunden haben das Problem etc.
Manche Dinge werden in der nächsten Version gelöst und angepasst, manche Dinge verschieben sich oder werden, wie in deinem Fall, wieder entfernt.
__________________________________________________________________________________________________________________
Auf der Anderen Seite ist nun diese Thematik das erste mal, dass ich davon höre, dass es ein Kunde benötigt - Das bedeutet es ist Status = Creation of FR. Nach dem Erstellen eines FR wird automatisiert betrachtet, wieviele Kunden benötigen das Feature noch. Bis es dann vom Produkt Management als Feature auf die Roadmap oder den Backlog genommen werden kann.
Kann ansonsten bei einigen Dingen durchaus dem Vortrag folgen, aber nicht bei dieser Option. War unter ideas.sophos.com jahrelang gelistet (weiß natürlich nicht mit wie vielen Stimmen, ist ja offline) und auch hier im Forum gibt es mind. 2 Threads dazu (auch Jahre alt)... Wenngleich ich natürlich auch wiederum nicht weiß, ob jemand einen Case dazu geöffnet hat. Und konkret zum Thema Implementierung bei dieser Option: wenn ich die optional mache und der Kunde es aktivieren muss, wüsste ich nicht woran es bei bestehenden Konfigurationen scheitern sollte. Bei anderen Dingen bin ich da bei dir, aber nicht bei konkret einer einzigen Option, die ich ja auch als optional belassen kann und somit am Bestand genau nichts ändere.
Ich geb dir im übrigen auch noch das Gegenbeispiel wo Sophos selbst sich dann nicht an seine von dir hier vorgetragene Maxime hält: im Application Filter. Wir hatten dort Regeln, die jahrelang funktioniert haben und plötzlich hat man die Zuordnung geändert, wodurch einige Dienste (bei uns im Besonderen AD Authentifizierung) nicht mehr durch den Tunnel gelaufen sind. Oder man konnte dann plötzlich aus den Zweigstellen keine IPSec Tunnel mehr aufbauen, weil ISAKMP VPN diese blockiert (jahrelang vorher nicht).
Dann sollt man an diesen Stellen dann auch so ehrlich sein und die Kunden ebenso darüber informieren.
Das ist allerdings ein bisschen OT, insofern schauen wir mal was das Ticket letztlich macht...
Es ist auch weiterhin auf der Roadmap relativ weit oben gelistet.
Ideas.sophos.com ist kein Indicator für eine Roadmap und war es auch nie. ideas.sophos.com war eine ältere Idee, um öffentlich auch zusätzlich Features zu sammeln und Interesse zu finden. Die große Herausforderung an ideas.sophos.com war - Home User und Kunden (jeder Größe) hatten die gleiche Anzahl an Stimmen. Plus: Niemanden hat einen Benutzer daran gehindert, mehrfach abzustimmen - bzw. neue Accounts zu erstellen.
LE auf der Ideas.sophos.com war DAS Home Feature. Weil es primär für die WAF genutzt wurde. Spricht man mit vielen größeren Kunden, haben die in der Regel ein Zertifikat erworben (mit den Features, die es mitbringt). Als Home Benutzer kann ich es verstehen, dass LE sich durchgesetzt hat. Auch kleinere Kunden (Zum Beispiel Desktop) ist LE sehr interessant.
Aus dem Grund befindet sich LE auch in auf der Roadmap für die Zukunft und wird nicht als "nicht interessant" abgestempelt.
Bezüglich der DHCP Option. Wenn du einem Benutzer die Option gibst, die aktuell nicht anpassbar DHCP Client Config zu editieren, baust du auch automatisch einen Prozess, der diese Datei auch anfassen kann. Damit kann sehr viel "schiefgehen".
Ich möchte nur zur verstehen geben, jede noch so kleine Änderung im System (Sub System) wird eine Änderung bei über 500k Kunden bedeuten. Und um es nochmal abzuschließen - Sophos muss dafür Ressourcen ablegen, QA, Entwicklung, PoC etc.
Dein Beispiel ist die App Control, die von Sophos Labs gebaut wird. App Control kann, auch wenn es unangenehm ist, immer wieder ein FP beinhaltet. Wir veröffentlichen immer einen Release Post für die App Control und die Änderungen: Application Control
Auch haben wir die Release Notes für die App Control hier: https://doc.sophos.com/releasenotes/output/en-us/nsg/ApplicationFilterSummary.html
Ich gehe davon aus, wir werden für diesen Kunden aufgrund deines Support Cases einen internen Feature Request eröffnen und das damit nachverfolgen, ob weitere Kunden danach fragen und entsprechend verfolgen.
__________________________________________________________________________________________________________________
Spricht man mit vielen größeren Kunden, haben die in der Regel ein Zertifikat erworben (mit den Features, die es mitbringt)
Haben wir auch, aber die sind nun mal mittlerweile auch nur noch maximum 1 Jahr gültig und dann nehme ich auch lieber LE mit automatischer Erneuerung, fertig. Ich habe auch nicht gesagt "ignorieren" und auch nicht "nicht interessant". Es gibt nur eine andere von dir vorgeschlagene Lösung, die einfach für KMU nicht passt, insofern muss das noch besser werden.
Die große Herausforderung an ideas.sophos.com war - Home User und Kunden (jeder Größe) hatten die gleiche Anzahl an Stimmen. Plus: Niemanden hat einen Benutzer daran gehindert, mehrfach abzustimmen - bzw. neue Accounts zu erstellen.
OK, kann ich mit, aber trotzdem waren da auch super Sachen für gewerbliche User drin und davon ist vieles nicht umgesetzt. Ich kann von Größe 5-500 einigermaßen mitreden in unserem Konsortium...
Ich möchte nur zur verstehen geben, jede noch so kleine Änderung im System (Sub System) wird eine Änderung bei über 500k Kunden bedeuten. Und um es nochmal abzuschließen - Sophos muss dafür Ressourcen ablegen, QA, Entwicklung, PoC etc.
Ist immer noch klar, aber wenn wir es selbst könnten, würden wir es ja auch machen, dafür zahlen wir Geld ;)
Dein Beispiel ist die App Control, die von Sophos Labs gebaut wird. App Control kann, auch wenn es unangenehm ist, immer wieder ein FP beinhaltet. Wir veröffentlichen immer einen Release Post für die App Control und die Änderungen: Application Control
Ah, super, das war doch hilfreich, auf die Idee bin ich nicht gekommen dort zu schauen.
