Vreemde redirect van externe website op het lan-netwerk

[Verwijderd]

Hallo Mede-tweakers,

Sinds gisteren ervaar ik iets heel vreemds, ben heel de middag aan het zoeken geweest maar ik ga er zelf helaas niet uit komen.

Ik krijg een mailtje doorgestuurd van een collega om een tweetal producten te bekijken op een webshop. Ik klik de link aan en vervolgens wordt ik gelijk geredirect naar onze eigen bedrijfswebsite. Ik klik de tweede link aan en potver...idem dito, wordt weer naar onze eigen website doorgestuurd.

Ik dacht gelijk.. ah, vast iets met een DNS config foutje..

Er is recentelijk niets veranderd in de server configuratie. Alles draait al jaren soepel en zonder problemen. Het enige gerelateerde dat ik me kan bedenken is dat ik recentelijk (vorige week) een SSL certificaat heb toegevoegd aan onze eigen website. Verder niet zo spannend maar ik zit zelf toch te denken dat er iets met de SSL wijziging te maken heeft. Echter als ik op de webshop kijk (vanuit onze server) dan zie ik niets vreemds aan het certificaat van betreffende partij..

De hamvraag.. wat veroorzaakt de redirect van deze webshop naar onze eigen website URL? Zowel direct als organisch wordt ik doorgelinkt naar onze eigen url.


Gerelateerde informatie

- Eigen server met dhcp, dns, ad en exchange
- Router in beheer van ISP
- IP van de server: 192.168.9.6


ip instellingen pc

[static ip] 192.168.9.243
[subn] 255.255.255.0
[gatew] 192.168.9.254
[dns] 192.168.9.6


Vervolgstappen
- Meerdere links vanuit andere mails aangeklikt --> linken allemaal keurig door naar de juiste site. Dit probleem doet zich dus alleen voor bij de bewuste url vanuit e-mail, Google, direct.
- Browsercache gewist
- Switchen van static ip naar dhcp --> geen effect
- Pingen naar de url --> request time out
- Tracert naar de url --> blijft hangen na 13 hops
- DNS cache gewist op de server
- Trustpoint --> leeg
- Conditional forwarders --> leeg
- Forward lookup zone nagekeken --> staan alleen redirects in welke ook kloppen en van onszelf zijn
- DNS aangepast naar 8.8.8.8 op mijn pc --> geen effect
- URL benaderen vanaf een andere desktop in het netwerk --> zelfde probleem
- URL benaderen vanaf de server zelf --> linkt keurig door naar de juiste url (!)

Het vreemde hiervan is.. de nic instellingen zijn identiek als die van mijn pc, op het ip-adres na, en toch kan ik niet de webshop benaderen vanaf mijn pc.



Hebben jullie nog opties? Tracert wil ik best posten als er vraag naar is, anders word mijn post wel erg lang..
Het lijkt me erg sterk dat het in de config van DNS zit. Zoals ik aangaf, hier is recentelijk niets in gewijzigd en het issue heeft slechts betrekking op één URL in het lan netwerk..

[ Voor 3% gewijzigd door Verwijderd op 19-12-2018 12:37 ]

[lier]

Zou je eens een tracert [url] vanaf de server en vanaf je werkstation kunnen doen? Wat zit er allemaal in het netwerk, maak je (bijvoorbeeld) gebruik van een proxy server?

[Equator]

Kijk eens of je rare dingen hebt in je C:\Windows\system32\Drivers\etc\host bestand?

Hmm, gezien je route en pings lijkt daar niets mis mee.

[ Voor 25% gewijzigd door Equator op 19-12-2018 12:48 ]

[Verwijderd]

lier schreef op woensdag 19 december 2018 @ 12:24:
Zou je eens een tracert [url] vanaf de server en vanaf je werkstation kunnen doen? Wat zit er allemaal in het netwerk, maak je (bijvoorbeeld) gebruik van een proxy server?

Hierbij de tracert vanaf beide machines. Wij maken geen gebruik van proxyservers e.d.

Vanaf de server:



Vanaf pc

[ Voor 4% gewijzigd door Verwijderd op 19-12-2018 12:49 ]

[Verwijderd]

Equator schreef op woensdag 19 december 2018 @ 12:44:
Kijk eens of je rare dingen hebt in je C:\Windows\system32\Drivers\etc\host bestand?

