[windows 8] AD-domein niet te bereiken in browser

[tim427]

Tweakers,

Door de jaren heen heb ik veel gekke dingen gezien in de ICT, maar deze blijft wel heel vaag.

De setup:
Server: Windows Server 2012 met Active Directory, DNS en DHCP met als domain: tim427.net
Laptop: Windows 8

Intern op het netwerk, werkt alles prima bij benadering van domein tim427.net. In de DNS van Windows Server staat het volgende "*.tim427.net" met een IP-adres naar de webservers in het datacenter.

Intern werkt alles prima. Bij benadering van bijvoorbeeld www.tim427.net of andere sub-domeinnamen kom ik netjes terecht bij de webserver. Zodra er een sub-domein wel bestaat in het netwerk (zoals servers, computer, etc.) krijg ik netjes het interne IP-adres terug van de DNS server.

So far so good.

Nu zit ik met mijn laptop op de universiteit en kan de webserver niet meer benaderen via de browser, alle andere sites werken wel.

Voor de grap heb ik nog geprobeerd om te internetten via mijn smartphone (Mobile Hotspot), ook hier werkt het niet.

Op de laptop van een maatje werkt het wel! (deze laptop is NIET gejoined in mijn Active Directory en draait op Windows 7)

Hier enkele troubleshoot outputs:
nslookup werkt WEL

C:\Users\tim>nslookup www.tim427.net
Server:  ns4.tudelft.net
Address:  131.180.0.25

Non-authoritative answer:
Name:    www.tim427.net
Address:  141.138.140.60

ping naar domein werkt NIET

C:\Users\tim>ping www.tim427.net
Ping request could not find host www.tim427.net. Please check the name and try a
gain.

ping naar IP werkt WEL

C:\Users\tim>ping 141.138.140.60

Pinging 141.138.140.60 with 32 bytes of data:
Reply from 141.138.140.60: bytes=32 time=4ms TTL=59
Reply from 141.138.140.60: bytes=32 time=3ms TTL=59
Reply from 141.138.140.60: bytes=32 time=3ms TTL=59
Reply from 141.138.140.60: bytes=32 time=3ms TTL=59

Ping statistics for 141.138.140.60:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 4ms, Average = 3ms

tracert naar domein werkt NIET

C:\Users\tim>tracert www.tim427.net
Unable to resolve target system name www.tim427.net.

tracert naar ip werk WEL

C:\Users\tim>tracert 141.138.140.60

Tracing route to vps01.tim427.net [141.138.140.60]
over a maximum of 30 hops:

  1     *       <1 ms     *     wired-145-94-212-1.wired.tudelft.nl [145.94.212.
1]
  2    <1 ms    <1 ms    <1 ms  131.180.255.10
  3     2 ms     2 ms     2 ms  GE2-0-0.1032.JNR01.Asd001A.surf.net [145.145.26.
101]
  4     2 ms     2 ms     2 ms  AE0.500.JNR02.Asd001A.surf.net [145.145.80.77]
  5     2 ms     2 ms     2 ms  amsix.router1.dcg.transip.net [195.69.144.244]
  6     3 ms     3 ms     3 ms  vps01.tim427.net [141.138.140.60]

Trace complete.

Het gekke is, dat het aan mijn laptop lijkt te liggen want anderen hebben er geen last van. Paar dagen hier voor had ik Windows 7 onder dezelfde omstandigheden en werkte wel prima. (Windows 8 is een schone installatie).

Overigens heb ik de DNS ge-flushed en ook de nameserver op die van Google gezet (8.8.8.8 en 8.8.4.4) om te testen.

Hosts-file is leeg (standaard zegmaar)

IPv6-uitgeschakeld, tevergeefs

Andere gebruiker op zelfde laptop geprobeerd, zelfde probleem.

Via Wi-Fi en Ethernet geprobeerd, beide zelfde probleem.

Virusscanner (standaard Windows 8 Defender) uitgeschakeld.

http://141.138.140.60/ werkt prima, zelfde geldt voor alle andere sites die gehost worden op de webserver.

Ik loop vast met troubleshooten.. Iemand suggesties?

[ Voor 5% gewijzigd door tim427 op 07-01-2013 10:07 ]

[Eagle Creek]

Wat ik nog mis in het verhaal: via je browser de server op IP benaderen, werkt dit?

[KillerAce_NL]

Check je hosts file eens, het lijt erop dat een geforceerde lookup wel werkt omdat je specifiek een dns server aanwijst die je gebruikt, echter een ping werkt niet, het lijkt erop dat iets anders als je dns server voorrang krijgt.

[tim427]

had ik inderdaad getets, vergeten te vermelden. Zie edit van TS.

[tim427]

Ok het lijkt hem in de "Branc Access" te zitten, welke nog niet helemaal werkt. Hierdoor probeerd hij wel al het "domein verkeer" (tim427.net) te tunnelen door die IPHTTPS-tunnel...

Nu probeer ik deze uit windows te halen..

[tim427]

Na het verwijderen van:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient

Werkt het weer normaal. Bleef toch wel heel vaag dit... Omdat een nslookup wel gewoon werkt.

[TheVMaster]

Eh....volgens mij is het ook redelijk best practice om intern niet een .NET / .COM / .NET te gebruiken .....of roep ik nu iets raars?

Neemt niet weg dat het natuurlijk wel vreemd is...

