[2003/DNS/VPN] DNS issues

[ElTigre]

Beste Tweakers,

Graag jullie gedachten over hetvolgende probleem.

Situatieschets:
Op kantoor Windows Small Business Server 2003 netwerk. 1 server in 2003 native mode, is tevens PDC, DHCP server en DNS server. Draait ook RRAS. Heeft IP 192.168.1.3/24 als LAN IP, 192.168.1.15 als RRAS (virtueel) IP.

Gateway naar buiten toe is een BEFSX41 router van Linksys op 192.168.1.1 welke als WAN een public internet adres krijgt door spoofing van een domme Alcatel modem.

Nu heb ik nog een BEFSX41 gekocht en thuis geinstalleerd op 192.168.4.1. De 2 BEFjes hebben een VPN link naar elkaar, opgezet door de router zelf. Deze is namelijk tevens VPN endpoint en kan 2 tunnels hebben. Dus een 192.168.1.1 <--> 192.168.4.1 tunnel.

In DNS een reverse lookup zone aangemaakt voor 192.168.4.x, die voor 1.x bestond al. Domeinnaam is opgebouwd als domein.local

De DNS van de client thuis is doorverwezen als enige DNS voorkeur naar 192.168.1.3 (static), ik doe niets met WINS of NETBIOS. Zijn IP is 192.168.4.100, verkregen van de lokale BEFSX41 (dhcp).
Ik kan de server pingen, de VPN link is actief. Kan alleen het domein niet joinen: Hij geeft wel credentialsbox voor toevoegen aan domein, maar zegt dan ´kan netwerkpad niet vinden´.
nslookup kan domein.local wel vinden en geeft juiste IP. Alleen domein zonder .local pikt deze niet, ook al staat mijn dnssuffix op domein.local bij de client.

Als ik op de server nslookup doe snapt deze alleen ´domein´ ook niet, de suffix moet erbij.

Op de server FSMO roles gechecked met dcdiag en nltest: ´DPC role is down´ - Server is wel degelijk DPC volgens de AD.

Bijgevoegd een netwerkschets als jpg.
Linkje naar netwerkschets

Hulp is welkom. Meer informatie kan verstrekt worden indien nodig!

Ter verduidelijking: Het probleem is dat ik in het lokale 1.x subnet wel het domein kan joinen, maar niet over de VPN link vanaf huis. Bij reeds gejoinde machines die ik daarheen verplaats gaat in hetloggen veel te traag en mislukt het -> Client werkt dan met lokale profielen en al, en geen connectiviteit naar server (file sharing of whatever).

[ Voor 10% gewijzigd door ElTigre op 06-10-2005 11:36 ]

[Equator]

Ik kan het er even niet echt uithalen, maar kan je vanaf je thuisPC wel de server op zijn lan IP pingen.

Overigens snap ik niet waarom die RRAS adapter aanwezig is.
Een PC/Server met 2 IP adressen in eenzelfde range kan daar tussen niet routeren, dus wat je daarmee wilt doen is mij nog een raadsel

[ElTigre]

Die RRAS adapter gebruiken sommigen nog af en toe om Softwarematig via VPN in te bellen. Dit werkt wel aardig. Maar hier willen we sowieso even vanaf.

[ElTigre]

Ik kan de server op LAN IP en RRAS ip pingen, en op DNS naam ook als ik FQDN gebruik.

[Equator]

En als je het domein probeert te joinen, doe je dat dan op dns name, of op netbios name

sub.domain.local of domain
Via domain zal het niet werken aangezien je WINS niet gebruikt. (Je zou dat nog op kunnen lossen door een entry in je lmhosts te plaatsen, maar dat even terzijde)

Op dns naam zou het gewoon moeten werken, als je domain controller goed vermeld staat in DNS.
Dus onder forward lookup/domain.ext/_msdcs/pdc/_tcp/_ldap

[ElTigre]

Het is 2003 Server met XP clients. Ik wil geen WINS of Netbios, pure DNS.
Ik join op FQDN, dus domein.local

