Mijn netwerk devices krijgen dhcp adres van KPN modem ipv UDM Pro

De DHCP server op de FB zou aan moeten blijven staan voor alle apparaten die op de FB zijn aangesloten, inclusief de UDM. Anders zullen deze apparaten na het verstrijken van de geldigheid van hun IP adres een 169.* adres kunnen krijgen en dus geen verbinding meer met internet kunnen maken...
 
Het enige dat ik uiteindelijk heb gedaan, is de DHCP op het FB modem tijdelijk uitgeschakeld.Daarna weer geactivieerd en sindsdien krijgt mijn USWFlex en Wifi Pro geen ip meer van FB DHCP. En ik heb alle apparaten met uitzondering Van de TV setopox op de UDM Pro aangesloten.
 
Het enige dat ik uiteindelijk heb gedaan, is de DHCP op het FB modem tijdelijk uitgeschakeld.Daarna weer geactivieerd en sindsdien krijgt mijn USWFlex en Wifi Pro geen ip meer van FB DHCP. En ik heb alle apparaten met uitzondering Van de TV setopox op de UDM Pro aangesloten.
Die DNS instellingen aan WAN zijde, had je die niet ook aangepast ? Ik denk nl dat het probleem daar zat.
 
1705828046559.png
Heb niet alles doorgelezen want ik zie dat er genoeg mensen bovenop zitten. ;)
Dit kan echter sowieso niet kloppen. Je geeft als DNS server voor de WAN kant een ip-server aan lan kant aan.
Dat is per definitie niet juist Daar zou je het ip-adres van de (dns server van de) provider kunnen staan, bij dubbel NAT kan daar het ip-adres van de router van de provider kunnen staan, maar daar mogen ook publieke DNS servers staan, zoals bijv. 1.1.1.1 (Cloudflare) of 9.9.9.9 (Quad9).
 
Bekijk bijlage 8682
Heb niet alles doorgelezen want ik zie dat er genoeg mensen bovenop zitten. ;)
Dit kan echter sowieso niet kloppen. Je geeft als DNS server voor de WAN kant een ip-server aan lan kant aan.
Dat is per definitie niet juist Daar zou je het ip-adres van de (dns server van de) provider kunnen staan, bij dubbel NAT kan daar het ip-adres van de router van de provider kunnen staan, maar daar mogen ook publieke DNS servers staan, zoals bijv. 1.1.1.1 (Cloudflare) of 9.9.9.9 (Quad9).
Ik denk dus ook dat dit het probleem heeft veroorzaakt. Je kunt in de gateway controleren welke nameservers nu gebruikt worden, ik heb die instelling ook op auto en krijg dan de nameservers van Ziggo. Toch blijft het een wazig probleem dat de clients en devices dan bij de ISP router DHCP uitkomen. Die instelling is nl alleen voor de gateway zelf als die updates krijgt. De clients en devices krijgen hun dns fixed of via DHCP van de gateway.

root@UDM-SE:~# cat /etc/resolv.dnsmasq
# Generated automatically by ubios-udapi-server
search dynamic.ziggo.nl

# dynamic nameservers
# eth8
nameserver 84.116.46.22
nameserver 84.116.46.23
 
Laatst bewerkt:
Wat ik dan niet helemaal begrijp wat een DHCP request met DNS te maken heeft.
Indirect, je kunt via DHCP de DNS server aan een client laten toekennen, da`s wat we met Unbound / Pi-Hole / Adguard e.d. doen, dat loopt via DHCP protocol. Zo kun je ook time server en boot server toekennen aan een client, zit veel meer rommel in dan alleen IP, leasetijd en masker. Als je die setting in WAN op auto zet, dan haalt ie de DNS op via DHCP, bij Ziggo in mijn geval. Aangezien modem in bridge staat, zal dat wel ergens hoger op in het netwerk gebeuren denk ik, ik ken die topografie van hun ook niet.

Is trouwens nog geen verklaring voor het probleem van topic starter, snap ik ook niet, maar lijkt me niet juist dat die WAN aansluiting naar de LAN zijde gaat kijken voor DNS
 
Laatst bewerkt:
Dit is wat ik bedoel. De extra opties zoals DNS krijg je pas als je je ip hebt.

Inderdaad, ik zie `t, ook wel logisch, eerst die handshake, dan de rest. De topic starter had die DNS v/d WAN v/d UDM vastgezet naar de gateway zelf, daar hoort toch altijd een extern adres te staan zou je zeggen, vast of DHCP. Dus dat lijkt me fout, maar waarom je dan bij de ISP router DHCP server uitkomt ontgaat me ook eerlijk gezegd.
 
Wat ik dan niet helemaal begrijp wat een DHCP request met DNS te maken heeft. De client gilt voor DHCP request op het netwerk en daar moet de Server op reageren. Voor zover ik weet zit er in het dhcp protocol niet iets met DNS.
Kan inderdaad niet gerelateerd zijn; het is gewoon een extra fout.
(Het beantwoorden van) DHCP requests kan niet vanuit het WAN naar het LAN komen, tenzij er specifiek een IP-helper (eigenlijk: UDP-helper) is geconfigureerd op het interne lan die die requests specifiek doorstuurt naar een DHCP server in een ander netwerk.
 
  • Leuk
Waarderingen: Eddie the Eagle
Mijn verklaring is veel simpeler: De switches hebben niet direct een DHCP aanvraag naar de UDMP gedaan en werkten daarom nog met de oorspronkelijke IP adressen van de originele router.
Pffff, daarom hebben we jou altijd weer even nodig om ons met beide beentjes op de grond te zetten. Dat moet het geweest zijn; de lease van die dingen was nog niet om dus geen DHCP request. Opgelost door niks te doen. En ons maar laten zwemmen 😂 .
 
Laatst bewerkt:
Mijn verklaring is veel simpeler: De switches hebben niet direct een DHCP aanvraag naar de UDMP gedaan en werkten daarom nog met de oorspronkelijke IP adressen van de originele router.
Nou, dan houden ze dat wel erg lang vast. Een maand geleden had ik hetzelfde probleem. clients via bekabeld kreeg ineens IP van achterliggende V10box (Wij hebben hier nog VDSL dus moeten wel gebruik maken van dat modem/dubbel NAT, kan niet anders)
De clients via Wifi kregen wel een IP adres van de UDMPro.
En dat terwijl de aangesloten clients waar dit speelde al ruim 1/2 jaar zijn aangesloten en altijd een IP van de Pro hebben gekregen.
Dit gebeurde zo van het ene op het andere moment. Had niets in de configuratie veranderd. Hooguit heeft er een mogelijk update plaatsgevonden.
Alle stekers eruit. (harde reset) en in volgorde KPNv10 -> UDMPro - rest weer opgestart en probleem was verdwenen.

De Unifi devices (als men deze bedoeld i.p.v. clients zitten bij mij in een managementnetwerk en bleven op hun gereserveerde IP)
 
  Topic Status: Hallo . Er is al meer dan 14 dagen geen nieuwe reactie meer geplaatst.
  De inhoud is mogelijk niet langer relevant.
  Misschien is het beter om in plaats daarvan een nieuw onderwerp te starten..