Station sperren

Forum für allgemeinen Fragen zum Thema IPv6 mit LANCOM Routern

Moderator: Lancom-Systems Moderatoren

Antworten
Avalanche
Beiträge: 182
Registriert: 19 Mai 2012, 23:53

Station sperren

Beitrag von Avalanche »

Wie kann ich eine Station daran hindern über IPv6 mit dem Internet zu kommunizieren? Es wird stateless autoconfiguration verwendet. Unter IPv4 verwende ich hierfür die MAC-Adresse. Wie geht das unter IPv6?
Benutzeravatar
stefanbunzel
Beiträge: 1404
Registriert: 03 Feb 2006, 13:30
Wohnort: endlich VDSL-250

Re: Station sperren

Beitrag von stefanbunzel »

Hallo Avalanche,

vor dem gleichen Problem stand ich auch und habe es wie folgt gelöst:

Ohne DHCPv6 geht es scheinbar nicht, da bei stateless autoconfiguration das Gateway die anderen IPv6-Geräte nicht kennt und somit die Firewall nicht filtern kann.
Theoretisch könnte es gehen, wenn man die Client-ID's (ähnlich MAC-Adresse) kennen würde (aber woher...). Aber ich habe in der IPv6-Firewall unter Stations-Objekte kein Feld für Client-ID gefunden... :(

Daher habe ich im Gateway DHCPv6 aktiviert und arbeite dort mit IPv6-Reservierungen zu bekannten Client-ID's.
Dann einfach in der IPv6-Firewall die Deny-All-Regel aktivieren und entsprechende Allow-Regeln für ein- und / oder ausgehenden Traffic für die vorher angelegten Stations-Objekte (lt. reservierter IPv6-Adrese) definieren.

Ich hoffe, das hilft dir weiter?

Viele Grüße, Stefan
GS-2326, 1783VAW, R883VAW, 1781A, 831A, 1781EF+, L-452agn, L-32x, L-54(ag/dual), 1711(+), 1511, 821(+), 3850, 3050, IL-11/2, VP-100 ..., Optionen: CF, PS, WLC
LCS WLAN
Avalanche
Beiträge: 182
Registriert: 19 Mai 2012, 23:53

Re: Station sperren

Beitrag von Avalanche »

Vielen Dank für den Hinweis. Ich werde das probieren. Funktioniert das auch, wenn man vom Provider umnumeriert wird (oder passiert das in der Realität nicht)?

Ich hoffe, dass das UI für diesen Bereich noch etwas überarbeitet wird und die Dokumentation um ein paar Beispiele erweitert wird. Gerade das UI ist schon sehr minimalistisch gestaltet.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Station sperren

Beitrag von backslash »

Hi stefanbunzel,
Aber ich habe in der IPv6-Firewall unter Stations-Objekte kein Feld für Client-ID gefunden...
Dafür ist in der Stationstabelle der Typ "Host-Identifdier" da. Um von der MAC-Adresse auf den Identifier zu kommen mußt du noch die EUI-64 Wandlung machen:

Aus der MAC-Adresse 01:23:45:67:89:ab wird dabei der Identifier 0123:45ff:fe67:89ab (zwischen drittem und viertem Byte der MAC-Adresse werden die Bytes 0xff und 0xfe eingefügt.

Gruß
Backslash
Avalanche
Beiträge: 182
Registriert: 19 Mai 2012, 23:53

Re: Station sperren

Beitrag von Avalanche »

Ich hoffe doch, dass sich hier dringend noch etwas am UI tut! Wenn ich http://technet.microsoft.com/en-us/libr ... s.10).aspx richtig verstehe, ist es sogar noch ein Stück komplizierter:
To obtain an IPv6 interface identifier from an IEEE 802 address, you must first map the IEEE 802 address to an EUI-64 address, and then complement the U/L bit.
[...]
Host A has the Ethernet MAC address of 00-AA-00-3F-2A-1C. First, it is converted to EUI-64 format by inserting FF-FE between the third and fourth bytes, yielding 00-AA-00-FF-FE-3F-2A-1C. Next, the U/L bit, which is the seventh bit in the first byte, is complemented. The first byte in binary form is 00000000. When the seventh bit is complemented, it becomes 00000010 (0x02). The final result is 02-AA-00-FF-FE-3F-2A-1C which, when converted to colon-hexadecimal notation, becomes the interface identifier 2AA:FF:FE3F:2A1C. As the result, the link-local address that corresponds to the network adapter with the MAC address of 00-AA-00-3F-2A-1C is FE80::2AA:FF:FE3F:2A1C.
Man muss also als Nutzer nicht nur wissen, an welcher Stelle das FFFE eingebaut werden muss, sondern auch noch wie danach das Komplement gebildet werden muss. Finde nur ich so etwas unintuitiv?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Station sperren

Beitrag von backslash »

Hi Avalanche,

sorry, das invertieren des Locally-Administered-Bit hatte ich ganz vergessen...
Da das erste Byte einer (echten) MAC-Adresse immer 00 ist wird somit aus einer MAC-Adresse 00:xx:xx:yy:yy:yy der Identifier 02xx:xxFF:FEyy:yyyy

Gruß
Backslash
Avalanche
Beiträge: 182
Registriert: 19 Mai 2012, 23:53

Re: Station sperren

Beitrag von Avalanche »

So richtig klar ist es mir trotzdem noch nicht, was ich für das Stationsobjekt angeben muss. Angenommen, die MAC ist D8:A2:5E:8B:11:11. Nach der Formel wäre das dann daa2:5eff:fe8b:1111. Echte MACs beginnen nicht immer mit 00:, so dass man beim Bit-Flippen leider rechnen muss.

Wie muss ich also mein Stationsobjekt anlegen? Das Präfix kenne ich ja an der Stelle nicht, da es bei der Einwahl dynamisch zugeteilt wird.
Benutzeravatar
stefanbunzel
Beiträge: 1404
Registriert: 03 Feb 2006, 13:30
Wohnort: endlich VDSL-250

Re: Station sperren

Beitrag von stefanbunzel »

Hallo Backslash,
backslash hat geschrieben:Dafür ist in der Stationstabelle der Typ "Host-Identifdier" da. Um von der MAC-Adresse auf den Identifier zu kommen mußt du noch die EUI-64 Wandlung machen:
Das hatte ich auch schon gehofft bzw. vermutet - aber selbst noch nicht getestet.
Allerdings ist dann in LANconfig die Eingabemaske unter Firewall -> IPv6-Regeln -> Stations-Objekte... -> Host-Identifier äußerst unglücklich gewählt, dass im einzigst verbleibenden Eingabefeld unter LCOS 8.84 nur "Adresse: ::/0" (zur weiteren Verwirrung in WebConfig: "Adresse: ::/64") steht, so dass man davon ausgeht, dass hier auch wirklich nur eine IPv6-Adresse und keine Host-Identifier eingegeben werden kann. Außerdem wird in den übrigen IPv6-Dialogen im LCOS immer die Bezeichnung "Client-ID" verwendet, so dass es auch dadurch zu Verwirrungen kommt. Zu guter Letzt schweigt sich auch noch die LANconfig-Hilfe zum Adress-Feld vollständig aus, dass hier Host- bzw. Client-ID einzutragen wären. Dort ist nur vin IP46-Adressen die Rede.

Und als Letztes stellt sich mir die Frage, warum dieses Feld in der Firewall überhaupt Host-ID und nicht Client-ID heißt, denn bei IPv6 würde ich aus Sicht des IPv6-Gateways doch immer davon ausgehen, dass alle anderen IPv6-Geräte "Clients" sind - oder nicht?

Viele Grüße,
Stefan
GS-2326, 1783VAW, R883VAW, 1781A, 831A, 1781EF+, L-452agn, L-32x, L-54(ag/dual), 1711(+), 1511, 821(+), 3850, 3050, IL-11/2, VP-100 ..., Optionen: CF, PS, WLC
LCS WLAN
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Station sperren

Beitrag von backslash »

Hi stefanbunzel,
Allerdings ist dann in LANconfig die Eingabemaske unter Firewall -> IPv6-Regeln -> Stations-Objekte... -> Host-Identifier äußerst unglücklich gewählt, dass im einzigst verbleibenden Eingabefeld unter LCOS 8.84 nur "Adresse: ::/0" (zur weiteren Verwirrung in WebConfig: "Adresse: ::/64") steht, so dass man davon ausgeht, dass hier auch wirklich nur eine IPv6-Adresse und keine Host-Identifier eingegeben werden kann.
Du mußt den Identifier dort auch in Form einer IPv6-Adresse angeben, nämlich ::1234:5678:90ab:cdef/128, wobei das /128 entfallen kann - genaugenommen wird es ignoriert, weshalb dort auch /0 oder /64 stehen kann... Das führende :: darf dabei aber nicht entfallen.
Außerdem wird in den übrigen IPv6-Dialogen im LCOS immer die Bezeichnung "Client-ID" verwendet, so dass es auch dadurch zu Verwirrungen kommt.
Client-ID taucht meines Wissens nur im Zusammenhang mit DHCPv6-Adreßreservierungen auf - und bezeichnet dort die GUID anhand der der jeweilige Client erkannt wird (die GUID des LANCOMs als DHCPv6-Client findet sich unter /Status/IPv6/DHCPv6/Client/Client-ID - und leitet sich aus der MAC-Adresse ab...)
Und als Letztes stellt sich mir die Frage, warum dieses Feld in der Firewall überhaupt Host-ID und nicht Client-ID heißt
Weil es sich nunmal nur um "einfache" Hosts handelt, die in keiner Client/Server-Beziehung zum LCNCOM stehen...

Gruß
Backslash
Avalanche
Beiträge: 182
Registriert: 19 Mai 2012, 23:53

Re: Station sperren

Beitrag von Avalanche »

Du mußt den Identifier dort auch in Form einer IPv6-Adresse angeben, nämlich ::1234:5678:90ab:cdef/128, wobei das /128 entfallen kann - genaugenommen wird es ignoriert, weshalb dort auch /0 oder /64 stehen kann... Das führende :: darf dabei aber nicht entfallen.
Verstehe ich das richtig, in meinem Beispiel müsste ich also ::daa2:5eff:fe8b:1111/128 eintragen, um mich auf den Host mit der MAC D8:A2:5E:8B:11:11 zu beziehen? Da sehe ich noch deutliches Verbesserungspotential bei der Usability.

Privacy Extension spielen nur bei der Bildung der IPv6-Adresse eine Rolle, aber nicht beim Host Identifier, oder?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Station sperren

Beitrag von backslash »

Hi Avalanche,
Verstehe ich das richtig, in meinem Beispiel müsste ich also ::daa2:5eff:fe8b:1111/128 eintragen, um mich auf den Host mit der MAC D8:A2:5E:8B:11:11 zu beziehen?
die /128 kannst du dir sparen, es reicht also ::daa2:5eff:fe8b:1111
Da sehe ich noch deutliches Verbesserungspotential bei der Usability.
man mag jetzt über das zusätzliche :: argumentieren - es gab hier damals auch eine hitzige Diskussion, die am Ende zu dem Schluß kam, daß es besser ist, für Präfixe und Identifier immer die vollständigen Schreibweise (also mit folgenden bzw. führendem "::") zu verlangen...

Hier wäre höchstens eine expliztite Angabe von MAC-Adressen - wie bei der IPv4-Firewall - noch sinnvoll
Privacy Extension spielen nur bei der Bildung der IPv6-Adresse eine Rolle, aber nicht beim Host Identifier, oder?
Der Host-Identifier ist das einzige, was sich in diner IPv6-Adresse sinnvoll ändern läßt... Daher ist der Nutzen der Privacy Extension auch eher fraglich, denn der Präfix ist konstant (wodurch du wieder Identifizierbar wirst) und es wird nur regelmäßig der Identifier geändert

Gruß
Backslash
Benutzeravatar
stefanbunzel
Beiträge: 1404
Registriert: 03 Feb 2006, 13:30
Wohnort: endlich VDSL-250

Re: Station sperren

Beitrag von stefanbunzel »

Hallo Backslash,
backslash hat geschrieben:Hier wäre höchstens eine expliztite Angabe von MAC-Adressen - wie bei der IPv4-Firewall - noch sinnvoll
Genau! Bitte mal als Wunsch aufnehmen und im nächsten LCOS umsetzen. Danke!

Stefan
GS-2326, 1783VAW, R883VAW, 1781A, 831A, 1781EF+, L-452agn, L-32x, L-54(ag/dual), 1711(+), 1511, 821(+), 3850, 3050, IL-11/2, VP-100 ..., Optionen: CF, PS, WLC
LCS WLAN
Avalanche
Beiträge: 182
Registriert: 19 Mai 2012, 23:53

Re: Station sperren

Beitrag von Avalanche »

Halllo Backslash,
backslash hat geschrieben: man mag jetzt über das zusätzliche :: argumentieren - es gab hier damals auch eine hitzige Diskussion, die am Ende zu dem Schluß kam, daß es besser ist, für Präfixe und Identifier immer die vollständigen Schreibweise (also mit folgenden bzw. führendem "::") zu verlangen...

Hier wäre höchstens eine expliztite Angabe von MAC-Adressen - wie bei der IPv4-Firewall - noch sinnvoll
interessant, dass Du gerade diesen Punkt herausgreifst. Diese Schreibweise IMHO das kleinste Problem an dieser Stelle. Bitte verstehe mich nicht falsch, ich möchte das Lancom UI nicht schlecht machen. Viel mehr würde ich gerne das Usability Argument aus meiner Erfahrung als Produktmanager bzw. Softwareentwickler betrachten. Ich bitte kleine Ungenauigkeiten in der IPv6-Terminologie zu verzeihen. Diese ist mir noch nicht ins Blut übergegangen.

Mit Usability-Problemen meinte ich nicht, dass man hier ein :: voranstellen muss! Wie Du selbst schon schreibst kommt das aus Überlegungen der Konsistenz. Das Problem ist hier, dass bei diesem Dialog anscheinend ein Wettbewerb stattgefunden hat, wie man mindestens sechs Usecases mit möglichst wenigen Textfeldern abdecken kann. Den Fall, dass schlicht ein Feature zur Konvertierung von Mac-Adressen fehlt, lasse ich hier erst mal außen vor.

Es wäre hier IMHO wesentlich sinnvoller gewesen sich stärker auf die Anwendungsfälle zu konzentrieren und für diese ggf. eigene Dialoge zur Verfügung zu stellen. Meiner Erfahrung nach sind Dialoge mit abwechselnd aktiven Eingabeelementen sowohl für die Nutzer schwer zu verstehen als auch extrem kompliziert zu beschreiben. Ersteres beruht darauf, dass der Nutzer mit mehr UI-Elementen konfrontiert wird als er für sein gedankliches Modell der Problemstellung benötigt und erst einmal beides in Einklang bringen muss. Zweiteres ist ein strukturelles Problem: Beschreibt man die Use Cases in der Dokumention sequentiell (also doch wieder aufdröseln?) oder beschreibt man nur die UI und verweist dann darin auf die Anwendungsfälle. Dadurch muss man dann mit bedingten Aussagen arbeiten ("Füllen Sie Gegenstelle mit x wenn Fall a oder mit y wenn Fall b"). Bedingte Aussagen sind sperrig, müssen vom Nutzer erst einmal durchdacht werden und hinterlassen oft einen neuen Satz Fragen.

Ein möglicher Grund für einen kombinierten Dialog wäre vielleicht, dass sich der Benutzer später umentscheiden können soll und dann natürlich nicht alle Eingaben neu machen möchte. Aber passiert das hier wirklich? Will der Benutzer wirklich die Option haben von jedem der sechs Einträge des Dropdowns zu den jeweils fünf anderen zu wechseln? Ich kann mir nicht vorstellen, dass ein Benutzer mit der Anlage eines Benamten Netzes anfängt und dann aber doch die Werte ohne Neueingabe in einen Host-Identifiers konvertieren möchte. In seinem gedanklichen Modell sind dies sicherlich zwei verschiedene Aufgabenstellungen. Auch geben eine solche Konvertierung die UI-Elemente -- trotz der aktuellen Implementierung -- überhaupt nur in wenigen Fällen wirklich her. Damit scheidet also auch dieser Grund für den gewählten Ansatz aus.

Natürlich spielen bei UI-Design auch immer Stil- und besonders Ressourcenfragen eine Rolle. Aber gerade die Hostdefinition ist einer der zentralen Bestandteile einer Firewall. Alleine schon, weil diese ja auch immer als Quelle/Ziel einer Regel auftauchen. Mit anderen Worten: Hier muss das UI sitzen!

Hinzu kommen noch Probleme mit den Begrifflichkeiten. Kann ::daa2:5eff:fe8b:1111 wirklich eine Adresse sein, wenn ich den Wert in das Feld eines Host-Identifiers eintrage? Dieser Begriff wird auch im Fehlermeldungs-Tooltip verwendet, ohne mir dabei im Fehlerfall bei der Eingabe zu helfen. Warum gibt es beim Host-Identifier eine Maske (die dann auch noch ignoriert wird)? Wenn ich schon eine Adresse angeben muss, welches Präfix? Ist ein Präfix beim Host-Identifier wirklich sinnvoll? Ein UI sollte den Benutzer immer bei seiner Problemstellung anleiten und Fehleingaben so möglichst weit verhindern.

Jetzt ist der Beitrag doch etwas länger geworden, aber ich hoffe, ich konnte meine Position mit Hintergrundinformationen unterfüttern und meine Gedankengänge zu diesem Thema verdeutlichen. Wenn Du möchtest, können wir diesen Punkt gerne auch außerhalb dieses Threads weiter vertiefen und diskutieren. Ich würde mich jedenfalls freuen, wenn ich zur Verbesserung der Usability einige Denkanstöße geben könnte.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Station sperren

Beitrag von backslash »

Hi Avalanche,

ich muß dir leider sagen, daß ich für LANconfig gar nicht zuständig bin...

auf dem CLI sieht diese Tabelle wie folgt aus:

Code: Alles auswählen

Name                              Type                    Local-network     Remote-peer/local-host                                            Address/Prefix
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ANYHOST                           Prefix                                                                                                      ::/0
LOCALNET                          Local-network
RASCLIENTS                        Remote-peer                               RAS-TEMPLATE
IDENTIFIER                        Identifier              INTRANET                                                                            ::1234:5678:9ab:cdef
ADDRESS                           IP-Address                                                                                                  2001:db8::1234
Da ist das Ganze schon übersichtlicher. Ich persönlich hätte am liebsten auch noch auf die Spalte "Remote peer/local host" verzichtet und das alles in die Adress/Prefix-Spalte geschrieben, denn die Bedeutung der Spalte wird ja durch den Typ angegeben, aber da hieß es, das wäre schlechtes Design... Die Spalte Local-Network ist hingegen nicht überflüssig, weil sie eine Beschränkung des Gültigkeitsbereichs darstellt, wie im "INDENTIFIER"-Beispiel zu sehen...


i.Ü. gebe ich dir Recht, daß der Zwang in LANconfig eine Prefixlänge angeben zu müssen, nicht gerade sinnvoll ist - besonders weil LANconfig bei der automatischen Erweiterung doch recht kreativ ist (mal wird mit /0, mal mit /64 erweitert). Ich hab dazu mal einen Bugeintrag gemacht...

Gruß
Backslash
Benutzeravatar
Chaosphere64
Beiträge: 103
Registriert: 16 Jul 2014, 10:55

Re: Station sperren

Beitrag von Chaosphere64 »

Sorry, dass ich diesen Thread noch mal exhumiere, aber ich habe noch ein Problem mit dem Sperren von Stationen über IPv6. Ich habe zwar alle Hosts, die ich potentiell vom Internetzugang aussperren möchte nun nach einer MAC-EUI64 Konvertierung (hier ein Online Tool dafür) als Stations-Objekte in der Firewall und kann entsprechende Regeln erstellen, ABER:

Aufgrund der Vergabe und Benutzung von Temporary Addresses für den Internetzugang durch Windows, Mac OS X etc. nutzt mir das nichts, weil die Source IP sich dann ja nicht mehr aus der MAC Adresse berechnen lässt. Fazit: Ich müsste dieses Verfahren auf den Clients abstellen, womit ich die dann immer manuell konfigurieren muss und den Benutzern ein wichtiges Sicherheitsfeature von IPv6 raube. Korrekt oder habe ich einen Denkfehler da drin?
Antworten