[ Voor 20% gewijzigd door ElTigre op 06-10-2005 12:48 ]

[ElTigre]

SRV records zijn daar present.

[StevenK]

Omdat .local gereserveerd is voor broadcast-achtige toepassingen zijn er routers DNS verkeer voor .local blokken. Heb hier precies hetzelfde met VPN's over een draytek, terwijl DNS verkeer naar andere domeinen over dezelfde VPN's wel goed werkt.

[ElTigre]

Betekent dat ik mijn dns suffix moet aanpassen voor zoiets?

[StevenK]

ElTigre schreef op donderdag 06 oktober 2005 @ 21:09:
Betekent dat ik mijn dns suffix moet aanpassen voor zoiets?

Wanneer dat het probleem is: ja. Of op een andere manier je VPN opzetten: direct van client naar de server.

[ElTigre]

Is er wat documentatie over het .local block probleem wat dns en routers betreft?
Misschien is de router erop aan te passen. Zo niet dan moet toch de domeinnaam/suffix eraan geloven.

[StevenK]

ElTigre schreef op donderdag 06 oktober 2005 @ 21:22:
Is er wat documentatie over het .local block probleem wat dns en routers betreft?
Misschien is de router erop aan te passen. Zo niet dan moet toch de domeinnaam/suffix eraan geloven.

Er is wel een RFC ofzo over te vinden; raar genoeg is er van de router-fabrikanten weinig informatie over te vinden.

[ElTigre]

Ok...
zou verklaren waarom ik op IP wel heel veel kan doen. Rare zooi.
Maar één ding steekt me dan nog: de FSMO roles op de server bij een dcdiag gaven aan dat de DPC role niet actief zou zijn. Waarom die onzin terwijl ik in AD en al wel de server gedefinieerd heb als PDC? Hij fungeert ook zo.

[alt-92]

[edit]
Hier stond crap.

[ Voor 88% gewijzigd door alt-92 op 06-10-2005 22:11 ]

[Brahiewahiewa]

Hier vind je hoe Microsoft tegen het Rendez Vous protocol aankijkt.

When you plan your network, avoid assigning your domain a name that uses the .local extension.

E.e.a. verklaart echter niet waarom het joinen van een domain vanaf een Windows machien niet zou werken.

ElTigre schreef op donderdag 06 oktober 2005 @ 21:32:...Maar één ding steekt me dan nog: de FSMO roles op de server bij een dcdiag gaven aan dat de DPC role niet actief zou zijn. Waarom die onzin terwijl ik in AD en al wel de server gedefinieerd heb als PDC? Hij fungeert ook zo.

Klinkt toch echt alsof het PDC record niet (goed) in DNS terecht is gekomen en dat verklaart wèl waarom je workstation het domain niet kan joinen. Doet eens kijken in de DNS management console naar Forward Lookup Zones | domain.local | _msdcs | pdc | _tcp
Als het goed is staat daar: _ldap [0][100][389]sbs2003.domain.local.
Asl er iets anders staat, heb je de oorzaak van je probleem gevonden.

Dan in Forward Lookup Zones | domain.local kijken welke A records er voor sbs2003.domain.local staan. Als dat er meer dan één zijn, heb je een mogelijke oorzaak gevonden (probeert-ie te connecten naar 192.168.1.15 en daar staat ws de Microsoft Network client uitgeschakeld)

Je zou nog heel bijdehand kunnen opmerken dat werkstations op je locale subnet ook niet zouden moeten kunnen joinen, maar da's niet het geval. Ondanks jouw aversie tegen NetBIOS doet een client toch gewoon een NetBIOS broadcast voor de domain name als-ie die via DNS niet kan vinden. Op je locale subnet werkt dat; op een gerouteerd subnet niet.

[ElTigre]

Vooruitgang!

