14.05.2018, aktualisiert am 18.05.2018

3564

Doppelte Gateway IP verhindern

Hallo Administratoren

Ich habe diesbzgl. eine Frage wo mir irgendwie keiner weiterhelfen kann bzw ich nichts dazu finde.
Folgende Hardware wird verwendet:
- Core-Switch: Aruba 2930F 48G 4SFP+ Switch
- Access Switch: MikroTik Cloud Smart Switch

Ich veranstalte mit meinen Kollegen zwei LANs im Jahr.
aktuell haben wir für jeden Sitzblock (20 Teilnehmer) ein seperates VLAN, sodass wenn jemand auf die Idee kommen sollte, sich die IP vom Gateway zu geben, das nur den jeweilige Block lahmgelegt wird.
Jetzt möchten wir aber ein komplettes VLAN für die User machen und möchten verhindert, das jemand sich die IP vom Gateway statisch zuweisen kann und das Netz damit lahmgelegt.
Geht das irgendwie auf dem Core-Switch? Wie gehe ich/wir da am besten vor? ACL?
Also irgendwie Switchseitig blockieren, das diese IP Adresse verwendet werden kann?
Oder das sich jemand nur IPs mit dem DHCP (bei uns aktuell Kea) ziehen kann?

Hoffe man versteht worauf ich hinausmöchte und mir/uns kann jemand weiterhelfen.

Gruß FiRE

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 373803

Url: https://administrator.de/forum/doppelte-gateway-ip-verhindern-373803.html

Ausgedruckt am: 14.04.2025 um 02:04 Uhr

42 Kommentare

Neuester Kommentar

Ja das ist kein Problem, dazu stellst du am Mikrotik auf dem VLAN Interface ARP auf reply only und im DHCP für das VLAN stellst du ein das für Leases ein ARP Eintrag im Mikrotik gesetzt wird, so sind nur DHCP vergebene IPs möglich und keine durch Clients statisch vergebenen. Das verhindert auch gleichzeitig einfache MitM Attacken via ARP Spoofing.

um das ganz total manipulationssicher zu gestalten, müsstest du doch eigentlich mit MAC Adressfiltern arbeiten und selbst die könnte man manipulieren. Mir fällt grad nix anderes ein aber ich finde das Thema recht interessant und bin auf die Antworten gespannt.

TOP das merke ich mir!

ja sicherer geht immer

aber bei 200 Teilnehmern etwas aufwenig :D

@readyplayerone, vielen Dank, das hört sich nach einem gehbaren weg an mit wenig konfigurationsaufwand

.
Werde ich morgen gleich mal testen. Danke!

Das mache ich schon lange so an meinem Wifi-Hotspot, dort sollte das und Client-Isolation Standard sein, eben aus diesen Gründen um den "Beginner-Skriptkiddies" erst mal einen Arschtritt zu verpassen.

weist du ob das die UTM 9 auch kann?

Zitat von @user217:

weist du ob das die UTM 9 auch kann?

k.A. hab ich grad nicht im Zugriff.

Ich veranstalte mit meinen Kollegen zwei LANs im Jahr.

Ich habe hier täglich mehrere "LANs" ! Du meinst vermutlich LAN Partys, oder ?
Mit statischen ARP Einträgen kannst du das wasserdicht nicht verhindern oder musst eben einen erheblich Aufwand treiben.

Das Sinnigste diese Policy durchzusetzen sind Private VLANs oder Isolated VLANs. Die unterbinden generell eine any zu any Kommunikation und lassen nur eine Kommunikation mit dem Upstram zu. Ein ARP Request landet also gar nicht erst bei einem Client.
Allerdings konterkariert das Design ja eine LAN Party wo any zu any ja erlaubt sein muss. So richtig helfen tut dir das also nicht und außerdem supporten die HP Billigswitches dieses Feature vermutlich auch gar nicht.

