Om met het eerste te beginnen: VDSL kan prima zonder dubbel NAT; je moet alleen een VDSL modem hebben dat bridging ondersteund.
Zelf had ik voor de overgang naar glas een Fritz met licht aangepaste firmware waardoor mijn bonded en vectored DSL gewoon direct dóór de Fritz heen als Ethernet bij de (toen nog) USG aan kwam. De USG had dus aan de WAN kant mijn externe IPv4 adres.
Dit kan dus wel gewoon, al zal het mogelijk niet lukken met de V10.
Dat gezegd hebbende: als clients op het LAN een adres krijgen van een DHCP server op het WAN is er echt iets heel serieus vreemds en potentieel zelfs gevaarlijks aan de hand. Nu wil ik jouw kennis en kunde niet in twijfel trekken, maar ik vermoed toch dat er ergens een route mogelijk was naar dat tussenliggende netwerk.
Het is technisch wel mogelijk om DHCP te forwarden, maar daar moet je wel wat voor doen. Voordat zoiets spontaan gebeurt zou ik eerst alle andere factoren uitsluiten, zoals bijvoorbeeld een device dat zowel bekabeld netwerk als wireless ondersteund en potentieel een bridge heeft opgezet.
Doordat alle stekkers eruit zijn gegaan is dat natuurlijk niet meer terug te leiden, maar als dat weer voorkomt kun je aan een client natuurlijk 'gewoon' vragen van wie deze zijn ip-adres heeft gekregen. Al is het afhankelijk van het type client welke mogelijkheden je daarvoor hebt.
Maar een gat door een wan/lan router heen is echt wel een dingetje; nu is het naar het ISP modem/router/AP-ding, straks kan het het boze internet zijn.
Je moet inderdaad een modem hebben die bridge ondersteund. Op dit moment hebben we die v10 die dat niet ondersteund. De glaskabels liggen al in de straat en we zijn in afwachting van afmonteren. Dit wetende ga ik natuurlijk niet een ander modem aanschaffen.
Mijn kennis is gecertificeerd CCNA en CCNP. Dat is weliswaar van Cisco maar gebaseerd op algemene netwerkkennis. Werkomgeving professioneel Meraki en Aerohive Wifi omgeving 500+ access points.
Natuurlijk heb ik als eerste een analyse gedaan want ik onderken dit ook als héél merkwaardig en wat eigenlijk niet zou moeten kunnen. Van wie het device het IP adres had gekregen is niet zo moeilijk. Dat is die v10 geweest. Maar ik kon géén logische verklaring hiervoor vinden.
Het enige extra is dat ik een apart vLan heb voor IPTV (Third party Gateway) waarbij een extra kabel uit die v10 op een poort is verbonden met profiel IPTV, en mijn beide mediaboxen ook op een switch met op de poort dat profiel. Dat werkt zonder probleem en minstens een jaar zo.
Omdat ik uiteindelijk geen enkele verklaring kon vinden. behalve misschien mogelijk corrupte image op de UDMPro-SE, leek het mij verstandig de boel te resetten en dan checken of probleem er nog zou zijn. Niet dus en ik heb het afgedaan als een incident. Totdat ik hier lees dat meer gebruikers soortelijke problemen hebben. Dan kan je naar de gemeenschappelijke deler kijken en dat zou dan de UDMPro kunnen zijn. Mogelijk toch een bug na een softwareupdate?
Mijn kennis is gecertificeerd CCNA en CCNP. Dat is weliswaar van Cisco maar gebaseerd op algemene netwerkkennis. Werkomgeving professioneel Meraki en Aerohive Wifi omgeving 500+ access points.
Natuurlijk heb ik als eerste een analyse gedaan want ik onderken dit ook als héél merkwaardig en wat eigenlijk niet zou moeten kunnen. Van wie het device het IP adres had gekregen is niet zo moeilijk. Dat is die v10 geweest. Maar ik kon géén logische verklaring hiervoor vinden.
Het enige extra is dat ik een apart vLan heb voor IPTV (Third party Gateway) waarbij een extra kabel uit die v10 op een poort is verbonden met profiel IPTV, en mijn beide mediaboxen ook op een switch met op de poort dat profiel. Dat werkt zonder probleem en minstens een jaar zo.
Omdat ik uiteindelijk geen enkele verklaring kon vinden. behalve misschien mogelijk corrupte image op de UDMPro-SE, leek het mij verstandig de boel te resetten en dan checken of probleem er nog zou zijn. Niet dus en ik heb het afgedaan als een incident. Totdat ik hier lees dat meer gebruikers soortelijke problemen hebben. Dan kan je naar de gemeenschappelijke deler kijken en dat zou dan de UDMPro kunnen zijn. Mogelijk toch een bug na een softwareupdate?
Ah, dit is wel een aardige aanwijzing.
Dan zou het bijvoorbeeld best een timings-ding kunnen zijn, waarbij bijvoorbeeld de poort al opkomt maar het VLAN profiel nog niet toegepast is/wordt. Er is natuurlijk geen fysieke scheiding. Het zou niet netjes zijn en inderdaad best bug-achtig, maar het is minder onwaarschijnlijk en onlogisch dan DHCP verkeer dat zich door een router heen verplaatst over verschillende IP-segmenten heen.
Hopen dat jouw glas snel doorgetrokken wordt!
Als je kpn Tv+ boxen hebt, dan werkt dat wel gewoon via de UDM en telefonie werkt ook als je de Fritzbox in je netwerk hangt met een ip adres vanuit de UDM. Dan stel je in de FB in dat deze is verbonden met een extern netwerk.
Heb je in het netwerk van de UDM-P ook de DHCP guarding actief. Ik heb ook het KPN modem nog actief en heb nergens last van.
Hier heb ik alleen de DHCP staan van de UDM netwerken/VLAN's. Dus niet het KPN netwerk. DHCP's schreeuwen nog wel eens over de netwerken heen de de hardst scheeuwende heeft dan voorrang.
Hier heb ik alleen de DHCP staan van de UDM netwerken/VLAN's. Dus niet het KPN netwerk. DHCP's schreeuwen nog wel eens over de netwerken heen de de hardst scheeuwende heeft dan voorrang.
Er zit geen volumeregeling op DHCP.
Een client doet een DHCP request, en doet dat middels een broadcast op het hele subnet waar deze client zich bevindt.
Alle DHCP servers binnen dat segment zullen daar dan ook op antwoorden.
Als je niet wilt dat een DHCP server antwoord geeft is de juiste oplossing om er voor te zorgen dat DHCP voor dat segment voor die server uit staat...
DHCP guarding is een aardig hulpmiddel; je vertelt Unifi dat als er een andere (vreemde) server DHCP antwoorden geeft dat dit verkeer geblokkeerd wordt. Dat moet echter ook door de switches ondersteund worden. Unifi switches kunnen dat en kunnen vanuit Unifi beheerd worden.
Je moet dat wel voor elke switch inschakelen, of inschakelen vanuit de global settings:
Gebruik je ook 3rd party switches moet je daar ook 'iets' regelen.
Functie is vooral interessant in omgevingen waar 'vreemden' binnen kunnen komen, bijvoorbeeld met een VM met DHCP server. Dat kan door onnozelheid, onachtzaamheid of kwade opzet.
Eigen DHCP servers (die je niet wilt gebruiken) moet je gewoon uit zetten.
Activiteit
Er wordt op dit moment (nog) geen nieuwe reactie gepost.