De ldap record was present in PDC.
Maar er waren idd 2 A records (1.3 en 1.15!) Ik heb 1.15 verwijderd.
Tevens heb ik DNS verteld alleen te luisteren op 1.3 waar deze dat eerst ook op 1.15 deed.

Domain join lukte!

Maar het inloggen nu niet: Duurt eeuwen en daarna verschijnt in de eventvwr:

Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or could not be contacted. ). Group Policy processing aborted

en

Automatic certificate enrollment for local system failed to contact the active directory (0x8007054b). The specified domain either does not exist or could not be contacted.
Enrollment will not be performed.

Na lange tijd gaat ie wel door. Vervolgens kan ik wel pingen naar servernaam (zonder FQDN te gebruiken), maar file sharing of andere functies werken niet (\\servernaam kan nie vinden)

[Verwijderd]

StevenK schreef op donderdag 06 oktober 2005 @ 19:51:
Omdat .local gereserveerd is voor broadcast-achtige toepassingen zijn er routers DNS verkeer voor .local blokken. Heb hier precies hetzelfde met VPN's over een draytek, terwijl DNS verkeer naar andere domeinen over dezelfde VPN's wel goed werkt.

AFAIK is dit niet waar. Ik heb dit gewoon zien werken. Maar mischien heb je een bron om dit statement te onderbouwen?

Over het probleem:

Op de server FSMO roles gechecked met dcdiag en nltest: ´DPC role is down´ - Server is wel degelijk DPC volgens de AD.

dcdiag, netdiag etc moeten natuurlijk geen fouten geven. Het heeft geen zin te troubleshooten op een client als de server niet ok is.

[ Voor 26% gewijzigd door Verwijderd op 07-10-2005 07:07 ]

[StevenK]

Verwijderd schreef op vrijdag 07 oktober 2005 @ 06:58:
[...]

AFAIK is dit niet waar. Ik heb dit gewoon zien werken. Maar mischien heb je een bron om dit statement te onderbouwen?

Kom maar kijken Als ik op het 192.168.2. netwerk een [code]nslookup - 192.168.1.12[/quote] probeer, krijg ik een timeout.

Zoeken op "dot-local" geeft je ook meer info over de herkomst: het komt uit de OS-X wereld en .local is een soort van broadcast oplossing voor DNS. Kijk maar op www.multicastdns.org

Als ik daarnaast een test-omgeving opbouw met een andere extensie dan .local dan gaat 't wel goed.

dcdiag, netdiag etc moeten natuurlijk geen fouten geven. Het heeft geen zin te troubleshooten op een client als de server niet ok is.

Overigens lukte het mij wel met één DNS server te joinen vanaf een andere vestiging; maar o.a. group policy processing ging weer wel fout; vanaf dat ik op elke vestiging een lokale DNS server had, werkte verder alles naar behoren.

En voor de goede orde: het kan ook heel goed zijn dat het draytek is die bepaald DNS verkeer blokkeert (of altijd probeert zelf te beantwoorden) en dat ik in mijn niet volledig ben geweest.

[ Voor 13% gewijzigd door StevenK op 07-10-2005 08:28 ]

[ElTigre]

´t blijf idd een mogelijkheid. Zeker omdat ik nu wel kan joinen maar slecht kan aanloggen (GP niet geladen enzo).

Maar dan blijft ´PDC role down´ nog staan. Ik had die ldap vermelding gechecked in DNS onder domain.local/msdc/pdc/tcp dat zit wel goed.

Waar kan dat nog meer in hangen?

Die event log geeft bij aanloggen de melding over PDC not found dus dat zal er denk ik mee samenhangen.

[ElTigre]

FSMO roles bij DCDIAG is opgelost - Passed.
Time Service draaide niet mee (stopped) en dat was dat probleem.

Blijft echter nog steeds dat de client niet fatsoenlijk kan aanloggen en de DC niet kan vinden bij aanlogpogingen.

[StevenK]

ElTigre schreef op vrijdag 07 oktober 2005 @ 10:30:
FSMO roles bij DCDIAG is opgelost - Passed.
Time Service draaide niet mee (stopped) en dat was dat probleem.

