Waarom zie ik deze ipv6 adressen op mijn subnet?

[Gogolathome]

Hieronder zie je een dump van verkeer tussen twee ipv6 hosts dat te zien is op mijn vlan 200 subnet.

Volgens mij heb ik niets verkeerd geconfigureerd maar ik heb moeite om het te interpreteren. Zou het kunnen zijn dat de source iets verkeerd heeft gedaan met zijn subnets?

De source en destination zijn wel twee Ziggo adressen.

VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:18	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:17	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:17	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:17	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:17	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:17	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:17	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:319	[2001:1c03:4003:202:1804:6098:8b18:d49d]:319	udp	Default deny / state violation rule	
VL200		2025-02-17T11:06:17	[2001:1c03:4003:203:c638:75ff:fe24:a6c8]:320	[2001:1c03:4003:202:1804:6098:8b18:d49d]:320	udp	Default deny / state violation rule

[tobiastheebe]

Het IPv6 GUA 2001:1c03:4003:203:c638:75ff:fe24:a6c8 is opgebouwd m.b.v. EUI-64, dus is eenvoudig naar een fabrikant te herleiden: Sonos. UDP 319 en 320 worden gebruikt voor Precision Time Protocol (PTP). Het is dus verkeer vanaf een Sonos-apparaat in VLAN 200 naar een apparaat in een ander VLAN c.q. andere /64. Dat apparaat maakt gebruik van een randomized GUA (meestal het geval bij ingeschakelde SLAAC privacy extensions), dus het kan een PC, smartphone of tablet zijn.

[Gogolathome]

Je krijgt toch van Ziggo een /56 subnet? En daaruit hoor je zelf /64 subnets maken om vlan/lan te scheiden? Dat traffic van anderen hoor ik toch niet te zien als het goed is?

[tobiastheebe]

Dat klopt, de delegated prefix vanuit Ziggo is een /56 in fZiggo of een /57 in fUPC, waarmee resp. 256 of 128 /64 (V)LAN's aangemaakt kunnen worden.

Er is geen sprake van "traffic van anderen". Jouw delegated prefix is 2001:1c03:4003:200::/56. De GUA's in de geplaatste firewall log vallen in twee verschillende /64's (2001:1c03:4003:202::/64 en 2001:1c03:4003:203::/64) binnen deze /56.

[Gogolathome]

Bedankt, het probleem is eigenlijk dat het NIET binnen mijn delegated prefix valt. Dus waarom zag ik het, want het is nu weg trouwens

[tobiastheebe]

Ik heb geen ervaring met Sonos en PTP, dus een directe verklaring heb ik niet. Mogelijk is jouw prefix in de tussentijd veranderd, aangezien dit inter-VLAN traffic was. Dergelijk verkeer ga je niet van een ander(e) klant/netwerk zien. Daar komt nog bij dat VLAN's zeldzaam zijn thuisomgevingen.

[Gogolathome]

Tja, ik weet er waarschijnlijk nog minder van, maar ik vermoed met mijn beperkte kennis dat die "andere" met subnet 2001:1c03:4003:20::/56 een verkeerde instelling heeft gehad op zijn LAN waardoor zijn Sonos over heel het subnet uit zat te zenden en dat dit traffic gezien werd op mijn subnet.

[tobiastheebe]

Het verkeer dat de log laat zien speelt zich allemaal achter een router af en blijft binnen dezelfde delegated prefix. Het is totaal niet logisch als dat verkeer op internet terecht zou komen én dan ook nog eens op jouw router zou binnenkomen (een firewall blokkeert normaliter 'by default' alle nieuwe inkomende verbindingen vanaf internet, dit geldt ook voor OPNsense) én naar het specifieke VLAN (200) gerouteerd zou worden. Dit is m.i. gewoon verkeer dat zich op jouw eigen netwerk voordeed.

[Gogolathome]

Dat klopt, je ziet ook de regel die actief is: default deny / state violation rule

Het is ook niet logisch, de twee IP adressen zijn volgens mij gewoon verkeer dat langskomt op mijn VLAN 200 interface (die ziet dat dus) en de twee IP adressen komen niet uit mijn netwerk, want niet eens uit mijn subnet dat ik van Ziggo heb gekregen, dus kunnen ook niet binnen mijn netwerk met SLAAC gegenereerd zijn.

Maar wat als die twee IP adressen bij de eigenaar daarvan met bv een /48 of een nog lager subnet geconfigureerd zijn? Dan stuurt een router dat toch langs het hele /48 subnet?

[tobiastheebe]

Prefixes zijn bij Ziggo altijd /56 of /57 voor particuliere klanten, alleen bij Zakelijk Internet Pro worden /48's toegewezen. Zowel het externe IPv4-adres als de IPv6 prefix kunnen bij Ziggo (helaas) spontaan veranderen zonder bericht vooraf.

[Gogolathome]

Jammer, we begrijpen elkaar niet meer vrees ik. Ik heb in ieder geval weer wat geleerd van je.

[tobiastheebe · Accepted solution]

Ik heb er zo direct geen andere verklaring voor.

[caesar]

@tobiastheebe, @Gogolathome 

Bizar, dat PTP protocol. Dat werkt alleen met speciale ethernet interfaces. PTP verkeer wordt in de interface onderschept en direct aan de CPU doorgegeven, helemaal buiten de IP stack om.

[Gogolathome]

Dat is zeker iets dat niet binnen mijn netwerk gebeurt!