1
Vraag
2
Reacties
PatrickTe

Level 2
  • 7Posts
  • 0Oplossingen
  • 2Likes

Sagemcom modem IPv6 en IPv4 broadcasts vanaf 1.178.168.192 naar adres 224.0.0.1

Sinds ik dit nieuwe Sagemcom modem (SmartWifi Modem (Zwart)) in gebruik heb valt het volgende me op:

- Iedere 3 seconden een ICMPv6 broadcast van het IPv6 modem adres naar ff02::1

- iedere 9,5 minuut een ICMPv4 broadcast van het omgekeerde modem adres (1.178.168.192) naar 224.0.0.1 (afzender MAC Adres is van het modem)

 

Hebben meer mensen hier "last" van? Ben bang dat 99% van de mensen hier geen last van hebben maar mijn pfSense firewall loopt vol met logging en IPv6 logging stil leggen werkt niet. (IPv6 wil ik niet aanhebben)

 

Zou graag zien dat dit vreemde verkeer niet op mijn netwerk voorkomt zonder dat ik daarvoor het modem of in bridgemode moet zetten of de firewall van het modem hiervoor zelf in zou moeten zetten.

Aanzetten van de firewall zorgt er namelijk voor dat de portforwards niet meer werken op dit modem.

 

Zie ook attachment

 

Oplossing

Geaccepteerde oplossingen
Rikst
Community Moderator
Community Moderator
  • 5213Posts
  • 495Oplossingen
  • 1699Likes

Hi @PatrickTe 

Hier even een update, er is een ticket gelogd voor dit probleem. Er is op dit moment verder nog geen concrete info bekend. 

Bekijk in context

15 Reacties 15
tobiastheebe

Level 20
T.E.A.M.
  • 31519Posts
  • 2218Oplossingen
  • 15803Likes

Het ICMPv6-verkeer is Router Advertisement (multicast), dit kan niet worden uitgeschakeld. Ik weet niet uit mijn hoofd wat het ICMPv4-verkeer is, in ieder geval ook multicast, niet broadcast. Ik zou simpelweg IPv6 uitschakelen op de WAN-interface, als je dit (nog) niet wil gebruiken.

 

Bij gebruik van een eigen router is bridge mode gebruiken sterk aanbevolen, waarom wil je dit niet gebruiken? Dit heeft namelijk een aantal voordelen t.o.v. router achter router en dubbele NAT.

PatrickTe
Topicstarter
Level 2
  • 7Posts
  • 0Oplossingen
  • 2Likes

Dank je wel voor je snelle reactie.

 

Was al bang dat het dit soort IPv6 verkeer zou zijn alleen is om de 3 seconden wel een heel erg hoge frequentie.

Maar het 1.178.168.192 afzender adres waar multicasts vandaan komen met het MAC adres van het ziggo modem vind ik echt heel vreemd.

Misschien dat ik een keer overstap naar bridge mode maar voorlopig nog niet.

Ga voor nu verdere pogingen doen om mijn logging weer schoon te krijgen binnen pfSense

 

tobiastheebe

Level 20
T.E.A.M.
  • 31519Posts
  • 2218Oplossingen
  • 15803Likes

Wat betreft de 3 seconden: dit blijkt het absolute minimum te zijn dat wordt ondersteund door radvd. Ik ben het met je eens dat dit een hoge frequentie c.q. kort interval is, maar het is bedoeld om clients zo snel mogelijk online te laten komen via IPv6. Via RA wordt namelijk de prefix (/64) verzonden die clients gebruiken om via SLAAC een adres op te bouwen. Tevens wordt met RA verwezen naar de DHCPv6-server voor bijvoorbeeld de DNSv6-servers met de O (other config) flag.

 

Wat betreft het ICMPv4-verkeer: 224.0.0.1 is all hosts, vergelijkbaar aan ff02::1 (all nodes). Vermoedelijk is het de eRouter van het modem die zichzelf presenteert als UPnP-geschikt. Dit IPv4-verkeer kun je dus mogelijk stoppen door UPnP uit te schakelen.

 

Bij gebruik van bridge mode kan dit multicast-verkeer (gedeeltelijk) verdwijnen, omdat routers van DHCPv6 gebruik moeten maken om de IA_NA en IA_PD op te halen.

PatrickTe
Topicstarter
Level 2
  • 7Posts
  • 0Oplossingen
  • 2Likes

Duidelijk verhaal, steeds meer redenen om het modem in bridge mode te zetten.

Wat betreft 1.178.168.192 --> 224.0.0.1 (all-systems.mcast.net) UPnP staat bij mij na aanzetten van het ziggo modem gelijk uit. Dus nee die staat zeker weten niet aan.

En dan zou ik 192.168.178.1 --> 224.0.0.1 verwachten niet dat vreemde 1.178.168.192 non private IP adres

 