Blijft echter nog steeds dat de client niet fatsoenlijk kan aanloggen en de DC niet kan vinden bij aanlogpogingen.

Kun je wel

code:

nslookup - <ip adres van DNS server>

doen ?

[ElTigre]

Jazeker. Komt terug met de FQDN en al.

[StevenK]

ElTigre schreef op vrijdag 07 oktober 2005 @ 10:58:
Jazeker. Komt terug met de FQDN en al.

En dat is vanaf de client, neem ik aan ? Dan weet je zeker dat je DNS verkeer helemaal werkt en dat je iig niet hetzelfde probleem hebt als ik.

[ElTigre]

Dat is inderdaad vanaf de client. Dus lijkt inderdaad goed te gaan.
Maar dan zou hij ook de DC moeten vinden en niet die event moeten geven bij aanloggen?

[StevenK]

ElTigre schreef op vrijdag 07 oktober 2005 @ 11:05:
Dat is inderdaad vanaf de client. Dus lijkt inderdaad goed te gaan.
Maar dan zou hij ook de DC moeten vinden en niet die event moeten geven bij aanloggen?

Voor de goede orde: als je in ip config kijkt op je client, heeft 'ie dan wel *jouw* dns als primaire dns ?

[ElTigre]

IPconfig op de client geeft maar 1 dns en dat is 192.168.1.3, de primaire dns en enige dns server van het domein.

[ElTigre]

[hier stond ook crap]

[ Voor 84% gewijzigd door ElTigre op 07-10-2005 11:20 ]

[StevenK]

Hebben die routers een NetBIOS filter ?

Heb je al gekeken of je met Netwerk monitor kunt zien of er bepaalde requests of queries zijn waar geen antwoord op komt ?

[ElTigre]

Geen idee, maar ik wil ook volledig buiten netbios om werken. Je moet toch puur op dns kunnen werken?

Ik zal later op de dag wat traces doen.

[ Voor 18% gewijzigd door ElTigre op 07-10-2005 11:25 ]

[StevenK]

ElTigre schreef op vrijdag 07 oktober 2005 @ 11:24:
Geen idee, maar ik wil ook volledig buiten netbios om werken. Je moet toch puur op dns kunnen werken?

Dan moet je linux pakken Windows is nog steeds in de basis op Lan Manager gebaseerd en daardoor kom je nog steeds op diverse plekken NetBIOS afhankelijkheden tegen. En Weliswaar wordt dan de name resolution via DNS geregeld, waardoor je geen WINS of LMHOSTS file meer nodig hebt, maar nog steeds zie dat er NetBIOS verkeer plaatsvindt.

Dat gezegd hebbende:

probeer eens in je %windir%\system32\drivers\etc een lmhosts file neer te zetten met daarin

code:

<ip adres van DC> <naam van DC> #PRE #DOM:<NetBIOS domeinnaam>

En daarna op de client de volgende twee commando's:

code:

NBTSTAT -R
NBTSTAT -RR

en dan kun je met

code:

NBTSTAT -c

Zien of je domein en dc in je NetBIOS cache verschijnen. Als dat het geval is, probeer dan nog eens aan te loggen en kijk of het verschil maakt.

[ElTigre]

Ook iets wat ik zo ga proberen... echter mocht dat werken...

Het kan toch niet zo wezen dat ik lmhost files moet gebruiken op ieder client van dat domein?

[StevenK]

ElTigre schreef op vrijdag 07 oktober 2005 @ 11:34:
Ook iets wat ik zo ga proberen... echter mocht dat werken...

Het kan toch niet zo wezen dat ik lmhost files moet gebruiken op ieder client van dat domein?

Nee, maar als het je probleem oplost, weet je in ieder geval dat 'ie iets via NetBIOS probeert wat niet werkt.

[Brahiewahiewa]

ElTigre schreef op vrijdag 07 oktober 2005 @ 01:46:
Vooruitgang!

