[VPN/Draytek/DNS]Geen reverse lookup door een draytek heen ?

[StevenK]

Ik kom op twee netwerken hetzelfde probleem tegen:

* Het netwerk bestaat uit twee of drie vestigingen, gekoppeld via draytek routers met een VPN tunnel.
* Op één vestiging staat een Win2K DC met DNS
* Op die DNS draaien standard primary zones voor het domein (domein.local) en een reverse primary voor 192.168
* Forward lookup werkt op elke locatie, en ook voor de mensen die met een PPTP tunnel inbellen op de draytek
* Reverse lookup werkt alleen op de locatie waar de server staat
* Op de andere vestigingen krijg ik "Can't find servername for address <ip adres van DNS server>"; typisch de melding van niet goed geconfigureerde reverse zone.

Nu heb ik met netwerk monitor van MS op de server zelf gekeken en ik zie de reverse-query helemaal niet langskomen. Doe ik een reverse query voor een ip adres buiten het subnet, dan zie ik 'm wel voorbij komen.

IMHO lijkt het erop dat die draytek de reverse queries voor het 'eigen' subnet niet doorlaat of doorstuurt.

Iemand die dit kan bevestigen of weerleggen of op een andere manier op kan lossen ?

[StevenK]

Inmiddels ook nog op een andere locatie getest. Ik heb twee vestigingen via een VPN tunnel met elkaar verbonden. Op de ene vestiging heb ik een DNS server (192.168.1.11) geïnstalleerd en die werkt helemaal.

Wanneer ik op de andere vestiging (192.168.2.x) het volgende doe, is dit het resultaat:

code:

C:\>nslookup - 192.168.1.11
*** Can't find server name for address 192.168.1.11: Non-existent domain
Default Server:  UnKnown
Address:  192.168.1.11

Ook een reverse-lookup werkt niet:

code:

> set type=PTR
> 192.168.1.11
Server:  UnKnown
Address:  192.168.1.11

*** UnKnown can't find 11.1.168.192.in-addr.arpa.: Non-existent domain
>

Wanneer ik hetzelfde op een machine op het 192.168.1.x netwerk doe, werkt het allemaal wel:

code:

C:\>nslookup - 192.168.1.11
Default Server:  s_hengelo2.domein.local
Address:  192.168.1.11

> set type=ptr
> 192.168.1.11
Server:  s_hengelo2.domein.local
Address:  192.168.1.11

11.1.168.192.in-addr.arpa       name = s_hengelo2.domein.local
>

Mijn conclusie is dat het probleem echt zit in de draytek tunnels; is er iemand die dit kan bevestigen ?

[StevenK]

Hm... Niemand die een draytek VPN gebruikt tussen z'n vestigingen ?

[Verwijderd]

NT > PNS

[Verwijderd]

Het zal uiteraard wel niet het geval zijn, maar probeer je nu ip-adressen uit de private range (192.168.16.xxx) te bereiken over het internet?

In dat geval gaat het je nooit lukken. Het zijn private ranges die niet over het internet routeerbaar zijn. Je router houdt ze aan de binnenkant al tegen omdat het doel zich net als je eigen lan zich ook in 192.168.16.xxx met subnetmask 255.255.255.0 (classful routing) bevindt.

anderzijds ben ik misschien niet aan het opletten en in dat geval wens ik je verder veel succes!


zoals ik al zei: niet aan het opletten

[ Voor 5% gewijzigd door Verwijderd op 10-09-2004 19:20 ]

[StevenK]

Verwijderd schreef op 10 september 2004 @ 19:19:
Het zal uiteraard wel niet het geval zijn, maar probeer je nu ip-adressen uit de private range (192.168.16.xxx) te bereiken over het internet?

<* StevenK checkt TT>
'VPN'. Lijkt me dus geen probleem dat ik private ranges gebruik

[StevenK]

Inmiddels ben ik wat verder: het lijkt door het .local TLD te komen.

Best wel jammer, omdat het om een AD gaat

[Zwelgje]

StevenK schreef op 10 september 2004 @ 07:56:
Hm... Niemand die een draytek VPN gebruikt tussen z'n vestigingen ?