Helfen würde dir eine Inbound Layer 3 ACL am Accessport die eine Absender IP mit der Gateway Adresse generell blockiert.
Das liesse sich auch noch recht einfach konfigurieren.
Fragt sich nur ob die HP Billiggurken Layer 3 ACLs im Layer 2 Mode supporten wie es bessere Switches ja tun. Aber eine Antwort darauf findet sich sicher im Handbuch.

@aqui
für mich ist der Aruba 2930F 48G 4SFP+ kein billiger Switch ^^.
aber wie mir auffällt, können die Mikrotiks keinen ARP reply only da es sich nur um das swOS handelt.

Also meinst du jetzt eine ACL auf dem Aruba (HP) CoreSwitch?

Und wie würde solch eine ACL dann aussehen?

So? deny 10.10.10.1 255.255.255.0

EDIT: Die User hängen an den Mikrotiks und die Mikrotiks hängen an dem Aruba.

für mich ist der Aruba 2930F 48G 4SFP+ kein billiger Switch

Für das Gros der Netzwerker aber schon. Ist ein billiges Access und SoHo Produkt mit mickriger CPU Performance.

Also meinst du jetzt eine ACL auf dem Aruba

Auf den HP Switches natürlich, denn dort sind ja direkt die User angeschlossen und genau da will man ja schon diese IP abfangen bzw. blockieren.
Dort muss eine Port ACL definiert sein die sämtlichen Traffic mit einer Absender IP die der Gateway IP entspricht blockiert.
Damit ist dann ausgeschlossen das ein Port mit der Gateway IP als Abenderadresse ins Netz kommt bzw. Traffic von dieser.
Der Knackpunkt ist nur das im Layer 2 Mode in dem die HP Gurken ja arbeiten eine L3 ACL am Port arbeiten muss.
Wie gesagt für das Gros der etwas besseren Switches ist das kein Thema aber ob HP das kann musst du checken.
Vielle der billigen Access Switches supporten keine L3 ACLs an L2 Ports.
Sollte aber im Handbuch oder Datenblatt stehen ob die das können.

wie würde solch eine ACL dann aussehen?

Nein !
Im Prinzip richtig aber du hast es syntaktisch falsch angegeben, da du oben eine Netzwerk Adresse ! angegeben hast und keine Hostadresse !! Richtig wäre:
DENY 10.10.10.1 255.255.255.255 any oder Cisco like DENY IP host 10.10.10.1 any

Die User hängen an den Mikrotiks und die Mikrotiks hängen an dem Aruba.
An den Ports wo die Mikrotiks angeschlossen sind könnte ich das ja dann machen und dann würde nur der Block lahmgelegt.

https://community.arubanetworks.com/aruba/attachments/aruba/CampusSwitch ...

Auf seite 439, soetwas?

Hallo,

ein VLAN pro User....

Damit hast du sicher gestellt das nichts schief geht....
Wenn sich einer die Gateway Adresse nimmt, blockt er sich nur selber aus.....

Auf der Console ist das in 5 minuten Konfiguriert... im Web interface ist das Scheiße.

brammer

also sollte gehen:

http://www.arubanetworks.com/techdocs/ArubaOS_61/ArubaOS_61_CLI/ip.htm

ip access-list extended 1
deny any host 10.10.10.1 any

oder mit

ip access-list standard 1

deny host 10.10.10.1

Moin,

also ich denke das der einzige Weg das zu verhindern der von @brammer vorgeschlagene ist.

Das ganze Layer 3-ACL-Gedöns greift doch erst, wenn ARP schon durch ist. D.h. der falsche Host dem Anfragenden schon per ARP Reply mitgeteilt hat, dass er die fragliche IP hat - und wenn beide am selben am gleichen Switch hänge kommt die auch noch vor der Reply des Routers an.(Gleiches gilt für den Vorschlag schon @readyplayerone)

lg,
Slainte