De ldap record was present in PDC.
Maar er waren idd 2 A records (1.3 en 1.15!) Ik heb 1.15 verwijderd...

Goeie kans dat-ie er na 15 minuten weer staat.
Volg FF de procedure in http://support.microsoft....aspx?scid=kb;en-us;830063 om 't definitief uit te zetten.

[ElTigre]

Ik had dat intussen inderdaad ontdekt en ook die procedure al uitgevoerd, doch bedankt voor de info.
Zit alleen nog met de inlog. Event 1054 uit userenv doet zich dus voor. Het aantal oplossingen wat geboden wordt volgens google/eventid.net is uitermate talrijk.

Enig idee welke het beste van toepassing is op de situatie zoals deze is?

[alt-92]

http://support.microsoft....aspx?scid=kb;en-us;326152 ?

Gbit nic toevallig?

[Verwijderd]

StevenK schreef op vrijdag 07 oktober 2005 @ 08:13:
[...]

Kom maar kijken Als ik op het 192.168.2. netwerk een [code]nslookup - 192.168.1.12

probeer, krijg ik een timeout.

Zoeken op "dot-local" geeft je ook meer info over de herkomst: het komt uit de OS-X wereld en .local is een soort van broadcast oplossing voor DNS. Kijk maar op www.multicastdns.org

Als ik daarnaast een test-omgeving opbouw met een andere extensie dan .local dan gaat 't wel goed.

[/quote]
.local komt niet uit de OS wereld. Het is al heel lang een standaard suffix voor private domeinen. Het is ook de default voor SBS. Nou ken ik drayteks vrij goed, ook met VPN configuraties en dit verschijnsel heb ik nog nooit gezien. Het lijkt me meer iets anders.

Overigens lukte het mij wel met één DNS server te joinen vanaf een andere vestiging; maar o.a. group policy processing ging weer wel fout; vanaf dat ik op elke vestiging een lokale DNS server had, werkte verder alles naar behoren.

Wat je wel bij drayteks kunt hebben is problemen met het uitvoeren van group policies doordat 2 kb pings niet worden doorgelaten. Daardoor gaat de slow link detection fout. Dat effect kun je wel uitschakelen door slow link uit te schakelen. Dit doe je normaal met een policy maar dat kan in dit geval niet en moet je het lokaal forceren.

[Verwijderd]

StevenK schreef op vrijdag 07 oktober 2005 @ 11:30:
[...]

Dan moet je linux pakken Windows is nog steeds in de basis op Lan Manager gebaseerd en daardoor kom je nog steeds op diverse plekken NetBIOS afhankelijkheden tegen. En Weliswaar wordt dan de name resolution via DNS geregeld, waardoor je geen WINS of LMHOSTS file meer nodig hebt, maar nog steeds zie dat er NetBIOS verkeer plaatsvindt.

Mischien haal je SMB en Netbios door elkaar. Voor de zaken die je hier schetst is netbios niet nodig. Dat wil niet zeggen dat je het nooit nodig hebt of dat WINS overbodig is geworden maar het zit er wel dicht tegen aan.

[Verwijderd]

StevenK schreef op vrijdag 07 oktober 2005 @ 11:23:
Hebben die routers een NetBIOS filter ?

Heb je al gekeken of je met Netwerk monitor kunt zien of er bepaalde requests of queries zijn waar geen antwoord op komt ?

Even kijken met netwerk monitor kan zeker geen kwaad dan zie je nog wel eens wat.

Andere banale dingen die het kunnen zijn

Firewall features zoals anti p2p, anti DoS maatregelen in een router
MUT grootte
TCP/UDP issues met DNS verkeer.

[StevenK]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 00:38:
[...]

Mischien haal je SMB en Netbios door elkaar. Voor de zaken die je hier schetst is netbios niet nodig. Dat wil niet zeggen dat je het nooit nodig hebt of dat WINS overbodig is geworden maar het zit er wel dicht tegen aan.