tobiastheebe

Level 20
T.E.A.M.
  • 31519Posts
  • 2218Oplossingen
  • 15803Likes

Om zeker te weten wat het ICMPv4-verkeer precies is, zou je verder moeten analyseren met een PC met Wireshark direct op de modemrouter aangesloten.

 

Het 'omgedraaide' IP-adres is waarschijnlijk het gevolg van een reverse DNS lookup.

PatrickTe
Topicstarter
Level 2
  • 7Posts
  • 0Oplossingen
  • 2Likes

Nee sorry, in-addr.arpa DNS entries ken ik tot in den treuren , ben alleen niet zo bekend met IPv6. Dit 1.178.168.192 adres komt van dit modem en is toevallig ook het omgekeerde van 192.168.178.1 maar het gaat in de logging 100% zeker om het 1.178.168.192 adres niet om een in-addr.arpa DNS representatie hiervan.

Ben bang dat er iemand bij het maken van de firmware voor dit modem heeft zitten slapen. en een paar octeteten in een verkeerde volgorde heeft neergezet.

Zal de screenshot van de packetcapture meesturen

tobiastheebe

Level 20
T.E.A.M.
  • 31519Posts
  • 2218Oplossingen
  • 15803Likes

Is het niet zo dat in de logging automatisch reverse DNS lookups gedaan worden? Dat het verkeer van de eRouter van het modem afkomstig is, daar twijfel ik ook niet aan.

PatrickTe
Topicstarter
Level 2
  • 7Posts
  • 0Oplossingen
  • 2Likes

Nee helaas, dit is rauw zonder DNS resolven van adressen. Dus dit is echt afkomstig van dit adres (tenminste lokaal gefaked natuurlijk door het modem) want het orginele 1.178.168.192 bevind zich in Australie

Random

Level 16
  • 2161Posts
  • 101Oplossingen
  • 1125Likes

Ik heb dat ook wel eens gehad in mijn pfSense logs.

Meestal als ik een DNS probleem had.

 

Ik heb lang geleden een floating block rule gemaakt voor dat multicast  verkeer.

 

Guido64_0-1672667108133.png

 

 

efok

Level 17
  • 4027Posts
  • 219Oplossingen
  • 1600Likes

@PatrickTe   Je wireshark capture zijn idd absoluut rauwe data. Het lijkt me dat je bug nr zoveel in de sagemcom hebt gevonden.

Ben ook wel benieuwd waarom je ipv6 niet aan wilt hebben by the wsy?

PatrickTe
Topicstarter
Level 2
  • 7Posts
  • 0Oplossingen
  • 2Likes

@Ziggo Wel weer jammer dat ik een voor mij zeer irritant probleem als opgelost moet zien door de opmerking " Het lijkt me dat je bug nr zoveel in de sagemcom hebt gevonden." als oplossing aan te merken. Had gehoopt dat er een productowner of iets dergelijks van deze firmware zich hier over zou gaan buigen. Maar dan bedenk je jezelf weer eens er zijn nog zoveel andere problemen die opgelost moeten worden. Dan valt deze nog reuze mee misschien, voor mij niet maar vergeleken met de rest natuurlijk wel.

Jos
Community Moderator
Community Moderator
  • 1351Posts
  • 206Oplossingen
  • 711Likes

Terechte melding @PatrickTe ik heb hem op de agenda gezet bij mijn collega's voor onderzoek. Het gaat mijn pet wel wat te boven als het op technisch vlak aan komt. Ik snap jouw gedachte ook dat het probleem misschien niet zo groot is, het is wel belangrijk dat het aangekaart en opgelost wordt. Zodra ik meer informatie heb van mijn collega's, dan koppel ik dit hier terug. 

PatrickTe
Topicstarter
Level 2
  • 7Posts
  • 0Oplossingen
  • 2Likes

Dank je wel Jos voor het in ieder geval bij je collega's onder de aandacht brengen. 

En nu hopen dat er geen andere grotere problemen zijn in de firmware die eerder opgelost moeten worden.😋

Rikst
Community Moderator
Community Moderator
  • 5213Posts
  • 495Oplossingen
  • 1699Likes

Hi @PatrickTe 

Hier even een update, er is een ticket gelogd voor dit probleem. Er is op dit moment verder nog geen concrete info bekend. 

bdtim

Level 1
  • 1Posts
  • 0Oplossingen
  • 0Likes

Jouw 'vanaf' adres is gewoon je modem in het omgekeerd (192.168.178.1) - lokaal verkeer en dus niets met Australie te maken.

Waarom het IP adres omgekeerd staat, geen idee, maar heb ik wel eens eerder in IT mogen tegenkomen.

 

E-mail notificaties
Aan Uit

Ontvang een update bij nieuwe reacties in dit topic.

Uitgelicht topic