ja ik gebruik ze ook, en ik had ook problemen (niet met dns overigens, maar wel met GPO's die niet netjes doorkwamen door de draytek)

was een draytek probleem die heeft nogal wat moeite met gefragmenteerde pakketjes naar het bleek, een andere router had dit probleem niet

als je nu eens een pptp tunnel opzet met winxp op die lokatie met je draytek op je hoofdvestiging werkt het dan wel?

ik gebruik ook .local overigens, je drayteks hebben wel de nieuwste firmware?

[ Voor 8% gewijzigd door Zwelgje op 11-09-2004 21:13 ]

[StevenK]

zwelgje schreef op 11 september 2004 @ 21:12:
[...]


ja ik gebruik ze ook, en ik had ook problemen (niet met dns overigens, maar wel met GPO's die niet netjes doorkwamen door de draytek)

Dat probleem heb ik ook. Maar zag jij dan ook Userenv 1000 foutmeldingen in de eventlog ? (iets over het niet kunnen vinden van de domeincontroller; dat wordt weer veroorzaakt door het niet werken van die reverse-DNS lookup. Ook schijnt het GetDC proces gebruik te maken van grote ICMP pakketten om de snelste DC te vinden en het kan ook zijn dat de draytek daarover struikelt.

was een draytek probleem die heeft nogal wat moeite met gefragmenteerde pakketjes naar het bleek, een andere router had dit probleem niet

als je nu eens een pptp tunnel opzet met winxp op die lokatie met je draytek op je hoofdvestiging werkt het dan wel?

Nee, zelfde probleem; ik zal binnenkort toch nog eens naar een ander merk router kijken.

ik gebruik ook .local overigens, je drayteks hebben wel de nieuwste firmware?

Yep, nieuwste firmware; gaat ook over twee verschillende, bij het éne bedrijf een 2300, bij het andere een 2200.

[Zwelgje]

StevenK schreef op 12 september 2004 @ 02:48:
[...]

Dat probleem heb ik ook. Maar zag jij dan ook Userenv 1000 foutmeldingen in de eventlog ? (iets over het niet kunnen vinden van de domeincontroller; dat wordt weer veroorzaakt door het niet werken van die reverse-DNS lookup. Ook schijnt het GetDC proces gebruik te maken van grote ICMP pakketten om de snelste DC te vinden en het kan ook zijn dat de draytek daarover struikelt.

[...]

Nee, zelfde probleem; ik zal binnenkort toch nog eens naar een ander merk router kijken.

[...]

Yep, nieuwste firmware; gaat ook over twee verschillende, bij het éne bedrijf een 2300, bij het andere een 2200.

ja precies ja die userenv errors, die heb ik dus ook, je kan met een registry key windows zo instelllen dat ie dat pakketje niet meer verstuurd om te checken, dan ben je van alle ellende af, zo heb ik het op het werk nu ook ingesteld staan op die remote site (4 pc's)

even voor de duidelijkheid die error wordt niet veroorzookt door een DNS lookup fout, maar door het feit dat windows bij het aanloggen probeerd een compressed jpg filetje te versturen over de link om te kijken hoe snel de lijn is, als dit pakketje niet goed aankomt (en dat komt ie niet omdat die draytek het als het ware blockt) dan concludeerd windows dat het een slow link is). maar goed zelfs al forceer je op je lokale machine dat alle links snel zijn, dannog werkt het niet. de enigste oplossing is die registry key OF een andere router

http://cert.uni-stuttgart...raq/2003/10/msg00054.html

[ Voor 3% gewijzigd door Zwelgje op 12-09-2004 07:48 ]

[Brahiewahiewa]

StevenK schreef op 08 september 2004 @ 12:35:
...
* Op die DNS draaien standard primary zones voor het domein (domein.local) en een reverse primary voor 192.168

Heb je één zone gemaakt voor het 192.168.0.0/16 subnet?
Zo ja: hoe heb je replicatie van die zone geregeld tussen de vestigingen? Master/slave of AD-integrated?
Zo nee: dan heb je dus 192.168.0.0/24, 192.168.1.0/24 etc. Hoe zijn die zones verdeeld en hoe verwijs je naar andere zones? Forwarders of secondaries of AD-integrated replicatie?

[StevenK]

Brahiewahiewa schreef op 12 september 2004 @ 10:01:
[...]

Heb je één zone gemaakt voor het 192.168.0.0/16 subnet?

Beide geprobeerd 192.168.0.0/16 en 192.168.2.0/24

Zo ja: hoe heb je replicatie van die zone geregeld tussen de vestigingen? Master/slave of AD-integrated?

dat staat er toch: standard zones; replicatie niet van toepassing, want er is nog maar één DC.

Daarvan afgezien: het probleem doet zich alleen voor met .local; met een andere TLD's is het probleem er niet.

[CyBeR]

.local is tegenwoordig ook alleen voor multicast DNS. Dat gaat niet over een tunnel heen. Ik weet niet of dat voor jouw versie van windows al geldt, maar houd er wel rekening mee.

Probeer eens gewoon het 'server' commando in nslookup. Daarmee kun je aangeven aan welke server nslookup de query gaat geven.

[StevenK]

CyBeR schreef op 12 september 2004 @ 14:57:
.local is tegenwoordig ook alleen voor multicast DNS. Dat gaat niet over een tunnel heen. Ik weet niet of dat voor jouw versie van windows al geldt, maar houd er wel rekening mee.

Hm... Heb ik dan toch op het verkeerde moment te lang onder een steen gezeten ?

Probeer eens gewoon het 'server' commando in nslookup. Daarmee kun je aangeven aan welke server nslookup de query gaat geven.

Ik weet wel welke server 't is, want er is er maar één