[ Voor 16% gewijzigd door TheVMaster op 07-01-2013 11:56 ]

[Brahiewahiewa]

tim427 schreef op maandag 07 januari 2013 @ 11:37:
Na het verwijderen van:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient

Werkt het weer normaal. Bleef toch wel heel vaag dit... Omdat een nslookup wel gewoon werkt.

Heb je gekeken welke value d'r in stond?

[Turdie]

Never mind is al opgelost.

[ Voor 165% gewijzigd door Turdie op 08-01-2013 04:16 ]

[tim427]

TheVMaster schreef op maandag 07 januari 2013 @ 11:56:
Eh....volgens mij is het ook redelijk best practice om intern niet een .NET / .COM / .NET te gebruiken .....of roep ik nu iets raars?

Neemt niet weg dat het natuurlijk wel vreemd is...

Valt wel mee toch? Heb apparte DNS voor de buiten wereld en apparte voor intern. Zie dit wel vaker bij bedrijven.

Brahiewahiewa schreef op dinsdag 08 januari 2013 @ 03:47:
[...]

Heb je gekeken welke value d'r in stond?

Ben de exacte value-naam vergeten, maar was iets met "Local domain branch access". Na wat verdieping in de werking van BranchAccess blijkt het een soort VPN tunnel te zijn over HTTP. Alles van dat domein wordt daarover gerouteerd, maar BranchAccess was nog niet werkende, dus ging de mist in.

Het idee van BranchAccess is wel mooi overigens; zonder VPN toch al je kantoor-verkeer tunnelen

[Question Mark]

tim427 schreef op dinsdag 08 januari 2013 @ 09:41:
[...]
Het idee van BranchAccess is wel mooi overigens; zonder VPN toch al je kantoor-verkeer tunnelen

Mwoah... Ik denk niet dat MS al zover is...

Ik denk dat je DirectAcces bedoeld. BrancheCache is een cachingtechniek voor filetransfer tbv branche-locations...

[TheVMaster]

tim427 schreef op dinsdag 08 januari 2013 @ 09:41:
[...]

Valt wel mee toch? Heb apparte DNS voor de buiten wereld en apparte voor intern. Zie dit wel vaker bij bedrijven.


[...]

Ben de exacte value-naam vergeten, maar was iets met "Local domain branch access". Na wat verdieping in de werking van BranchAccess blijkt het een soort VPN tunnel te zijn over HTTP. Alles van dat domein wordt daarover gerouteerd, maar BranchAccess was nog niet werkende, dus ging de mist in.

Het idee van BranchAccess is wel mooi overigens; zonder VPN toch al je kantoor-verkeer tunnelen

Dit was inderdaad in het verleden vaak wel de manier van inrichten. Tegenwoordig (ik kom ze niet meer tegen in een nieuwe setup) is het wel wenselijk om hier geen gebruik meer van te maken. Neemt niet weg dat wij het zelf ook hebben en ik het ook nog wel bij klanten gezien heb, wenselijk is anders

[Question Mark]

Maar waarom is het dan niet wenselijk of niet best practices? Split brain dns is immers ook geen rocket science.

Zeker met certificaten zit er zelfs nog een voordeel in om wel in- en extern dezelfde domeinnaam te hanteren.

[TheVMaster]

Question Mark schreef op dinsdag 08 januari 2013 @ 14:44:
Maar waarom is het dan niet wenselijk of niet best practices? Split brain dns is immers ook geen rocket science.

Zeker met certificaten zit er zelfs nog een voordeel in om wel in- en extern dezelfde domeinnaam te hanteren.

Met certificaten kan het inderdaad nog wel eens een voordeel zijn inderdaad om wel een publieke tld te gebruiken intern, maar in de praktijk kom ik het eigenlijk niet tegen (althans bij greenfield omgevingen ).

[tim427]

Question Mark schreef op dinsdag 08 januari 2013 @ 10:46:
[...]

Mwoah... Ik denk niet dat MS al zover is...

Ik denk dat je DirectAcces bedoeld. BrancheCache is een cachingtechniek voor filetransfer tbv branche-locations...

My bad.. Die bedoel ik ja

Question Mark schreef op dinsdag 08 januari 2013 @ 14:44:
Maar waarom is het dan niet wenselijk of niet best practices? Split brain dns is immers ook geen rocket science.

Zeker met certificaten zit er zelfs nog een voordeel in om wel in- en extern dezelfde domeinnaam te hanteren.

Juist om die reden hanteer ik die setup.

[Question Mark]

TheVMaster schreef op woensdag 09 januari 2013 @ 00:47:
[...]


Met certificaten kan het inderdaad nog wel eens een voordeel zijn inderdaad om wel een publieke tld te gebruiken intern, maar in de praktijk kom ik het eigenlijk niet tegen (althans bij greenfield omgevingen ).

Vraag ik toch nog even door hoor, maar ik mis eigenlijk nog steeds de uitleg waarom het nu niet wenselijk is om intern geen publieke tld te gebruiken. Leuk dat jij het niet meer tegenkomt bij nieuwe omgevingen, maar dat kan natuurlijk ook zijn omdat iedereen als makke schaapjes achter elkaar aanloopt zonder zelf na te denken.

Dus nogmaals: waarom is het nu niet wenselijk om intern een publieke tld te gebruiken?