@brammer und @SlainteMhath
mein Ziel war es, alle User in 1 VLAN zu mache, das sie sich auch problemlos im LAN finden in den Spielen. Und euer Vorschlag ist genau das Gegenteil, also ist das nicht die Lösung.

Denke hier ist der Ansatz mit den ACL richtig, da die User an den Access-Switchen angeschlossen sind.
Also wenn die ACL funktioniert, hängt hierbei doch max. der eine Userblock wo die IP des Gateways benutzt wird.

Hallo,

Dein Bestreben das sich keiner die Gateway Adresse nimmt kann man mit ACL umsetzen... aufwe dir und gegen einen Eindringling der sein Handwerk versteht n8cht ganz trivial.

Mit dem Ansatz ein VLAN pro User anzulegen schliesst du ja nicht aus das die sich sehen können... Das nennt man dann Routing... und dein Core Switch ist in L3 ... also eine Routing Device....
Das Segmentieren ist in einem Netzwerk ein Standard....

Wo ist also dein Problem??

Brammer

Ja, ich weiß das es mit L3 Switche geht, nur machen die Spiele das nicht. Außer man hängt de Bridge oder des gleichen dazwischen für den Multi- und UDP Broadcast (geht aber meistens nur mit wenigen VLANs und nicht mit 200). Und das ist mehr Konfigurationsaufwand als nur ne ACL . Wenn ein Block down geht ist das nicht so schlimm wie das alle 200 Teilnehmer nichts mehr machen können.

Werde mir aufjedenfall mal das mit der ACL anschauen, aufjedenfall ist das mit den VLAN pro Userdefinitiv keine Option. Es ist schon sehr umständlich, wenn jeder Block in einem VLAN ist ^^.

Wäre denn die ACL wo ich oben gepostet habe richtig?

VLAN pro User ist ja auch Blödsinn. Für sowas gibt es das Private VLAN oder Isolated VLAN Feature auf Switches was oben ja schon mehrfach genannt wurde.
Das fällt aber eben weg weil du eine Layer 2 Kommunikation brauchst die auch noch Latenz arm ist. All das ist mit deinen einfachen Store and Forward Billigswitches eh nicht realisierbar.
Es bleibt also in der Tat bei der ACL Lösung sofern die HP Gurken L3 ACLs im L2 Mode supporten.
Auch wenn ARP durchgeht unterbindet das dann aber doch wirkungsvoll den IP Traffic mit dieser IP und Endgeräte discovern dann nach einem ARP Timeout eh neu.

Ich werde morgen mal schauen,
also laut dem hier:
http://www.arubanetworks.com/techdocs/ArubaOS%206_3_1_Web_Help/Web_Help ...

können die das.
also etwa so dann:
ip access-list extended 1
deny any host 10.10.10.1 any

Client Isolation? Jup, kann se. Habe ich so im Einsatz.

Nützt nur nichts wie oben schon mehrfach gesagt der er auf eine Client any zu any Kommunikation angewiesen ist wie es bei Ballerspielen ja nun mal so üblich ist...

also etwa so dann:

Nein !
Es reicht auch vollkommen eine Standard IP ACL statt einer Extended. Extended ist für eine reine IP Adress Filterung NICHT nörig !
ip access-list extended 1
deny ip host 10.10.10.1 any

öh ne? Also ich kenne keinen neueren Egoshooter der Client zu Client macht. Die machen alle Client zu Server. Oder habe ich dich falsch verstanden aqui? Normal connecten die Clients ja auf einen Server und der spielt dann Vermittlungsstelle für die Kugeln

Also ich zitiere mal den TO: "Außer man hängt de Bridge oder des gleichen dazwischen für den Multi- und UDP Broadcast..."
Was auch immer er da spielt was dann Multicasting und UDP Broadcasts verwendet ?!
Braucht er das nicht und ist das alles Server zentrisch, dann kommen wieder die Private VLANs ins Spiel.

