Vodafone Bridge Mode erfordert DHCP Option 60 auf WAN

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.

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?

K-M said:

scheinbar haben Sie den verlinkten Artikel nicht gelesen.

Oha ... das ist jetzt ja schon frech!

dirkkotte said:

Die Information, dass eine DHCP-Option bei der DHCP-Antwort und nicht bei der Anfrage gesendet wird, kenne ich auch nicht anders.

Bei Oracel-Solaris kann man wohl so etwas basteln

Relativ finde ich, denn dort ist der Kontext klarer, daher die Verlinkung. Letztlich aber auch ein bisschen dem Frust geschuldet, dass immer jeder seinen eigenen "Scheiß" produziert.

Funktionieren denn die "Basics", also der einfache Router-mode des ISP-Routers?

Was spricht gegen diesen? 

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.