Hi Community en met name de Ziggo medewerkers in deze community 🙂
TL/DR: Kan het zijn dat met het onderhoud in Ziggo gebied Haarlem Oost van afgelopen maandag nacht er iets is gewijzigd in de DHCP server die klanten in bridge mode van een IP adres moet voorzien? Ik krijg met mijn Palo Alto Firewall met geen mogelijkheid een IP adres meer. Met een Linux laptop reachtstreeks op het modem lukt het wel, maar ook alleen net nadat de Connectbox geboot is. Het belangrijkste verschil in het DHCP DISCOVER request is de bootp-flag die aangeeft of de server dmv een broadcast of unicast packet zal moeten gaan antwoorden. Packet captures beschikbaar op verzoek...
Long story:
Afgelopen paar jaar heeft mijn Internet verbinding prima gewerkt. Ik gebruik bridge-mode op het Connectbox modem met een Palo Alto firewall achter het modem.
In de nacht van 2 op 3 mei is er Ziggo-onderhoud geweest bij mij in de wijk (Haarlem Oost). Sindsdien werkt mijn Internet verbinding niet meer. Meestal moest ik na onderhoud even een DHCP-RELEASE en DHCP-RENEW doen waarbij de verbinding weer tot stand kwam. Andere keren moest ik het modem toch even uit zetten en weer aan, maar altijd lukte het om de verbinding weer tot stand te brengen. Dit keer niet, ik kreeg de verbinding met geen mogelijkheid meer up.
Wat in een packet capture zie is dat er op de DHCP DISCOVER vanuit mijn Firewall geen DHCP OFFER vanuit het modem terug komt. Gisteren heb ik de hele dag met Ziggo support geprobeerd het probleem op te lossen, hierbij zijn alle stappenplannen doorlopen en alle hoepels doorsprongen, een greep:
- Modem afkoppelen van alles, wachten, opnieuw aansluiten en booten (geen resultaat)
- Modem terug naar fabrieksinstellingen (geen resultaat)
Ik had nog een Connectbox liggen die niet door Ziggo was terug gevraagd na bandbreedte upgrade jaren geleden. Toen bleek dat dit modem geen hairpin-nat ondersteunde ben ik terug gegaan naar het oude modem (toen dus nog in routing mode) en is de connectbox blijven liggen. Dus toen support voorstelde een modem-swap te doen, hebben we dit modem gebruikt.
Na de modemswap en het modem naar fabrieksinstellingen te hebben gezet kwam er wel een Internetverbinding tot stand. Goed nieuws! Maar helaas van korte duur, het modem geeft in de WebGUI niet de mogelijkheid om bridge-mode aan te zetten. Vanuit support wordt aangegven dat dit aan het modem zou kunnen liggen waardoor een nieuwe modemswap wordt voorgesteld door een modem bij de Ziggo winkel te halen. Bij het aansluiten van het nieuwe modem, dit keer type Connectbox Giga komt de verbinding weer niet goed tot stand en is ook de optie om het modem in bridge-mode te zetten niet beschikbaar.
Weer support gebeld (het is inmiddels einde van de middag), er moest nog wat geactiveerd worden en ik moest het na een half uur nogmaals proberen, dan zou alles goedkomen. Dat deed het dus niet. Weer geen verbinding, dus ik weer bellen. Deze medewerkster wist te vertellen dat het activeren van een modem tot 24 uur kan duren, dus of ik daar dan maar op wilde wachten. Ze zou het in de gaten houden en me vandaag nog nabellen (niet gebeurd).
Vandaag bij thuiskomst om 15:30 bleek het modem toch een Internetverbinding te hebben opgezet, dus hoera, we komen weer verder. Maar ook nu weer geen optie om bridge-mode aan te zetten. Zonder bridgemode heb ik niet veel aan de verbinding. Dus wederom met support gebeld. Op afstand is toen bridgemode aangezet. Met de testlaptop op poort 1 van het modem lukt het nu om een (public) IP adres te krijgen (zelfs een IPv6 adres, wat voorheen nooit werkte in bridgemode, dus daar ga ik als het IPv4 stuk opgelost is ook naar kijken).
Met het erugplaatsen van de verbinding naar mijn firewall is er echter nog steeds met geen mogelijkheid een antwoord te krijgen op de uitgestuurde DHCP DISCOVER packets.
Analyse van de DHCP DISCOVER packets van de linux laptop en de Palo Alto firewall laten zien dat in de BOOTP-flags bij de linux laptop het broadcast bit uit staat. Of wel, de DHCP server wordt verzocht met een unicast packet antwoord te geven. De Palo Alto stuurt het DHCP DISCOVER packet uit met het broadcast bit in de BOOTP flags aan. Ofwel de DHCP server zal met een broadcast packet antwoord moeten geven. Of dit ook de oorzaak van het probleem is weet ik niet, maar het is wel een cruciaal verschil. Wellicht heeft het onderhoud van afgelopen week iets in de DHCP werking gewijzigd aan Ziggo kant.
Ook ben ik bel benieuwd of het nu aanbieden van dualstack in bridgemode in mijn wijk met het onderhoud van eergisteren is aangezet, aangezien ik dat voor het eerst langs zie komen (ik zit in oud UPC gebied en daar werd het tot voor kort nog niet uitgerold begreep ik uit een andere thread).
Heel verhaal, maar bottomline is dat ik na anderhalve dag nog steeds geen werkend internet heb, dus ik hoop dat er inzicht gegeven kan worden in waarom het DHCP proces met mijn Firewall nu niet meer werkt.
PS De WiFi backup over 4G die ik bij Ziggo afneem doet het op zich wel, maar heeft maar 5Mbit down en 2Mbit up en voldoet dus alleen maar voor het hoogst noodzakelijke. Ik had verwacht dat hier meer bandbreedte op beschikbaar zou zijn. Is de 4G bandbreedte van de WiFi backup oplossing geknepen?