deny ip gibts laut doku nicht :D daher hatte ich das mit any drin.
Aber ich werd einfach mal direkt in der CLI schauen.
eine permit regel brauch ich ja in diesem fall dann nicht. was ich nicht regle, wird einfach durchgelassen.

@Ex0r2k16
geht allgemein um Spiele (neu und alt), einige machen Client2Server ander Client2Client.
Aber wenn ein Client einen Server aufmacht ist es halt trdm Cient2Client und das das funktioniert (also Ingame Serverbrowser), müssen sich die Clients im gleichen Netz und gleichen VLAN befinden, da die UDP Broadcastabfrage nur im selben Netz/VLAN funktioniert.
Ich will da keine Bridge bauen und jeden UDP Port von den Games pflegen bis das alles funktioniert.
Noch schwieriger wirds ja bei Blizzard-Spielen mit mDNS (Multicast) ... da brauchst dann einen mDNS Server mit gebridgten Interfaces...
Das ganze is ein rießiger konfigurationsaufwand wenn man seperate VLANs macht, ich versuch das schon seit ca. 2 Jahren und es werden leider nicht weniger Spiele. Daher wollen wir jetzt 1 VLAN für die User das sie sich ohne Problem untereinander finden können. Punkt.

aqui hat das schon richtig verstanden

eine permit regel brauch ich ja in diesem fall dann nicht. was ich nicht regle, wird einfach durchgelassen.

Doch, sorry das ging oben unter.
Sowie du eine ACL etablierst ist die Default Regel dann deny any any.
Deine Regel muss dann also vollständig so lauten:
ip access-list extended 100
deny ip host 10.10.10.1 any
permit ip any any
Sorry....

ah sorry! An (dedicated) Servern auf Clients hatte ich jetzt nicht gedacht.

Danke, habe bisher nicht mit ACLs gearbeitet. Nun bin ich schonmal etwas schlauer

Danke! Werde ich so aufjednfall mal testen!

@Ex0r2k16
Ja das is ja der Grund wies man auf ne LAN-Party geht

wies ?? Wies'n ? O'zapft is !

:D:D *wieso

muss die ACL aber aufm Aruba machen, kann es nicht direkt an den Switchen machen wo die User dranstecken^^

kann es nicht direkt an den Switchen machen wo die User dranstecken

Warum nicht ??
Genau DORT müssen die ACLs aber hin ! Logisch, denn nur da machen sie Sinn. Ansonsten hast du das Paket mit der falschen Absender IP ja schon im Netz was dann ziemlich kontraproduktiv ist.

Ich schau mal ob die das können.
https://wiki.mikrotik.com/wiki/SwOS/CSS326#ACL_Tab

Wir haben für die User folgenden Switch:
https://shop.omg.de/mikrotik/cloud-router-switches/mikrotik-cloud-smart- ...

Ich hab mal nachgefragt bei einer anderen LAN-Party, die haben auch die ACLs nicht auf den Switchen der User direkt, aus Kostengründen haben sie sich auch nur solche "dummen" Switche gekauft für die User. Dort funktioniert das also 1A.

Auf den Access-Switchen direkt wär natürlich wirklich am schönsten.

Das mit den ACLs funktioniert so leider nicht.
Habe eine auf dem Aruba und eine auf den Mikrotik agelegt. User mal direkt an die Aruba gehangen. Switchübergreifend etz pp.
leider ohne erfolg.

aus Kostengründen haben sie sich auch nur solche "dummen" Switche gekauft

Wie immer rächt sich sowas dann später ! Siehe auch hier ! Ein typischer Fehler von LAN Party Enthusiasten die nicht nach- und weiterdenken im Netzwerk Bereich

Es gilt wie immer der Satz: "You get what you pay for !"
Deshalb oben auch der Einwand ob deine L2 Switches mit Layer 3 Port Accesslisten umgehen können. Etwas bessere Switches können das logischerweise. Billigheimer wie HP usw. meist nicht.
Nur da ist die ACL aber sinnvoll, denn genau DORT soll ja der Zugriff dieser IP verhindert werden ! Wo auch sonst ?

