Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

MAC conflict op internetlijn met ander subnet

Pagina: 1
Acties:

  • TommyboyNL
  • Registratie: januari 2006
  • Niet online
De afgelopen dagen ben ik bezig geweest met een raar issue bij een klant, waar ik graag wat verdere input/meningen voor ontvang.

Heel in het kort:
Ik had op de internetlijn een MAC adres conflict met een host uit een compleet ander subnet (eerste octet was gelijk, tweede, derde, en vierde octet anders, beiden /24 netwerken). Naar mijn idee moet dit niet kunnen, aangezien een MAC conflict alleen binnen 1 broadcast domain plaats kan vinden, en een gezond netwerkontwerp maar 1 subnet per broadcast domain kent.

In het lang:
Klant heeft een internetlijn van een ISP, welke via glasvezel binnen komt;
Glasvezel -> Media Convertor -> Technicolor router -> L2 VLAN op switch -> FortiGate HA cluster
De Technicolor wilden we er tussenuit hebben, omdat die toch geen toegevoegde waarde heeft (doet NATting en routering). Dit moest gewoon kunnen volgens de ISP, dus de Technicolor er tussenuit gesloopt.
Toen begon de ellende; enorme packetloss. Kabels vervangen, poortinstellingen op de switch nagelopen. Niks raars. Vervolgens een packet capture gedraaid op de Fortigate, en toen brak mijn klomp; Er kwam verkeer binnen dat niet gericht was aan het IP adres van onze klant, maar wel aan het MAC van de firewall van deze klant. Dit tweede IP adres zat echter in een compleet ander subnet. Ik heb geleerd dat je elk subnet in een eigen broadcast domain/VLAN douwt, en tussen verschillende broadcast domains kan je geen MAC conflict hebben.
Aanvankelijk sloot ik dan ook een MAC conflict uit, heb de ISP gebeld met mijn bevindingen, en heb ze uiteindelijk de packet captures gestuurd met de vraag "wat gebeurt hier, en hoe kan dit?".
Uiteraard werd dit opgepakt zoals je zou verwachten, dus had ik na 2 weken nog niks gehoord. Reminder gestuurd. Antwoord van ISP: "Zoals we al zeiden, ligt dit aan uw modem. Wat gebeurt er als u ons modem terugplaatst?" In de geschiedenis van het ticket stond echter al dat dan het probleem weg was. Weer bellen. Na een kwartier werd ik doorgezet naar de tweedelijns, die het ook allemaal niet wist, en het door zou stiften aan hun NOC. Binnen 2 uur zou ik teruggebeld worden. Uiteraard gebeurde dit niet.
Buiten kantooruren maar zelf verder gegaan, en het betreffende firewall cluster een ander MAC adres gegeven (door het cluster ID aan te passen, zie http://help.fortinet.com/...ity/HA_failoverVMAC.htm). Spontaan waren alle issues opgelost.
Dit teruggekoppeld aan de ISP, die daar uiteraard niks mee deed. Ik probeer nu bij de ISP los te peuteren hoe dit heeft kunnen gebeuren, en hoe zij gaan voorkomen dat dit nog een keer gebeurt. De kans is namelijk veel te groot dat dit nog een keer gebeurt (best-case 1:65535, in de praktijk groter omdat er niet veel FortiGates zijn met 235 interfaces), en onze klant weer met een niet-werkende internetlijn zit. De ISP vertikt het echter om dit issue serieus te nemen.
Aan de hand van replies op DNS queries heb ik kunnen achterhalen met welke partij ik een MAC conflict had, maar heb hen nog niet geïnformeerd.

Hoe denken de andere experts hierover? Zie ik problemen die er niet zijn, of had dit inderdaad écht niet mogen gebeuren? Is de ISP te laks? Of doen ISPs zulke exotische dingen op hun netwerken dat ik niet meer moet denken volgens "klassieke" netwerken, maar volgens heel andere concepten?

De ISP in kwestie wil ik (nog?) niet noemen, dus daarnaar vragen heeft geen zin.

Voor de mods: Dit topic valt naar mijn idee zowel onder "Internetproviders en Hosting" als onder "Netwerken". Aangezien dit issue voornamelijk te maken heeft met netwerkconcepten, heb ik hem hier neer gegooid.

  • MewBie
  • Registratie: april 2002
  • Laatst online: 23:28
Een MAC adres hoort toch bij een netwerk interface, behoort uniek te zijn en is ook nog eens merk specifiek?
Dat zou dus betekenen dat iemand of MAC adressen zit te spoofen of de fabrikant apparatuur geleverd heeft met identieke MAC adressen.

Please leave a message after the beep.
*beeeeep*


  • HKLM_
  • Registratie: februari 2009
  • Laatst online: 23:53
Zit hier niet gewoon je probleem?

Buiten kantooruren maar zelf verder gegaan, en het betreffende firewall cluster een ander MAC adres gegeven (door het cluster ID aan te passen, zie http://help.fortinet.com/...ility/HA_failoverVMAC.htm). Spontaan waren alle issues opgelost. In je firewall cluster dus?

Een MAC adres is uniek en vaak per leverancier ook nog. Je ISP doet daar volgens mij al helemaal niks mee...

⛔Trackers of betalen...⛔


  • TommyboyNL
  • Registratie: januari 2006
  • Niet online
MewBie schreef op woensdag 24 oktober 2018 @ 18:15:
Een MAC adres hoort toch bij een netwerk interface, behoort uniek te zijn en is ook nog eens merk specifiek?
Dat zou dus betekenen dat iemand of MAC adressen zit te spoofen of de fabrikant apparatuur geleverd heeft met identieke MAC adressen.
HKLM_ schreef op woensdag 24 oktober 2018 @ 18:20:
In je firewall cluster dus?

Een MAC adres is uniek en vaak per leverancier ook nog. Je ISP doet daar volgens mij al helemaal niks mee...
Zowel de apparatuur van onze klant als de andere conflictant gebruiken virtuele MAC adressen. De twee nodes van het firewall cluster hebben inderdaad per interface een écht MAC adres, maar voor het clusteringprotocol delen ze een roaming virtual MAC adres, wat alleen actief is op de actieve node. Bij een failover stuurt de nieuwe actieve node een aantal promiscous ARPs met dit roaming MAC zodat het verkeer bij de juiste fysieke doos uit komt. Dit proces staat ook beschreven in de link in mijn eerste post.
De ISP doet wel degelijk wat met deze MAC adressen, namelijk het verkeer naartoe sturen.

@KRGT Bonuspunten voor het wél klikken op de link!

  • KRGT
  • Registratie: september 2001
  • Niet online

KRGT

Have a nice day!

Die Mac- adressen worden niet gespoofd @MewBie er is gewoon een andere klant die ook een cluster heeft met een virtual Mac adres. Waarschijnlijk heeft Fortinet dit niet random gemaakt... Zie waarschuwing website waarnaar gelinkt wordt.

Verder kan het zijn dat ze niet vlans gebruiken erg smerig, maar je conclusie klopt wel, kan ook per ongeluk een foute netmask zijn ergens

  • SMSfreakie
  • Registratie: maart 2004
  • Niet online
en zelfs MAC adressen zijn helaas niet uniek... al eens gehad met cheapo moederborden met onboard NIC....

Dell XPS 15-9570, Dell E6440, Custom homeserver C2750 based, HP EliteDesk G4 705 :7


  • drie van acht
  • Registratie: december 2015
  • Niet online
En wat ik vroeger wel zag met el-cheapo Chinese rommel, doen telefoons nu ook en noemen het een "feature": Gewoon wat random bytes als mac instellen. Scheelt toch weer een OUI-registratie, nietwaar.

Maar dit klinkt als dat er meerdere klanten fortinet "virtuele MACs" inzetten aan de ISP-kant. Mij lijkt gebrek aan coordinatie hieraan een beetje slordig. Het is een beetje kort door de bocht maar niet geheel onterecht van de ISP om dan te zeggen "stop onze CPE maar terug" want die presenteert wel een unieke MAC die bovendien door de ISP aangeleverd is. Als dit een zakelijke ISP is dan is het tijd met de account manager even kort te sluiten dat de technische gang van zaken wat te wensen overliet.

De correcte manier is om een gegarandeerd-unieke MAC als "virtuele" MAC te gebruiken, danwel een propere local administration op te zetten van welke niet-zo-unieke-MACs er in gebruik zijn. En dat laatste dan over alle klanten in het broadcast domain, dus een taak van de ISP. Die dus ook die andere klant zal moeten benaderen om hun gebruik van een niet-zo-vreselijk-unieke MAC aan de ISP-kant van hun fortinet. En oh ja, hun aansluitgegevens in het geval van een eigen router bijwerken. Niet dat ik de illusie heb dat een fly-by-night ISP dat allemaal gaat doen, maar het is wel de correcte oplossing.

En nuja, hoe zie je het verschil via DNS-queries? Lijkt me dat je het ziet met ARP-queries.

  • TommyboyNL
  • Registratie: januari 2006
  • Niet online
drie van acht schreef op woensdag 24 oktober 2018 @ 19:37:
En nuja, hoe zie je het verschil via DNS-queries? Lijkt me dat je het ziet met ARP-queries.
Een L3 device houdt alleen ARP entries bij van IP adressen binnen zijn eigen subnet, daar was in dit geval geen sprake van. Een Whois van het andere IP adres leverde alleen op dat het binnen de adresruimte van dezelfde ISP zat.
De identiteit van de andere partij heb ik kunnen achterhalen omdat zij hun DNS niet goed geconfigureerd hadden, en ik replies langs zag komen als "Geen idee welk IP adres bij ldap.bedrijfsnaam.local hoort", of "microsoftdienst.bedrijfsnaam.nl resolved naar 1.2.3.4"

  • The Realone
  • Registratie: januari 2005
  • Laatst online: 18-06 16:07
De ISP is hierin niks kwalijk te nemen, vreemd dat je dat denkt eigenlijk. Zoals aangegeven ben jij nog altijd degene die de fout in gaat door een MAC address te assigned als VMAC. Even bot gezegd dan.

Je kunt dit risico relatief makkelijk indammen door het VMAC zelf aan te passen. Nu heb ik geen ervaring met Fortigates maar het lijkt me sterk dat dit niet zou kunnen. 100% voorkomen gaat je niet snel lukken bij dit soort verbindingen, tenzij je de mogelijkheid hebt 1 van de eigen physical MAC's te gebruiken als VMAC en dat physical MAC te spoofen naar iets anders.

  • TommyboyNL
  • Registratie: januari 2006
  • Niet online
The Realone schreef op woensdag 24 oktober 2018 @ 20:27:
De ISP is hierin niks kwalijk te nemen, vreemd dat je dat denkt eigenlijk. Zoals aangegeven ben jij nog altijd degene die de fout in gaat door een MAC address te assigned als VMAC. Even bot gezegd dan.
Ik vind het anders vrij kwalijk dat de betreffende ISP blijkbaar zo weinig segmentering aangebracht heeft in zijn netwerk, waardoor het kindseenvoudig wordt om verkeer af te luisteren en te spoofen.

  • dutch_warrior
  • Registratie: mei 2005
  • Laatst online: 10-06 09:53
Is wel opvallend inderdaad, maar L3 apparatuur routeert gewoon tussen vlans tenzij er ACL's zijn geconfigureerd zou in dit geval nog niet direct een mac conflict hoeven geven maar wie weet.
Als je infra beetje groot en complex is kan er wel eens een foutje insluipen waardoor je ACL groter bereik
Ik snap dat je hier de betreffende IP's niet kunt plaatsen mogelijk zou daarin een verklaring zitten, je zou haast denken aan een /8 broadcast domain maar dat lijkt me technisch geen reëel verklaring.

Mijns inziens zou de ISP dit wel iets actiever mogen oppakken want men stelt tegenwoordig toch veel vertrouwen in de netwerken van ISP's. Ik hoor zo vaak een IP based filter als maatregel om risico's van unencrypted legacy meuk aan het internet te beperken want: "alleen nation states tappen actief op het internet en als die instanties je verkeer willen zien lukt dat toch wel.". Een technisch onderbouwde verklaring lijkt me hier toch wel op zijn plaats want het riekt een beetje naar configuratie issue maar ik ben totaal niet thuis in wan netwerken en ken zeker de nieuwste routing/aggregatie technieken niet dus misschien is er door de ISP wel een logische uitleg te geven.

  • eric.1
  • Registratie: juli 2014
  • Laatst online: 22:33
The Realone schreef op woensdag 24 oktober 2018 @ 20:27:
De ISP is hierin niks kwalijk te nemen, vreemd dat je dat denkt eigenlijk. Zoals aangegeven ben jij nog altijd degene die de fout in gaat door een MAC address te assigned als VMAC. Even bot gezegd dan.
Mah, dat is wel heel makkelijk gesteld. Een ISP heeft ook gewoon nog een beschermende rol. Als je als afnemer door wat MAC-spoofingen verkeer van andere binnen kan krijgen, dan doe je het gewoon verkeerd als ISP - dat is gewoon te voorkomen. Daar kan je echt niet omheen.

Dat het niet handig is gedaan door deze twee bedrijven, dat is een ander verhaal.

  • TheGhostInc
  • Registratie: november 2000
  • Niet online
[...]

[Voor 99% gewijzigd door TheGhostInc op 25-10-2018 00:19. Reden: Geen zin]


  • Yordi-
  • Registratie: december 2016
  • Niet online
..

[Voor 99% gewijzigd door Yordi- op 08-11-2018 12:47]


  • ik222
  • Registratie: maart 2007
  • Niet online
Tja als je apparatuur gebruikt waarbij (zij het dan virtuele) MAC adressen makkelijk niet meer uniek kunnen zijn dan kan dit gebeuren. Dan nog is de kans in de praktijk heel klein en heb je dus in zeker zin pure pech gehad maar het kan dus wel. Het is niet voor niets zo dat MAC adressen uniek moeten zijn.

Als ISP kun je dit alleen voorkomen als je alle klanten in een volledig apart L2 domein hebt zitten. In de praktijk is dat zelden het geval omdat dat lastig uit te rollen is op grote schaal. Wat je dus vaak ziet zijn netwerken waarin klanten in hetzelfde L2 domein zitten maar waarin direct L2 verkeer tussen klanten onderling tegengehouden wordt (als het netjes is ingeregeld). Echter voor de access router van de ISP (en daarmee voor jou) is er dan nog steeds een probleem als binnen hetzelfde L2 domein twee klanten met hetzelfde MAC adres zitten.

Nogmaals, MAC adressen moeten gewoon uniek zijn en de ISP mag daar vanuit gaan (los van wat spoofing beveiliging). Als jij apparatuur gebruikt waarbij dat op wat voor manier dan ook niet het geval is dan loop je het risico dat er dingen niet goed werken. Dat kan je de ISP niet direct verwijten.

  • Ben(V)
  • Registratie: december 2013
  • Laatst online: 00:39
Je configuratie is gewoon fout.
Je mag een fortinet HA cluster niet zomaar aan het internet leggen.

Virtuele mac adressen moet je binnen je broadcast domain houden en doordat je die technicolor eruit gehaald hebt is het internet je broadcast domain geworden.

Er moet een L2 afscheiding komen.

En het ligt uiteraard niet aan de ISP, die verwacht een echt geldig mac adres van jouw kant en niets virtueel wat met een willekeurig in gebruik zijnd macadres kan clashen.

En buiten dat dit niet mag/kan is het ook nog tamelijk unsecure.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • Kabouterplop01
  • Registratie: maart 2002
  • Laatst online: 20-06 10:10

Kabouterplop01

chown -R me base:all

Ik had op de internetlijn een MAC adres conflict met een host uit een compleet ander subnet (eerste octet was gelijk, tweede, derde, en vierde octet anders, beiden /24 netwerken
ik snap niet wat je wilt zeggen.
zodra het 2e, 3e en 4e "octet" anders zijn is er geen conflict.

  • Ben(V)
  • Registratie: december 2013
  • Laatst online: 00:39
Hij had een mac conflict en geen ip conflict dus dat subnet doet er niet toe.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • ewoutw
  • Registratie: oktober 2013
  • Laatst online: 19-06 20:07
De fortinet is een virtueel MAC toch?? Geen echte. Volgens mij heeft het technicolor modem nog steeds de taak om het broadcastdomein te scheiden. Als er 2 of meer mensen bij de zelfde ISP dit doen ga je rare shit krijgen....
Pagina: 1


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True