Zover ik kan zien staat er niets raars in de hostfile:

PHP:

 # Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost

[Equator]

Verwijderd schreef op woensdag 19 december 2018 @ 12:48:
[...]


Zover ik kan zien staat er niets raars in de hostfile:

code:

 # Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost

Dat was al duidelijk na je post met tracerts en ping

[Cpt.Morgan]

* Heb je ook al andere browsers geprobeerd?
* Wat gebeurd als je andere links van die website probeert, of direct naar het homepage van die site wilt gaan? (met andere woorden: ligt het aan de links in de email, of aan die hele website)

[dion_b]

Verwijderd schreef op woensdag 19 december 2018 @ 12:45:
[...]


Hierbij de tracert vanaf beide machines. Wij maken geen gebruik van proxyservers e.d.

Vanaf de server:

[Afbeelding]

Vanaf pc

[Afbeelding]

Dit is allemaal IPv4. Moderne browsers prefereren IPv6 indien aanwezig. Is IPv6 aanwezig, zo ja, kun je dezelfde stappen daarvoor doen?

[Verwijderd]

Cpt.Morgan schreef op woensdag 19 december 2018 @ 12:54:
* Heb je ook al andere browsers geprobeerd?
* Wat gebeurd als je andere links van die website probeert, of direct naar het homepage van die site wilt gaan? (met andere woorden: ligt het aan de links in de email, of aan die hele website)

Ik heb zowel Chrome, Firefox als IE geprobeerd. Op alle drie de browsers hetzelfde resultaat..
De links die ik ontving per mail waren ook 'deeplinks' naar artikelen toe. Voor zowel de deeplink als een link naar de reguliere homepage wordt ik doorverwezen naar onze homepagina..

[Verwijderd]

dion_b schreef op woensdag 19 december 2018 @ 13:03:
[...]

Dit is allemaal IPv4. Moderne browsers prefereren IPv6 indien aanwezig. Is IPv6 aanwezig, zo ja, kun je dezelfde stappen daarvoor doen?

Wij maken (nog) geen gebruik van IPv6. We zijn toevallig wel bezig om over te stappen naar een andere ISP waar momenteel gesprekken over gaande zijn. Echter zal dit pas over 6 maanden+ uiteindelijk in gang gezet worden waarop ik IPv6 bespreekbaar ga maken.

[Verwijderd]

Misschien nog een waardevolle toevoeging. Vanaf de website van mxtoolbox heb ik het domein eens laten scannen. Hierin komt uiteindelijk naar voren dat er geen dns record is vastgelegd voor dit domein.

https://mxtoolbox.com/domain/www.liebherr-webshop.nl/

Dan nog blijft bij mij de vraag, waarom vanaf de server wel te benaderen en vanaf een client niet..

[valkenier]

geen DNS record? tuurlijk wel.
Als het vanaf de server wel gaat, en een cliënt niet.... Proxy-dingetje?

[Brahiewahiewa]

Zit het probleem niet gewoon in het mailtje? Dat zeg maar de url veranderd is door een of ander proces.
Als je in je browser gewoon www.liebherr-webshop.nl intikt, kom je dan ook op je eigen website uit?
En doe eens rechtsklikken op de link in het mailtje | copy shortcut | paste in notepad o.i.d.

[Oogje]

Brahiewahiewa schreef op donderdag 20 december 2018 @ 00:08:
Zit het probleem niet gewoon in het mailtje? Dat zeg maar de url veranderd is door een of ander proces.
Als je in je browser gewoon www.liebherr-webshop.nl intikt, kom je dan ook op je eigen website uit?
En doe eens rechtsklikken op de link in het mailtje | copy shortcut | paste in notepad o.i.d.

Dacht ik dus ook, als TS met zn muis hoovert over de URL in de mail, wat staat daar dan?

[jurri@n]

Heb je heel misschien het domein van het bedrijf ook ingesteld staan als DNS search domain? In sommige omstandigheden kan dit er toe leiden dat dit achter de opgevraagde hostname komt te staan.

Bijvoorbeeld:

code:

www.liebherr-webshop.nl.jouwbedrijf.nl

Deze wordt dan vervolgens opgevangen door een wildcard-record in de DNS van jouwbedrijf.nl (*.jouwbedrijf.nl) en kom je op de website van je eigen bedrijf uit.