Auf den Access-Switchen direkt wär natürlich wirklich am schönsten.

...und am sinnvollsten !

leider ohne erfolg.

Da hast du ja dann ganz klar etwas komplett falsch konfiguriert oder eben die Aruba Gurke supportet das nicht.
Solange du hier nicht postest WAS du WO konfiguriert hast können wir natürlich auch nur im freien Fall raten.
Zielführend für eine Hilfe ist das natürlich nicht.
Fazit: Etwas mehr Infos bitte !

also am Mikrotik, wo die User dran hängen, habe ich folgendes konfiguriert:
https://wiki.mikrotik.com/wiki/SwOS/CSS326#ACL_Tab
In den Feldern (siehe Screenshot) habe ich die Gateway IP im Feld IP Src eingetragen, VLAN any und unten Drop angehackt mit, rest leer (womit er any macht). Testweise mal nur mit einem Port, komischerweise gehen die Hits hoch, allerdings auf dem 2. Switch angesteckte PCs können nichts mehr machen.

auf dem Aruba (HP) habe ich folgende ACL angelegt und dem Trunk zugeordnet (mit ip access-list 100 in)
ip access-list extended 100
deny ip host 10.10.10.1 any
permit ip any any

2018-05-17 13_18_37-crs326-acl-table (1861×297)

also am Mikrotik, wo die User dran hängen

Du hast doch gerade noch gesagt die hängen an den HP Gurken ?! Was ist denn nun richtig ?

angehackt

Ne Hacke nutzt man nur im Garten oder hat sie hinten am Fuss. In der IT wäre das ziemlich brutal...

allerdings auf dem 2. Switch angesteckte PCs können nichts mehr machen.

Kein Wunder !
Oben wurde bereits mehrfach darauf hingewiesen das sowie einen ACL auf dem Port aktiv ist dann per Default DENY any any
NACH deiner DENY Regel musst du also logischerweise noch ein PERMIT ip any any konfigurieren damit es klappt.
Lesen hilft...!

Auf dem Aruba ist das OK.

Die User hängen am Mikrotik.
Und die Mikrotik Switche am Aruba.
Also Aufbau sieht so aus: pfSense -> Aruba Switch (Gateway) -> Mikrotik -> UsePC

Auf dem Mikrotik mit nur der genannten ACL funktioniert alles ohne Probleme bis sich jemand die IP des Gateway gibt.

die ACL auf dem Aruba stimmt ja, allerdings funktioniert das trdm nicht, da Switchübergreifend dann auch nichts mehr geht wenn sich jemand die Gateway IP gibt.

PERMIT any any auf dem Mikrotik ändern nichts (auch schon getestet), da es ja nur mit der einen Regel (siehe oben) funktioniert, solang sich niemand die Gateway IP gibt.

Testweise habe ich dann mal ne ACL gebaut (auf den Mikrotik & dem Aruba) die als Source IP das Gateway blockt, das funktioniert.
Also funktionieren ACLs im allgemeinen mal, nur nicht so wie ich mir das vorstelle das er die source IP blockt.

Die User hängen am Mikrotik. Und die Mikrotik Switche am Aruba.

OK, sorry das hatte ich missverstanden.
Dann hast du natürlich Recht, dann müssen die ACLs natürlich auf die MT Ports.
Aber auch hier stellt sich wieder die Frage ob die MTs im Layer 2 (Mac Adress) Modus eine Layer 3 IP ACL am Port abarbeiten können.
Wie gesagt...besser Switches machen sowas problemlos aber bei Billigheimern sollte man da immer in das datenblatt oder Handbuch sehen ob die das supporten.
Meistens können die auch nur L2 ACLs wenn sie selber nur im L2 Modus arbeiten.
DAS musst du sicher vorher klären sonst konfigurierst du dir einen Wolf....

