16
Remoteapp funktioniert nicht - 2008r2
hallo zusammen,
nach etlichen stunden/tagen bin ich am ende meiner weisheit (und auch meiner nerven ...) - vielleicht hat jemand einen
tipp oder eine idee, was ich ev. übersehen habe ...
habe in meiner testumgebung win server 2008r2 aufgesetzt, einfache umgebung ... ad, dns, dhcp und remote-desktopdienste.
bei den rd-diensten sind die rollen lizenzsierung und eben die rd-dienste installiert.
habe das thema remoteapp in ruhe getestet, mal mit einfachen dingen, wie mit dem win-rechner, mal mit komplexeren dingen,
d.h. mit einer dafür angedachten anwendung ... nal mit in die domäne eingebundene pc's, mal mit welchen, die in einer beliebigen
arbeitsgruppe sind ... alles kein problem, alles lief wie erwartet ...
letzte woche wollte ich das ganze in produktionsumgebung einsetzen und dort bekomme ich das einfach nicht zum laufen:
(d.h. schon der win-calc lässt sich nicht aufrufen, d.h. an der anwendung kann es dann ja nicht liegen)
die remot-app bringt immer einen fehler "getrennte remote-app" und (habe ich auch schon getestet, je nachdem welchen
rd-client (6 od. 7) ich verwende) folgende "weitere hinweise":
was so komisch und nervig ist, ist die tatsache, daß lokal (pc angemeldet an domäne, im gleichen netz) beides geht - remote-
desktop-verbindung und remoteapp. greife ich von remote (pc nicht in domäne, internet, vpn über eine fw, dann weiter ins interne
netz, ...) darauf zu, dann funktioniert zwar die remote-desktop-verbindung problemlos, nur beim aufruf der remoteapp kommt der
besagte fehler. hab' schon gegoogelt wie wild, versucht in den logs am server und am client was zu finden ... nichts ...
(ist natürlich egal ob die remote-apps per installer-paket verteilt werden oder per rdp-datei)
dass die ext. fw hier irgendwie ihre finger im spiel haben könnte, wäre ja naheliegend, aber nicht unbedingt eindeutig ... rd-verbindung
und remote-app verwenden doch den gleichen port ... für mich stellt sich einfach die frage, was da offensichtlich der kleine feine
unterschied ist, der die remote-app scheitern lässt und die rd-verbindung problemlos ermöglicht ? irgendwie kommen die remote-
apps nicht "durch", vermute irgendein netzwerkproblem (namensauflösung ?) od. rechte-problem (?) ... wenn ich nur wüsste, wo solche
fehler protokolliert werden, dann könnte man ja dort weitersuchen ...
in meiner test-umgebung funktioniert es nach wie vor, aber da greife ich ja auch nicht von extern darauf zu ....
den server in echt-umgebung kann ich nicht so einfach neu aufsetzen, falls das was bringen könnte .... die rd-dienste habe ich bereits
einmal entfernt und als rolle wieder hinzugefügt - ohne erfolg.
wäre euch wahnsinnig dankbar, wenn jemand einen tipp hätte oder zumindest eine idee hätte, wo ich suchen kann ...
DANKE !
lg rp
nach etlichen stunden/tagen bin ich am ende meiner weisheit (und auch meiner nerven ...) - vielleicht hat jemand einen
tipp oder eine idee, was ich ev. übersehen habe ...
habe in meiner testumgebung win server 2008r2 aufgesetzt, einfache umgebung ... ad, dns, dhcp und remote-desktopdienste.
bei den rd-diensten sind die rollen lizenzsierung und eben die rd-dienste installiert.
habe das thema remoteapp in ruhe getestet, mal mit einfachen dingen, wie mit dem win-rechner, mal mit komplexeren dingen,
d.h. mit einer dafür angedachten anwendung ... nal mit in die domäne eingebundene pc's, mal mit welchen, die in einer beliebigen
arbeitsgruppe sind ... alles kein problem, alles lief wie erwartet ...
letzte woche wollte ich das ganze in produktionsumgebung einsetzen und dort bekomme ich das einfach nicht zum laufen:
(d.h. schon der win-calc lässt sich nicht aufrufen, d.h. an der anwendung kann es dann ja nicht liegen)
die remot-app bringt immer einen fehler "getrennte remote-app" und (habe ich auch schon getestet, je nachdem welchen
rd-client (6 od. 7) ich verwende) folgende "weitere hinweise":
was so komisch und nervig ist, ist die tatsache, daß lokal (pc angemeldet an domäne, im gleichen netz) beides geht - remote-
desktop-verbindung und remoteapp. greife ich von remote (pc nicht in domäne, internet, vpn über eine fw, dann weiter ins interne
netz, ...) darauf zu, dann funktioniert zwar die remote-desktop-verbindung problemlos, nur beim aufruf der remoteapp kommt der
besagte fehler. hab' schon gegoogelt wie wild, versucht in den logs am server und am client was zu finden ... nichts ...
(ist natürlich egal ob die remote-apps per installer-paket verteilt werden oder per rdp-datei)
dass die ext. fw hier irgendwie ihre finger im spiel haben könnte, wäre ja naheliegend, aber nicht unbedingt eindeutig ... rd-verbindung
und remote-app verwenden doch den gleichen port ... für mich stellt sich einfach die frage, was da offensichtlich der kleine feine
unterschied ist, der die remote-app scheitern lässt und die rd-verbindung problemlos ermöglicht ? irgendwie kommen die remote-
apps nicht "durch", vermute irgendein netzwerkproblem (namensauflösung ?) od. rechte-problem (?) ... wenn ich nur wüsste, wo solche
fehler protokolliert werden, dann könnte man ja dort weitersuchen ...
in meiner test-umgebung funktioniert es nach wie vor, aber da greife ich ja auch nicht von extern darauf zu ....
den server in echt-umgebung kann ich nicht so einfach neu aufsetzen, falls das was bringen könnte .... die rd-dienste habe ich bereits
einmal entfernt und als rolle wieder hinzugefügt - ohne erfolg.
wäre euch wahnsinnig dankbar, wenn jemand einen tipp hätte oder zumindest eine idee hätte, wo ich suchen kann ...
DANKE !
lg rp
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 145801
Url: https://administrator.de/contentid/145801
Printed on: April 23, 2024 at 21:04 o'clock
16 Comments
Latest comment
Verwendest du von Extern den gleichen DNS Namen zu Verbinden wie von Intern?
Wenn nicht, könntest du ein Problem mit deinem Sicherheitszertifikat haben.
Intern stimmt der FQDN mit dem Zertifikat überein.
Extern verbindest du dich mit dem Remoteapp über IP oder einen anderen DNS Namen.
Der stimmt mit dem Zertifikat nicht überein.
RD-Verbindung und remoteapp verwenden tatsächlich den gleichen Port, daran kann es nicht liegen.
Hast du nur den einen TS oder eine gesamte Farm mit TS-Gateway usw?
Hast du deine Remoteapps mit einem Zertifikat signiert? Wenn nicht, probier das mal und erstelle danach das remoteapp neu.
(Bei den remoteapp eigenschaften unter digitale signatur)
Wenn nicht, könntest du ein Problem mit deinem Sicherheitszertifikat haben.
Intern stimmt der FQDN mit dem Zertifikat überein.
Extern verbindest du dich mit dem Remoteapp über IP oder einen anderen DNS Namen.
Der stimmt mit dem Zertifikat nicht überein.
RD-Verbindung und remoteapp verwenden tatsächlich den gleichen Port, daran kann es nicht liegen.
Hast du nur den einen TS oder eine gesamte Farm mit TS-Gateway usw?
Hast du deine Remoteapps mit einem Zertifikat signiert? Wenn nicht, probier das mal und erstelle danach das remoteapp neu.
(Bei den remoteapp eigenschaften unter digitale signatur)
noch was:
ist es der komplett gleiche client der intern funktioniert aber von extern nicht?
ist der client mit dem du dich extern über vpn einwählst in der domäne?
ist es der komplett gleiche client der intern funktioniert aber von extern nicht?
ist der client mit dem du dich extern über vpn einwählst in der domäne?
hi,
danke für die rasche anwort !!!!!!!
ich werde heute abend alles testen - vorab folgende antworten zu deinen fragen:
TS oder Fram mit Gateway ?
habe nur einen "einfachen" ts !
Zertifikat ?
nein, habe (noch) keine zertifikate in verwendung - dort geht ja deine erste vermutung hin, das werde ich als erstes testen und nachholen ...
Gleicher Client intern wie extern ?
nein, das war/ist natürlich ein anderer pc wenngleich beide windows xp sp3 ... aber ich weiß, da kann viel unterschiedlich sein ...
wenn die zertifakte-geschichte nichts bringt, werde ich als nächstes morgen versuchen in produktionsumgebung mit ein und demselben client zu testen !
du bekommst sobald wie möglich feedback !
danke für die rasche anwort !!!!!!!
ich werde heute abend alles testen - vorab folgende antworten zu deinen fragen:
TS oder Fram mit Gateway ?
habe nur einen "einfachen" ts !
Zertifikat ?
nein, habe (noch) keine zertifikate in verwendung - dort geht ja deine erste vermutung hin, das werde ich als erstes testen und nachholen ...
Gleicher Client intern wie extern ?
nein, das war/ist natürlich ein anderer pc wenngleich beide windows xp sp3 ... aber ich weiß, da kann viel unterschiedlich sein ...
wenn die zertifakte-geschichte nichts bringt, werde ich als nächstes morgen versuchen in produktionsumgebung mit ein und demselben client zu testen !
du bekommst sobald wie möglich feedback !
was mir noch eingefallen ist:
wenn der externe rechner nicht in der domäne ist, musst du domain\username als benutzernamen angeben, und nicht nur username.
wenn der externe rechner nicht in der domäne ist, musst du domain\username als benutzernamen angeben, und nicht nur username.
jo und danke nochmals, das ist aber auch schon so, wenn man nicht remote reinkommt und nur im internen netz eine remoteapp starten möchte...
... auch die geschichte mit "domänen-name" vs. "server-name", was der server vorträgt, habe ich beachtet, aber soweit komme ich über remote gar nicht,
da kommen nicht mal der sonst übliche "sicherheitshinweis" und "zertifikate-hinweis", d.h. da blockt mich schon vorher was ... aber schau ma mal ...
... auch die geschichte mit "domänen-name" vs. "server-name", was der server vorträgt, habe ich beachtet, aber soweit komme ich über remote gar nicht,
da kommen nicht mal der sonst übliche "sicherheitshinweis" und "zertifikate-hinweis", d.h. da blockt mich schon vorher was ... aber schau ma mal ...
MIt den Zertifikaten hab ich mich selbst schon so lange rumgeärgert dass das passt, ua. habe ich auch die gleiche Meldung wie du bekommen, weil das Zertifikat was ich akzeptierte, trotzdem verweigert wurde. Da kommt dann die gleiche Meldung.
Du sagtest du kannst dich über RDP ganz normal verbinden. Funktioniert das auch als Benutzer oder nur als Admin?
kommst du eigentlich über https://servername/ts auf den TS webzugriff drauf?
Du sagtest du kannst dich über RDP ganz normal verbinden. Funktioniert das auch als Benutzer oder nur als Admin?
kommst du eigentlich über https://servername/ts auf den TS webzugriff drauf?
hi,
das mit den zertifikaten hat offensichtlich nichts gebracht ...
zu deinen fragen:
geht weder mit admin noch mit anderen usern, den ts-webzugriff habe ich nicht installiert !
ich komme aber immer mehr zur überzeugung, daß das mit der namensauflösung zu tun haben muss ... wenn das nicht die rd-verbindung wäre ...
egal, meine überzeugung begründet sich auf folgendem:
ich habe versucht, einen test-pc remote in die domäne zu heben - das müsste doch gehen, oder ?
er meint dabei, daß der domänenname der netbiosname sein könnte und man dann wins aktivieren sollte ...
naj, eigentlich klar daß auch das lokal funktioniert, weil hier vermutl. netbios leichter geht als über remote mit vpn usw. wird der name offensichtlich
nicht richtig aufgelöst ...
fürchte bei meinem dns am server ist etwas nicht ganz sauber .... nur ich gebe jetzt langsam zu, daß bei dns und namensauflösung über remote ich
da an meine grenzen stosse ...
naja, vielleicht hilfst du od. jemand anderer mir trotzdem weiter ?!
ergänzung:
so grundsätzliche dinge, wie ping mit servernamen oder dns-namen funktioniert natürlich ... auch mit und ohne aufgebauter vpn-verbindung schon,
d.h. der server antortet von der ferne mit ip-adresse etc. ..... es muss irgendwo im detail liegen ... vielleicht sollte man mal drüner schlafen (hätte ich
aber schon ein zwei mal gemacht ;-() ) !!??
das mit den zertifikaten hat offensichtlich nichts gebracht ...
zu deinen fragen:
geht weder mit admin noch mit anderen usern, den ts-webzugriff habe ich nicht installiert !
ich komme aber immer mehr zur überzeugung, daß das mit der namensauflösung zu tun haben muss ... wenn das nicht die rd-verbindung wäre ...
egal, meine überzeugung begründet sich auf folgendem:
ich habe versucht, einen test-pc remote in die domäne zu heben - das müsste doch gehen, oder ?
er meint dabei, daß der domänenname der netbiosname sein könnte und man dann wins aktivieren sollte ...
naj, eigentlich klar daß auch das lokal funktioniert, weil hier vermutl. netbios leichter geht als über remote mit vpn usw. wird der name offensichtlich
nicht richtig aufgelöst ...
fürchte bei meinem dns am server ist etwas nicht ganz sauber .... nur ich gebe jetzt langsam zu, daß bei dns und namensauflösung über remote ich
da an meine grenzen stosse ...
naja, vielleicht hilfst du od. jemand anderer mir trotzdem weiter ?!
ergänzung:
so grundsätzliche dinge, wie ping mit servernamen oder dns-namen funktioniert natürlich ... auch mit und ohne aufgebauter vpn-verbindung schon,
d.h. der server antortet von der ferne mit ip-adresse etc. ..... es muss irgendwo im detail liegen ... vielleicht sollte man mal drüner schlafen (hätte ich
aber schon ein zwei mal gemacht ;-() ) !!??
Zitat von @rolpau:
hi,
das mit den zertifikaten hat offensichtlich nichts gebracht ...
zu deinen fragen:
geht weder mit admin noch mit anderen usern, den ts-webzugriff habe ich nicht installiert !
ich komme aber immer mehr zur überzeugung, daß das mit der namensauflösung zu tun haben muss ... wenn das nicht
die rd-verbindung wäre ...
hi,
das mit den zertifikaten hat offensichtlich nichts gebracht ...
zu deinen fragen:
geht weder mit admin noch mit anderen usern, den ts-webzugriff habe ich nicht installiert !
ich komme aber immer mehr zur überzeugung, daß das mit der namensauflösung zu tun haben muss ... wenn das nicht
die rd-verbindung wäre ...
Du hast gesagt du kannst dich extern über RDP verbinden aber mit dem RemoteApp nicht.
Wenn du im RemoteApp den gleichen DNS Namen wie für RDP verwendest (kontrollier das mal), kann es kein DNS Problem sein. Sonst ginge ja RDP auch nicht.
egal, meine überzeugung begründet sich auf folgendem:
ich habe versucht, einen test-pc remote in die domäne zu heben - das müsste doch gehen, oder ?
ich habe versucht, einen test-pc remote in die domäne zu heben - das müsste doch gehen, oder ?
Nur wenn er mit VPN verbunden ist.
er meint dabei, daß der domänenname der netbiosname sein könnte und man dann wins aktivieren sollte ...
naj, eigentlich klar daß auch das lokal funktioniert, weil hier vermutl. netbios leichter geht als über remote mit vpn
usw. wird der name offensichtlich
nicht richtig aufgelöst ...
fürchte bei meinem dns am server ist etwas nicht ganz sauber .... nur ich gebe jetzt langsam zu, daß bei dns und
namensauflösung über remote ich
da an meine grenzen stosse ...
naja, vielleicht hilfst du od. jemand anderer mir trotzdem weiter ?!
ergänzung:
so grundsätzliche dinge, wie ping mit servernamen oder dns-namen funktioniert natürlich ... auch mit und ohne
aufgebauter vpn-verbindung schon,
d.h. der server antortet von der ferne mit ip-adresse etc. ..... es muss irgendwo im detail liegen ... vielleicht sollte man mal
drüner schlafen (hätte ich
aber schon ein zwei mal gemacht ;-() ) !!??
Dann beschreib bitte mal wie dein Netzwerk aussieht.naj, eigentlich klar daß auch das lokal funktioniert, weil hier vermutl. netbios leichter geht als über remote mit vpn
usw. wird der name offensichtlich
nicht richtig aufgelöst ...
fürchte bei meinem dns am server ist etwas nicht ganz sauber .... nur ich gebe jetzt langsam zu, daß bei dns und
namensauflösung über remote ich
da an meine grenzen stosse ...
naja, vielleicht hilfst du od. jemand anderer mir trotzdem weiter ?!
ergänzung:
so grundsätzliche dinge, wie ping mit servernamen oder dns-namen funktioniert natürlich ... auch mit und ohne
aufgebauter vpn-verbindung schon,
d.h. der server antortet von der ferne mit ip-adresse etc. ..... es muss irgendwo im detail liegen ... vielleicht sollte man mal
drüner schlafen (hätte ich
aber schon ein zwei mal gemacht ;-() ) !!??
Du sagst du kannst den Server von extern mit und ohne VPN pingen.
Heisst das der Server hängt direkt am internet, ohne Firewall dazwischen?
Vielleicht hast du auch bei den Remoteapps wirklich einen anderen Port eingestellt.
Kontrolliere bitte mal bei den Remoteappseigenschaften unter Terminalserver ob der Servername wirklich der gleiche ist wie der, der auch über RDP funktioniert.
Zitat von @sniffnase:
> Zitat von @rolpau:
> ----
> hi,
>
> das mit den zertifikaten hat offensichtlich nichts gebracht ...
>
> zu deinen fragen:
> geht weder mit admin noch mit anderen usern, den ts-webzugriff habe ich nicht installiert !
>
> ich komme aber immer mehr zur überzeugung, daß das mit der namensauflösung zu tun haben muss ... wenn das
nicht
> die rd-verbindung wäre ...
>
Du hast gesagt du kannst dich extern über RDP verbinden aber mit dem RemoteApp nicht.
Wenn du im RemoteApp den gleichen DNS Namen wie für RDP verwendest (kontrollier das mal), kann es kein DNS Problem sein.
Sonst ginge ja RDP auch nicht.
> Zitat von @rolpau:
> ----
> hi,
>
> das mit den zertifikaten hat offensichtlich nichts gebracht ...
>
> zu deinen fragen:
> geht weder mit admin noch mit anderen usern, den ts-webzugriff habe ich nicht installiert !
>
> ich komme aber immer mehr zur überzeugung, daß das mit der namensauflösung zu tun haben muss ... wenn das
nicht
> die rd-verbindung wäre ...
>
Du hast gesagt du kannst dich extern über RDP verbinden aber mit dem RemoteApp nicht.
Wenn du im RemoteApp den gleichen DNS Namen wie für RDP verwendest (kontrollier das mal), kann es kein DNS Problem sein.
Sonst ginge ja RDP auch nicht.
ja, wir kommen der sache schon näher, denke das war ein/der entscheidender tipp !!!
hab' ich überprüft: bei der rd-verbindung verwende ich eine ip-adresse (die interne des servers,aus dem lan, nach aufbau des vpn-tunnel),
die remoteapp verwendet natürlich eines/den dns-namen, der vom remot-app-manager bei erstellung standardmäßig vorgeschlagen wird.
kurzer test: ich erstelle die remote-app mit der internen ip-adresse - siehe da es funktioniert !!!!!
ergo, die auflösung des dns/-server-namen ergibt nicht die gewünschte ip ... ??
> egal, meine überzeugung begründet sich auf folgendem:
> ich habe versucht, einen test-pc remote in die domäne zu heben - das müsste doch gehen, oder ?
Nur wenn er mit VPN verbunden ist.
> ich habe versucht, einen test-pc remote in die domäne zu heben - das müsste doch gehen, oder ?
Nur wenn er mit VPN verbunden ist.
klar, hatte ich natürlich davon - aber ich denke dort herrscht dasselbe problem !
> er meint dabei, daß der domänenname der netbiosname sein könnte und man dann wins aktivieren sollte ...
> naj, eigentlich klar daß auch das lokal funktioniert, weil hier vermutl. netbios leichter geht als über remote mit vpn
> usw. wird der name offensichtlich
> nicht richtig aufgelöst ...
>
> fürchte bei meinem dns am server ist etwas nicht ganz sauber .... nur ich gebe jetzt langsam zu, daß bei dns und
> namensauflösung über remote ich
> da an meine grenzen stosse ...
> naja, vielleicht hilfst du od. jemand anderer mir trotzdem weiter ?!
>
>
> ergänzung:
> so grundsätzliche dinge, wie ping mit servernamen oder dns-namen funktioniert natürlich ... auch mit und ohne
> aufgebauter vpn-verbindung schon,
> d.h. der server antortet von der ferne mit ip-adresse etc. ..... es muss irgendwo im detail liegen ... vielleicht sollte man mal
> drüner schlafen (hätte ich
> aber schon ein zwei mal gemacht ;-() ) !!??
>
>
>
>
Dann beschreib bitte mal wie dein Netzwerk aussieht.
Du sagst du kannst den Server von extern mit und ohne VPN pingen.
Heisst das der Server hängt direkt am internet, ohne Firewall dazwischen?
> naj, eigentlich klar daß auch das lokal funktioniert, weil hier vermutl. netbios leichter geht als über remote mit vpn
> usw. wird der name offensichtlich
> nicht richtig aufgelöst ...
>
> fürchte bei meinem dns am server ist etwas nicht ganz sauber .... nur ich gebe jetzt langsam zu, daß bei dns und
> namensauflösung über remote ich
> da an meine grenzen stosse ...
> naja, vielleicht hilfst du od. jemand anderer mir trotzdem weiter ?!
>
>
> ergänzung:
> so grundsätzliche dinge, wie ping mit servernamen oder dns-namen funktioniert natürlich ... auch mit und ohne
> aufgebauter vpn-verbindung schon,
> d.h. der server antortet von der ferne mit ip-adresse etc. ..... es muss irgendwo im detail liegen ... vielleicht sollte man mal
> drüner schlafen (hätte ich
> aber schon ein zwei mal gemacht ;-() ) !!??
>
>
>
>
Dann beschreib bitte mal wie dein Netzwerk aussieht.
Du sagst du kannst den Server von extern mit und ohne VPN pingen.
Heisst das der Server hängt direkt am internet, ohne Firewall dazwischen?
nein, der server hat natürlich eine firewall davor. über die wird die vpn-verbindung aufgebaut und die routet in das interne netz.
mit erreichbar per ping meinte ich, daß bei ping auf server-/dns-namen ip-adressen zurückgeliefert werden, also im prinzip eine auflösung
erfolgt und nicht irgendeine fehlermeldung. offensichtlich werden aber nicht die richtigen geliefert, was ja der obige test mit direkt eingetragener
bewiesen hat.
Vielleicht hast du auch bei den Remoteapps wirklich einen anderen Port eingestellt.
Kontrolliere bitte mal bei den Remoteappseigenschaften unter Terminalserver ob der Servername wirklich der gleiche ist wie der,
der auch über RDP funktioniert.
Kontrolliere bitte mal bei den Remoteappseigenschaften unter Terminalserver ob der Servername wirklich der gleiche ist wie der,
der auch über RDP funktioniert.
anderer port bei remote-app war nicht der grund - siehe oben !
... und servername: wie gesagt, war/ist unterschiedlich !
so, nun wie mache ich da weiter ... ?!
was meinst du ... ich meine, ich könnte bei der erstellung meiner remote-apps die interne ip einbinden, dann funktioniert das ja jetzt, aber ich denke
das wäre nicht so schlau und irgendwie möchte ich meinen denk-/konfigurationsfehler am server finden ... damit meine ich, daß ein ping auf den
server-/dns-namen die richtige ip-adresse liefert ...
betrachten wir mal den server:
bei einem ping auf den im dns in den forwardlookupzone eingetragenen namen liefert die richtige ip-adresse (ip4)
bei einem ping auf den server-namen bekomme ich die ip6-adresse zurück - denke das ist schon mal nicht richtig, oder ?
betrachten wir mal den client:
sobald ich die vpn-verbindung aufgebaut habe liefert der ping auf den dns-namen eben nicht die gewünschte (interne) adresse !
vielleicht setzt mir auch die firewall etwas falsch um, dort wurde aber nichts geändert ??
hab' zwar schon einiges getestet, aber den endgültigen click hat es noch nicht gemacht ... ?
Anscheinend verwendet er (der client), wenn du eine VPN Verbindung aufgebaut hast, nicht den DNS Server deiner Domäne.
Überprüfe das mal mit.
ipconfig /all
Bei deinem VPN Interface muss bei DNS die IP Adresse deines Internen DNS Servers stehen.
du kannst auch mal eine DOS Box aufmachen und folgendes probieren
nslookup
terminalservername
Ergebnis: ????
server 10.10.10.10 (internerDNS)
terminalservername
Ergebnis: ????
Wenn das 2te ergebnis richtig ist, dann funktioniert eigentlich alles.
Bis auf das, dass du standardmäßig den falschen DNS Server verwendest.
Wie wird die VPN Verbindung aufgebaut - gibt es einen eigenen VPN Client oder wird eine normale windows VPN Verbindung aufgebaut?
Überprüfe das mal mit.
ipconfig /all
Bei deinem VPN Interface muss bei DNS die IP Adresse deines Internen DNS Servers stehen.
du kannst auch mal eine DOS Box aufmachen und folgendes probieren
nslookup
terminalservername
Ergebnis: ????
server 10.10.10.10 (internerDNS)
terminalservername
Ergebnis: ????
Wenn das 2te ergebnis richtig ist, dann funktioniert eigentlich alles.
Bis auf das, dass du standardmäßig den falschen DNS Server verwendest.
Wie wird die VPN Verbindung aufgebaut - gibt es einen eigenen VPN Client oder wird eine normale windows VPN Verbindung aufgebaut?
das hatte ich schon mal kontrolliert - die dns-adresse ist beim tool für den vpn-aufbau (windows vpn-client) eingetragen ...
ipconfig/all liefert(e) auch immer den richtigen dns-server
nslookup mit dns-namen des servers liefert mir als erstes die ip-adresse(n) meiner auf dem test-pc bei der netwerkkarte eingetragenen dns-server
und als zweites namen und ip-adresse meines besagten servers (aber eben nicht die richtige/interne ip-adresse) ??
als vpn-client verwende ich den windows client, das gegenstück bildet eine fortigate ...
vielleicht liegt's doch an der fw ?
ipconfig/all liefert(e) auch immer den richtigen dns-server
nslookup mit dns-namen des servers liefert mir als erstes die ip-adresse(n) meiner auf dem test-pc bei der netwerkkarte eingetragenen dns-server
und als zweites namen und ip-adresse meines besagten servers (aber eben nicht die richtige/interne ip-adresse) ??
als vpn-client verwende ich den windows client, das gegenstück bildet eine fortigate ...
vielleicht liegt's doch an der fw ?
Nein,
Der Client verwendet standardmäßig den DNS Server der Normalen Netzwerkverbindung, anstelle den der VPN Verbindung.
Wenn du den Fortigate VPN Client verwendest stellt der das während der Verbindung automatisch um.
Du kannst das Lösen indem du deinem LAN-Interface als Primären DNS die IP Adresse deines internen (VPN) DNS Servers angibst.
Als Sekundären gibst du den ursprünglichen DNS Server deines LAN-Interfaces ein
Der Client verwendet standardmäßig den DNS Server der Normalen Netzwerkverbindung, anstelle den der VPN Verbindung.
Wenn du den Fortigate VPN Client verwendest stellt der das während der Verbindung automatisch um.
Du kannst das Lösen indem du deinem LAN-Interface als Primären DNS die IP Adresse deines internen (VPN) DNS Servers angibst.
Als Sekundären gibst du den ursprünglichen DNS Server deines LAN-Interfaces ein
Sorry hab vorher was überlesen 
das versteh ich jetzt nicht ganz.
Du bekommst also von deinem internen DNS Server eine falsche IP Adresse zurück?
also mit 'nslookup deinterminalserver' bekommst du nicht die richtige ip adresse deines servers zurück?
selbst wenn dus so machst:
Dann stimmt nämlich etwas an deinem internen DNS Server nicht der für VPN eingetragen ist. Hast du da die Fortigate als DNS eingetragen und nciht den DC?
und als zweites namen und ip-adresse meines besagten servers (aber eben nicht die richtige/interne ip-adresse) ??
das versteh ich jetzt nicht ganz.
Du bekommst also von deinem internen DNS Server eine falsche IP Adresse zurück?
also mit 'nslookup deinterminalserver' bekommst du nicht die richtige ip adresse deines servers zurück?
selbst wenn dus so machst:
nslookup
server 10.20.30.40 (InternerDNS)
TerminalServerDann stimmt nämlich etwas an deinem internen DNS Server nicht der für VPN eingetragen ist. Hast du da die Fortigate als DNS eingetragen und nciht den DC?
sorry, aber irgendwie zeigt sich der client unbeeindruckt, ich habe da mit den dns-einträgen schon gestern experimentiert und
auch jetzt auf deinen hinweis hin nochmals - der ping auf dns-name, wie auch nslookup liefert mir immer die gleiche ip-adresse
(eine 68.178.232....) und nicht die gewünschte (192.168....).
zu deiner vorangegangenen frage:
vielleicht habe ich mich nicht klar ausgedrückt: auf den pc's wie auf meinem aktuellen test-pc laufen die windows-vpn-clients,
nicht fortigate-vpn-clients ... aber ich denke das ist egal ...
zu deiner 2.frage:
genau an dem suche ich gerade wie verrückt ... ?
nein, die ip der fortigate habe ich nirgends am server in verwendung.
was festgesetllt habe:
ich bekomme als antort auf einen ping auf dns-server-name (hugo.server.com) die richtige adresse, ok gut !
warum bekomme ich als antwort auf einen ping auf den maschinennamen (server-hugo) einer ip6-adresse und nicht mit der ip4-adresse ?
warum bringt mit der nslookup mit dem domänennamen (hugo) als erstes "unknown" und als adresse "::1" (ip6) und als zweites den richtigen
dns-namen (hugo.server.com) mit der richtigen ip (192.168.....) ?
warum bringt mit der nslookup mit dem dns-namen (hugo.server.com) als erstes "unknown" und als adresse "::1" (ip6) und als zweites ebenfalls
einen falschen namen (hugo.server.com.server.com) und die besagte "falsche" ip die ich auch über vpn bekomme ?
ich befürchte, wenn ich den konfigurationsfehler nicht finde, ist es zeit den dns-server in ruhe neu aufzusetzen ....
aber das mache ich natürlich nur vor ort !
ich habe deine zeit schon so sehr in anspruch genommen und bin dir wahnsinnig (!!) dankbar, mich in die richtige ecke geführt zu haben,
aber ich weiß nicht, ob DEIN aufwand sich weiter lohnt bzw. dir das wert ist ?
wenn ich die remote-apps mit der internen ip-adresse ausstelle funktioniert das ja nun und ich sehe hier kein großes sicherheitsrisiko ...
der fehler liegt/lag eindeutig in der namensauflösung !
das mein dns-server irgendwo falsch konfiguriert ist, ist eine ander geschichte ...
auch jetzt auf deinen hinweis hin nochmals - der ping auf dns-name, wie auch nslookup liefert mir immer die gleiche ip-adresse
(eine 68.178.232....) und nicht die gewünschte (192.168....).
zu deiner vorangegangenen frage:
vielleicht habe ich mich nicht klar ausgedrückt: auf den pc's wie auf meinem aktuellen test-pc laufen die windows-vpn-clients,
nicht fortigate-vpn-clients ... aber ich denke das ist egal ...
zu deiner 2.frage:
genau an dem suche ich gerade wie verrückt ... ?
nein, die ip der fortigate habe ich nirgends am server in verwendung.
was festgesetllt habe:
ich bekomme als antort auf einen ping auf dns-server-name (hugo.server.com) die richtige adresse, ok gut !
warum bekomme ich als antwort auf einen ping auf den maschinennamen (server-hugo) einer ip6-adresse und nicht mit der ip4-adresse ?
warum bringt mit der nslookup mit dem domänennamen (hugo) als erstes "unknown" und als adresse "::1" (ip6) und als zweites den richtigen
dns-namen (hugo.server.com) mit der richtigen ip (192.168.....) ?
warum bringt mit der nslookup mit dem dns-namen (hugo.server.com) als erstes "unknown" und als adresse "::1" (ip6) und als zweites ebenfalls
einen falschen namen (hugo.server.com.server.com) und die besagte "falsche" ip die ich auch über vpn bekomme ?
ich befürchte, wenn ich den konfigurationsfehler nicht finde, ist es zeit den dns-server in ruhe neu aufzusetzen ....
aber das mache ich natürlich nur vor ort !
ich habe deine zeit schon so sehr in anspruch genommen und bin dir wahnsinnig (!!) dankbar, mich in die richtige ecke geführt zu haben,
aber ich weiß nicht, ob DEIN aufwand sich weiter lohnt bzw. dir das wert ist ?
wenn ich die remote-apps mit der internen ip-adresse ausstelle funktioniert das ja nun und ich sehe hier kein großes sicherheitsrisiko ...
der fehler liegt/lag eindeutig in der namensauflösung !
das mein dns-server irgendwo falsch konfiguriert ist, ist eine ander geschichte ...
hallo "sniffnase",
ich denke ganz besonders dir und auch allen anderen bin ich endgültige lösung des problems "schuldig":
also zuerst das thema meines vermeintlichen konfigurationsfehlers meines dns-servers bzw. zu meinen (teilweise "dummen") fragen, sorry:
ganz einfach, wenn man die hilfe zu ping liest, dann erfährt man, daß ein "ping server-hugo" - bei zumindest server 2008r (vermutl. auch bei win7 etc.)
immer die ip6-adresse liefert, will man die ip4, dann gibt es den parameter "-4" - also "ping -4 server-hugo"
das lag an den netzwerkeinstellung: aus irgendeinem grund war bei den eingeschaften der lanverbindung im ip-6-protokoll zwar automatisch beziehen,
beim dns-server aber dieser eintrag eingetragen. dort habe ich nach der installation natürlich nie nahcgesehen, weil ich ip6 nicht verwende.
irgendwo habe ich gelesen, daß viele leute empfehlen ip6 ebenfalls mit fixer adresse zu konfigurieren oder eben ganz zu deaktivieren - jetzt weiß ich u.a.
auch warum !!
selbes problem wie oben !
und zum einetlichen problem am xp-client - siehe hier:
http://www.itprofaq.com/ms_windows_allgemein/vpn-falsche-dns-auflosung- ...
... dann sollte alles klar sein ... zumindest löste das bei mir die probleme und ich kann jetzt in den remote-apps den "standard"-dns-namen verwendem !
ändert aber nichts daran, dir ein letztes mal ganz herzlichst für deine hilfe zu danken !!!!!!!
lg
rp
ich denke ganz besonders dir und auch allen anderen bin ich endgültige lösung des problems "schuldig":
also zuerst das thema meines vermeintlichen konfigurationsfehlers meines dns-servers bzw. zu meinen (teilweise "dummen") fragen, sorry:
Zitat von @rolpau:
was festgesetllt habe:
ich bekomme als antort auf einen ping auf dns-server-name (hugo.server.com) die richtige adresse, ok gut !
warum bekomme ich als antwort auf einen ping auf den maschinennamen (server-hugo) einer ip6-adresse und nicht mit der ip4-adresse ?
was festgesetllt habe:
ich bekomme als antort auf einen ping auf dns-server-name (hugo.server.com) die richtige adresse, ok gut !
warum bekomme ich als antwort auf einen ping auf den maschinennamen (server-hugo) einer ip6-adresse und nicht mit der ip4-adresse ?
ganz einfach, wenn man die hilfe zu ping liest, dann erfährt man, daß ein "ping server-hugo" - bei zumindest server 2008r (vermutl. auch bei win7 etc.)
immer die ip6-adresse liefert, will man die ip4, dann gibt es den parameter "-4" - also "ping -4 server-hugo"
warum bringt mit der nslookup mit dem domänennamen (hugo) als erstes "unknown" und als adresse "::1" (ip6) und als zweites den richtigen
dns-namen (hugo.server.com) mit der richtigen ip (192.168.....) ?
dns-namen (hugo.server.com) mit der richtigen ip (192.168.....) ?
das lag an den netzwerkeinstellung: aus irgendeinem grund war bei den eingeschaften der lanverbindung im ip-6-protokoll zwar automatisch beziehen,
beim dns-server aber dieser eintrag eingetragen. dort habe ich nach der installation natürlich nie nahcgesehen, weil ich ip6 nicht verwende.
irgendwo habe ich gelesen, daß viele leute empfehlen ip6 ebenfalls mit fixer adresse zu konfigurieren oder eben ganz zu deaktivieren - jetzt weiß ich u.a.
auch warum !!
warum bringt mit der nslookup mit dem dns-namen (hugo.server.com) als erstes "unknown" und als adresse "::1" (ip6) und als zweites ebenfalls
einen falschen namen (hugo.server.com.server.com) und die besagte "falsche" ip die ich auch über vpn bekomme ?
einen falschen namen (hugo.server.com.server.com) und die besagte "falsche" ip die ich auch über vpn bekomme ?
selbes problem wie oben !
und zum einetlichen problem am xp-client - siehe hier:
http://www.itprofaq.com/ms_windows_allgemein/vpn-falsche-dns-auflosung- ...
... dann sollte alles klar sein ... zumindest löste das bei mir die probleme und ich kann jetzt in den remote-apps den "standard"-dns-namen verwendem !
ändert aber nichts daran, dir ein letztes mal ganz herzlichst für deine hilfe zu danken !!!!!!!
lg
rp
war ja ein hartes stück arbeit - gern gschehn