Tip: Probeer eens

code:

www.liebherr-webshop.nl.

(let op die punt erachter)

[ Voor 2% gewijzigd door jurri@n op 20-12-2018 08:20 . Reden: Code-tags toegevoegd om ongewenste links te voorkomen ]

[Kees]

Inderdaad. Check je dns search domein, en check of dat search domein een wildcard heeft (en indien ja: schop je locale it, een search domein met wildcard record is een erg slecht idee).

Tenzij je bij liebherr werkt lijkt me bovenstaande dns probleem het meest waarschijnlijk

[roberttttt]

Ik had dat gisteren ook nadat ik de pool hier op Tweakers had ingevuld (bolletje aangetikt met "ja ik wil mee doen"
Daarna deed mijn browser vreemd en ook windows deed een paar dingen die die niet zou moeten doen.

Adwcleaner loste het op.
Geeft te denken tweakers.net..................................

[Verwijderd]

Brahiewahiewa schreef op donderdag 20 december 2018 @ 00:08:
Zit het probleem niet gewoon in het mailtje? Dat zeg maar de url veranderd is door een of ander proces.
Als je in je browser gewoon www.liebherr-webshop.nl intikt, kom je dan ook op je eigen website uit?
En doe eens rechtsklikken op de link in het mailtje | copy shortcut | paste in notepad o.i.d.

Nee, dit dacht ik in eerste instantie ook. Of ik nu de link aanklik vanuit de e-mail, of rechtstreeks naar de website ga.. ik blijf op ons eigen domein uitkomen. Zelfs via Google search kom ik bij mijn eigen domein uit

[Verwijderd]

jurri@n schreef op donderdag 20 december 2018 @ 08:17:
Heb je heel misschien het domein van het bedrijf ook ingesteld staan als DNS search domain? In sommige omstandigheden kan dit er toe leiden dat dit achter de opgevraagde hostname komt te staan.

Bijvoorbeeld:

code:

www.liebherr-webshop.nl.jouwbedrijf.nl

Deze wordt dan vervolgens opgevangen door een wildcard-record in de DNS van jouwbedrijf.nl (*.jouwbedrijf.nl) en kom je op de website van je eigen bedrijf uit.

Tip: Probeer eens

code:

www.liebherr-webshop.nl.

(let op die punt erachter)

Tip: Probeer eens

code:

www.liebherr-webshop.nl.

Bedankt voor het meedenken. Helaas geeft de link (met punt) een bad request.

In onze DNS records staat 100% geen doorverwijzing of een andere relatie naar het bedrijf. Een externe collega had thuis toevallig een vergelijkbaar product gevonden (op de website van liebherr-webshop) en stuurde dit ter info door naar een interne collega van mij. Deze collega wees me uiteindelijk op de vreemde redirect van de link die hij binnen kreeg.

Ter info wat ik binnen kreeg:

[jurri@n]

In onze DNS records staat 100% geen doorverwijzing of een andere relatie naar het bedrijf.

Dit is geen DNS-instelling, dat zit in de netwerk-instellingen van je PC.

Voer op de command prompt eens het volgende uit:

code:

ipconfig /all

Vooral de regel met "DNS Suffix Search List" in interessant.

[ Voor 0% gewijzigd door jurri@n op 20-12-2018 10:31 . Reden: Typo ]

[Verwijderd]

word dit domein voor uitgaand http niet gefilterd en dan geredirect?

ik moet leren lezen...

[ Voor 19% gewijzigd door Verwijderd op 20-12-2018 11:18 ]

[Verwijderd]

Kees schreef op donderdag 20 december 2018 @ 09:43:
Inderdaad. Check je dns search domein, en check of dat search domein een wildcard heeft (en indien ja: schop je locale it, een search domein met wildcard record is een erg slecht idee).

Tenzij je bij liebherr werkt lijkt me bovenstaande dns probleem het meest waarschijnlijk

Ik vermoed zelf dat het ook echt een DNS probleem is inderdaad. Aangezien ik buiten onze LAN (via 4g of whatever) wel naar de goede website wordt doorgelinkt kan ik er vanuit gaan dat het in onze interne DNS records zou moeten zitten en niet de records bij onze hostingpartij.

Mijn interne records zijn als volgt:
zwart streepje = onze bedrijfsnaam



In de Cached Lookup kom ik dit tegen:

[Verwijderd]

jurri@n schreef op donderdag 20 december 2018 @ 10:31:
[...]


Dit is geen DNS-instelling, dat zit in de netwerk-instellingen van je PC.

Voer op de command prompt eens het volgende uit:

code:

ipconfig /all

Vooral de regel met "DNS Suffix Search List" in interessant.

Het geldt niet alleen voor mijn pc maar ook voor alle thin clients binnen ons LAN netwerk. Iedereen in ons bedrijfsnetwerk wordt dus naar ons eigen domein doorverwezen (alleen bij het aanklikken van de link naar liebherr webshop)

Iets met de interne DNS zou je zeggen...

Ik ben al lang blij dat iedereen meedenkt. Hoe meer info ik verschaf, hoe inzichtelijker het uiteindelijk zal worden en hoe eerder het 'probleem' achterhaald kan worden. Het gaat me ook niet zozeer om dit kleine issue maar ik ben gewoon benieuwd waar dit nou vandaan komt.

[ Voor 3% gewijzigd door Verwijderd op 20-12-2018 11:37 ]

[eric.1]

Kees schreef op donderdag 20 december 2018 @ 09:43:
Inderdaad. Check je dns search domein, en check of dat search domein een wildcard heeft (en indien ja: schop je locale it, een search domein met wildcard record is een erg slecht idee).

Tenzij je bij liebherr werkt lijkt me bovenstaande dns probleem het meest waarschijnlijk

Vooralsnog is er niets gepost wat deze theorie ondersteunt. Als je via Nslookup/Tracert wel gewoon bij het juiste adres terecht komt, lijkt het me sterk dat dit aan het search domein ligt. Volgens mij heb je hier sowieso via de browser minder snel mee te maken.

Dan is het eerder iets mysterieus in de browser/av/... . Heck, het zou zelfs nog aan de kant van TransIP kunnen zitten..

[Kees]

Of een overijverige bedrijfsproxy.

Als je de devtoolbar (F12) aangooit en de link copy-paste in de url balk (en 'persist logs' aanzet) krjg je dan wel te zien of (en van wie) je een redirect krijgt? En op welk ip hij probeert te connecten?

[EvH]

MXtoolbox geeft A record: 37.97.141.198 terug.

In je DNS:
[Afbeelding]

gebruik je 37.97.177.103

[eric.1]

EvH schreef op donderdag 20 december 2018 @ 12:54:
MXtoolbox geeft A record: 37.97.141.198 terug.

In je DNS:
[Afbeelding]

gebruik je 37.97.177.103

Ja, die webshop zit op 37.97.141.198, en de TS zijn bedrijf op 37.97.177.103?

Wat wil je hiermee zeggen?

[EvH]

Verkeerde interpretatie van de betreffende vraag.

[ Voor 91% gewijzigd door EvH op 20-12-2018 13:14 ]

[Verwijderd]

Kees schreef op donderdag 20 december 2018 @ 12:28:
Of een overijverige bedrijfsproxy.

Als je de devtoolbar (F12) aangooit en de link copy-paste in de url balk (en 'persist logs' aanzet) krjg je dan wel te zien of (en van wie) je een redirect krijgt? En op welk ip hij probeert te connecten?

Proxy maken wij geen gebruik van binnen de organisatie.
Hierbij wat info uit de devtoolbar. Zover ik kan zien krijg ik een statuscode 302 [found] terug waarop ik geredirect wordt.

[Kees]

Nee, je krijgt een '302 Found' terug, dus een redirect. Mischien dat ze bij liebherr iedereen met jullie ip redirecten naar je eigen site om een of andere reden.

Het meest eenvoudige is dat te checken met een commandline tool; bijvoorbeeld curl. Je kan dan rechtsclicken op de 302-request en 'copy as curl' kiezen.

[DukeBox]

eric.1 schreef op donderdag 20 december 2018 @ 13:00:
Ja, die webshop zit op 37.97.141.198, en de TS zijn bedrijf op 37.97.177.103?

Kees schreef op donderdag 20 december 2018 @ 13:38:
Nee, je krijgt een '302 Found' terug, dus een redirect. Mischien dat ze bij liebherr iedereen met jullie ip redirecten naar je eigen site om een of andere reden.

Best kans dat hier ergens een relatie in zit..
Ah.. niet iedere interne host reageert het zelfde.. dan geen idee, succes.

[ Voor 8% gewijzigd door DukeBox op 21-12-2018 13:51 ]

[Verwijderd]

Kees schreef op donderdag 20 december 2018 @ 13:38:
Nee, je krijgt een '302 Found' terug, dus een redirect. Mischien dat ze bij liebherr iedereen met jullie ip redirecten naar je eigen site om een of andere reden.

Het meest eenvoudige is dat te checken met een commandline tool; bijvoorbeeld curl. Je kan dan rechtsclicken op de 302-request en 'copy as curl' kiezen.

Sorry, dat bedoelde ik ook. Ik verwacht het niet. Ons bedrijf heeft in principe niets met Liebherr-webshop te maken, waarschijnlijk kennen ze ons niet eens . Liebherr is een leverancier van een onderliggend bedrijfje van ons. De www.liebherr-webshop.nl is weer een soort wederverkoper van het merk Liebherr (denk ik).


Als ik middels de server (192.168.9.6) naar de website van www.liebherr-webshop.nl ga kom ik er namelijk wel gewoon. Ik kreeg even het vermoeden dat ik misschien nog een regel had toegevoegd dat alle 302 statussen automatisch worden geredirect naar onze eigen website. Echter maakt de server ook gebruik van zijn eigen DNS server...

Een vergelijkbaar topic en probleem:

https://networkengineering.stackexchange.com/questions/20224/http-302-redirect-is-this-my-problem

[ Voor 11% gewijzigd door Verwijderd op 20-12-2018 15:07 . Reden: typo ]

[Verwijderd]

[Ryanirin]

Klinkt idd als mogelijk een firewall dingetje. tracert gaat via icmp wat wellicht wel wordt toegestaan. De firewall zit blijkbaar aan de inside waardoor het verkeer vanaf de server zelf niet wordt gefiltert.
Waarom die website dan wordt gefiltert weet ik niet, maar indien je inderdaad iets van een firewall draait zou je dat in de logging moeten kunnen zien.

[Atlantis1995]

Het zou goed een firewall dingetje kunnen zijn. Als je wat tests aware zijn van combie van wel/geen www en http/https.

[Verwijderd]

Ik heb alle firewall rules eens doorgenomen, uitgeschakeld en getest. Helaas wordt ik er niet veel wijzer van en de redirect blijft aanwezig. Hierbij meteen eens alles in de IIS manager bekeken.

Hier zou ik juist verwachten dat er een HTTP rule ingesteld zou zijn. Echter blijkt alles leeg:




Core server (fysiek aanwezig) - 192.168.9.5 - krijgt een redirect
Virtuele server (AD/DNS/DHCP) - 192.168.9.6 - GEEN problemen
Virtuele server (PIM) - 192.168.9.8 - krijgt een redirect
PC - 192.168.9.243 - krijgt een redirect


Ik vraag me nu af in welke server ik het eigenlijk moet zoeken. Core of de AD? Gezien de AD server zelf wel de juiste website krijgt.

[valkenier]

Verwijderd schreef op donderdag 20 december 2018 @ 15:00:
[Afbeelding]

Die onderstreepte tekst: van wie is die? Er staat toch wat er aan de hand is, and now everything is running good?

Maar dat is dus niet zo?

[ Voor 5% gewijzigd door valkenier op 21-12-2018 16:08 ]

[Koffie]

Verwijderd schreef op woensdag 19 december 2018 @ 12:45:

Verwijderd schreef op woensdag 19 december 2018 @ 12:48:

Verwijderd schreef op woensdag 19 december 2018 @ 13:08:

Verwijderd schreef op woensdag 19 december 2018 @ 13:10:

Verwijderd schreef op donderdag 20 december 2018 @ 10:27:

Verwijderd schreef op donderdag 20 december 2018 @ 11:29:

Verwijderd schreef op donderdag 20 december 2018 @ 11:36:

Graag gewoon in 1 keer reageren op de vragen/reacties ipv allemaal losse posts onderelkaar.
Als je na het posten je bericht wil aanpassen kan dit dmv 'wijigen' knop.