Aruba Switch (Gateway)

Du schreibst "Gateway" ?! Was soll das genau heissen ?? Arbeitet der Aruba Switch hier im Layer 3 Mode, sprich also routet zwischen ggf. vorhandenen VLANs ?
Also die Gateway IP liegt dann auf dem Aruba/HP Switch und ist NICJHT direkt die Gateway IP der pfSense ?
Ist das richtig so ?

Fakt ist aber auf alle Fälle das die L3 ACL an den MT muss, denn genau dort muss dieser Traffic ja schon gefiltert sein. Wenn er dort durchkommt und die Gateway IP die des Aruba/HP Switches ist ist ja logischerweise das Kind schon in den Brunnen gefallen und dann auch vollkommen klar das "nix mehr geht" dann in dem Falle der Dopplung.

Aber auch hier stellt sich wieder die Frage ob die MTs im Layer 2 (Mac Adress) Modus eine Layer 3 IP ACL am Port abarbeiten können.

Also laut der Website heißt es:
An access control list (ACL) rule table is very powerful tool allowing wire speed packet filtering, forwarding and VLAN tagging based on L2,L3 protocol header field conditions.
Sollte also gehen. wahrscheinlich nur falsch aufgebaut.

Aruba Switch (Gateway)

richtig

weshalb ich mir gedacht habe eine ACL am Aruba hilft dabei, das max. der UserBlock nicht geht in dem die Gateway IP verwendet wird.
Der Aruba kann L3 ACLs.

aktuell machen wir ja für jeden UserBlock (a 20 Gamer) ein VLAN, also heißt, wenn sich jemand im Block die Gateway IP gibt, hängt maximal der Block.
Da kann man schonmal besser das Problem lokalisieren. Aber da ist das Problem mit den dedicated Server untereinander halt wieder, weshalb wir 1 VLAN machen möchten.

based on L2,L3 protocol header field conditions....Sollte also gehen. wahrscheinlich nur falsch aufgebaut.

Yepp, das kläet die Sache !
Also L3 ist supportet, was gut ist ! OK, sollte man bei MT auch erwarten...

gedacht habe eine ACL am Aruba hilft dabei, das max. der UserBlock nicht geht in dem die Gateway IP verwendet wird.

Nee, das wäre ja sinnfrei. Da kommt dann eine Absender IP an die die gleiche IP hat wie das L3 Interface des Aruba.
Ersten IST diese IP ja dann schon in dem Netz und kann da sein Unwesen treiben und zweitens nützt es ja nix, denn was willst du da denn filtern ?? Da dann der Aruba und der User PC mit der falschen IP schon um die Wette nach der Mac Adresse ARPen ist das Kind ja schon in den Brunnen gefallen.
Der Switch forwardet so oder so nix dann mit der IP Adresse, kann er ja auch nicht da es auch seine eigenen ist.
Er reportet dann sofort eine Doubled IP Adress als Warning in seinem Syslog oder Logging.
Filtern dort bringt dann herzlich wenig logischerweise.
Vergebe doch die IPs per DHCP und mache DHCP Spoofing im Netz. Damit schliesst du dopplte IPs so gut wie komplett aus in den Segmenten und mit dem DHCP Spoofing auf den Switches gehst du auch auf Nummer sicher das dir keinen einen fremden DHCP dort unterjubelt im User Segment.
Wär ja auch ne Option. OK, verhindert natürlich nicht den Spaßvogel der euch ärgern will und einen RasPi mit der Gateway Adresse ins Netzwerk klemmt und sich einen feixt weil die anderen dann nix mehr machen können...

ha dhcp spoofing hab ich auch mal überlegt. aber is irgendwie schwierig zu konfigurieren.
der DHCP Server, bei uns Kea, läuft zur Zeit im Docker auf einem Server. muss ich dann aif dem Aruba en Relay eintragen? Und die Mikrotik Switche können DHCP snooping,ist das sowas?