MAC conflict op internetlijn met ander subnet

[TommyboyNL]

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]

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_]

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...

[TommyboyNL]

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.

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

[Vorkie]

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]

en zelfs MAC adressen zijn helaas niet uniek... al eens gehad met cheapo moederborden met onboard NIC....

[drie van acht]

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]

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]

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]

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]

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]

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]

[...]

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

[Yordi-]

..

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

[ik222]

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)]

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.

[Kabouterplop01]

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)]

Hij had een mac conflict en geen ip conflict dus dat subnet doet er niet toe.

[ewoutw]

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....