Maak je geen zorgen, ik haal NetBIOS en SMB zeker niet door elkaar. Laatste keer dat ik keek was SMB een protocol dat o.a. door de server en workstation service gebruikt wordt en dat overigens, met uitzondering van 'direct hosting' over IPX, altijd bovenop NetBIOS draait. Sinds Win2K wordt CIFS ondersteund, waarmee het SMB verkeer zonder NetBIOS direct op tcp/ip kan draaien en het is daarom het SMB over NetBIOS gedeelte dat je in Win2K niet meer nodig hebt of zou moeten hebben. Maar voor communicatie met niet CIFS-clients wordt nog steeds het hele LM-compatible scala aan SMB ondersteund.

Wat je wel bij drayteks kunt hebben is problemen met het uitvoeren van group policies doordat 2 kb pings niet worden doorgelaten. Daardoor gaat de slow link detection fout. Dat effect kun je wel uitschakelen door slow link uit te schakelen. Dit doe je normaal met een policy maar dat kan in dit geval niet en moet je het lokaal forceren.

Maar dat verklaart nog niet waarom een nslookup niet over een draytek-vpn werkt.

[ Voor 40% gewijzigd door StevenK op 08-10-2005 07:48 ]

[Verwijderd]

StevenK schreef op zaterdag 08 oktober 2005 @ 07:44:


Maar dat verklaart nog niet waarom een nslookup niet over een draytek-vpn werkt.

Over jouw draytek VPN. Ik heb dit verschijnsel bij draytek nog nooit eerder waargenomen. Als het een algemeen verschijnsel zou zijn zou ik er meldingen over verwachten vandaar mijn eerdere vraag om de bronvermelding.

MTU problemen kunenn trouwens WEL tot gevolg hebben dan nslookup niet werkt.

[Verwijderd]

StevenK schreef op zaterdag 08 oktober 2005 @ 07:44:
[...]

Maak je geen zorgen, ik haal NetBIOS en SMB zeker niet door elkaar. Laatste keer dat ik keek was SMB een protocol dat o.a. door de server en workstation service gebruikt wordt en

Nog wel meer dan dat maar dat is voor dit probleem niet zo relevant.

[StevenK]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 14:27:
[...]

Over jouw draytek VPN. Ik heb dit verschijnsel bij draytek nog nooit eerder waargenomen. Als het een algemeen verschijnsel zou zijn zou ik er meldingen over verwachten vandaar mijn eerdere vraag om de bronvermelding.

Ik heb het probleem in verschillende netwerken, met verschillende versies en modellen van draytek gereproduceerd. Het is dus niet zozeer 'mijn' VPN. En de laatste keer dat ik er contact over had met draytek support werd mij gemeld dat ze het probleem konden reproduceren. Was helaas ook het laatste wat ik er van hoorde.

[Verwijderd]

StevenK schreef op zaterdag 08 oktober 2005 @ 14:46:
[...]

Ik heb het probleem in verschillende netwerken, met verschillende versies en modellen van draytek gereproduceerd. Het is dus niet zozeer 'mijn' VPN. En de laatste keer dat ik er contact over had met draytek support werd mij gemeld dat ze het probleem konden reproduceren. Was helaas ook het laatste wat ik er van hoorde.

Was dit mischien de ingebouwde DNS van die routers? In elk geval moet het een heel specifiek probleem dan zijn in een zeer specifieke situatie, immers die .local wordt vrij algemeen gebruikt dan moeten veel mensen daar last van hebben en dat is niet zo.

[StevenK]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 16:47:
[...]

Was dit mischien de ingebouwde DNS van die routers? In elk geval moet het een heel specifiek probleem dan zijn in een zeer specifieke situatie, immers die .local wordt vrij algemeen gebruikt dan moeten veel mensen daar last van hebben en dat is niet zo.

Nee, ik heb 't over de DNS die op de betreffende Win2K DC('s) draait.

[ElTigre]

De MTU is volgens mij 1500.