8
VPN - keine Verbindung zu Exchange
Guten Tag verehrte Kollegen,
ich betreibe lokal ein Netzwerk mit einer Windows Domäne.
Intern habe ich keine Schwierigkeiten.
Es geht um die "Roadwarrior" und alle Telnehmer, welche übers Internet über IPSec herein kommen.
Es ist nicht möglich, Outlook (2010 Standard) zum Exchange 2003 zu vermitteln.
Der Aufbau ist sehr grob umrissen in etwa so:
- Externer Internetzugang wird aufgebaut
- IPSec Einwahl positiv (IKE Phase 1 aggressive mode und IKE Phase 2, XAUTH, manuelle Schlüsselverwaltung...)
keinerlei Fehlermeldungen, alles andere funktioniert, Zugriff auf diverse Systeme (ports), Filesystem und weitere.
Sämtliche Tests funktionieren, Ping, Traceroute, DNS Auflösung.
Die Firewall lässt Verkehr von authentifizierten Teilnehmern an alle lokalen Server zu, es gibt keine Einschränkungen.
die lokale Clientfirewall ist aus.
Outlook Web access funktioniert ebenso.
Die Systemlandschaft sieht in etwa so aus:
Client:
keine Firewall für VPN
Gateway:
Server:
die Systeme sind noch relativ einfach gehalten, also keine zertifikate oder dergleichen.
Netzwerkbeziehungen scheinen auch zu stimmen.
Ich stehe vor einem Rätsel und hoffe, dass dies schonmal jemand gelöst bekam.
Vielen Dank
ich betreibe lokal ein Netzwerk mit einer Windows Domäne.
Intern habe ich keine Schwierigkeiten.
Es geht um die "Roadwarrior" und alle Telnehmer, welche übers Internet über IPSec herein kommen.
Es ist nicht möglich, Outlook (2010 Standard) zum Exchange 2003 zu vermitteln.
Der Aufbau ist sehr grob umrissen in etwa so:
- Externer Internetzugang wird aufgebaut
- IPSec Einwahl positiv (IKE Phase 1 aggressive mode und IKE Phase 2, XAUTH, manuelle Schlüsselverwaltung...)
keinerlei Fehlermeldungen, alles andere funktioniert, Zugriff auf diverse Systeme (ports), Filesystem und weitere.
Sämtliche Tests funktionieren, Ping, Traceroute, DNS Auflösung.
Die Firewall lässt Verkehr von authentifizierten Teilnehmern an alle lokalen Server zu, es gibt keine Einschränkungen.
die lokale Clientfirewall ist aus.
Outlook Web access funktioniert ebenso.
Die Systemlandschaft sieht in etwa so aus:
Client:
Win 7 Pro (64bit) : outlook 2010 (14.0.4760.1000 32 bit)
IPSec Client: Lancom Advanced VPN Client v2.31 Build 104 (also NCP Client)keine Firewall für VPN
Gateway:
Lancom 9100 VPN FW: 8.82.0100RU1
Firewall erlaubt sämtlichen traffic zwischen VPN Teilnehmern und lokalem Netz mit Bandbreitengarantie von min. 512 kbit/sServer:
Windows 2003 mit Exchange 2003 aktuellestes Patchlevel
keine lokale Firewalldie Systeme sind noch relativ einfach gehalten, also keine zertifikate oder dergleichen.
Netzwerkbeziehungen scheinen auch zu stimmen.
Ich stehe vor einem Rätsel und hoffe, dass dies schonmal jemand gelöst bekam.
Vielen Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 219434
Url: https://administrator.de/forum/vpn-keine-verbindung-zu-exchange-219434.html
Ausgedruckt am: 31.12.2024 um 20:12 Uhr
8 Kommentare
Neuester Kommentar
Schlüsselfrage: Kannst du vom Outlook Client den Exchange anpingen ?
Wenn das möglich ist, also die IP Connectivity da ist, ist es kein Netzwerk Problem soviel ist dann schon mal sicher.
Da bleibt dann nur ein simples Microsoft Rechte Problem oder das du doch irgendwo vergessen hast die Firewall auszuschalten und das nicht weisst.
Wenn das möglich ist, also die IP Connectivity da ist, ist es kein Netzwerk Problem soviel ist dann schon mal sicher.
Da bleibt dann nur ein simples Microsoft Rechte Problem oder das du doch irgendwo vergessen hast die Firewall auszuschalten und das nicht weisst.
Da gab es doch ein Problem mit der MTU Size ich hatte dies mal.
http://www.dslreports.com/drtcp
Musste mit diesem Tool die Size verändern.
lg
http://www.dslreports.com/drtcp
Musste mit diesem Tool die Size verändern.
lg
Hallo Aqui, ja, ping geht, IP sowie FQDN. Lokal ist es das selbe Setup und keine Schwierigkeiten.
Hallo goscho, danke, aber hat nicht geholfen, obwohl es schon Sinn macht.
und nslookup Exchangeserver?
User ist per Client-VPN verbunden und Outlook verbindet nicht mehr?
Es geht sonst alles, außer Outlook 2010 mit Exchange?
Ich habe bei mir und meinen Kunden zumeist den kostenlosen Shrew-Clienten laufen.
Deine Probleme habe ich bei funktionierender VPN-Verbindung noch nicht gehabt.
Vielleicht ist es ja mal einen Test wert.
Wenn das alle deine User mit Client-VPN betrifft, würde ich doch mal den Lancom-Support bemühen.
Lokal ist es das selbe Setup und keine Schwierigkeiten.
User ist im LAN -> Outlook verbindet mit dem Exchange.User ist per Client-VPN verbunden und Outlook verbindet nicht mehr?
Es geht sonst alles, außer Outlook 2010 mit Exchange?
Ich habe bei mir und meinen Kunden zumeist den kostenlosen Shrew-Clienten laufen.
Deine Probleme habe ich bei funktionierender VPN-Verbindung noch nicht gehabt.
Vielleicht ist es ja mal einen Test wert.
Wenn das alle deine User mit Client-VPN betrifft, würde ich doch mal den Lancom-Support bemühen.
Verhehrte Kollegen,
ich hab die Lösung gefunden und wollte nun alle teilhaben lassen, damit dies für alle Ewigkeiten dokumentiert ist und niemanden mehr Haare kostet.
Vorab bedanke ich mich für die Hilfe und die Vorschläge bei euch.
Also:
Der Lancom Advanced VPN Client ( NCP Client oder auch Watchguard client ) hat in jedem Einwahlprofil eigene Link firewall Einstellungen, welche nun bei Aktivität den Traffic filtern. Da ich für die Clientlaptops die Windows Firewall und für die Absicherung des Intranets ausschliesslich die Firewall des Gateways nutze, lasse ich die VPN Client Firewall aus.
Nun bin ich in meiner Naivität davon ausgegangen, dass ich bei ausgeschalteter Stateful Inspection (so heisste die Option ) nichts weiter beachten muss, denn aus ist aus, so gibt es die Maske intuitiv her.
Ist aber falsch angenommen. Darauf gekommen bin ich durch Traces auf den Clients, der NCP Client (Lancom, Watchdog...) bietet einen klasse Tracer, das LANTrace.exe, welches im Programmroot des clients zu finden ist.
hier tauchten immer wieder folgende Zeilen bei Verbindungsaufbau mit dem Mailserver auf:
Fri Oct 18 11:44:03 2013:Link: ipv4_sndreq - len=52,srcipa=VPN-IP,dstipa=Ziel_Mailserver,srcprt=56693,dstprt=135
Fri Oct 18 11:44:03 2013:Link: ip_sndreq -> filter discard( 56693 , 135 )
Quelle und Ziel habe ich verfälscht und ersetzt, da stehen sonst IP Adressen.
Am Gateway Trace war wie schon angedeutet nichts zu finden, was nun daran lag, das diese Pakete nie dort angekommen sind, die Firewallregeln aber für alles andere gegriffen hat. Naja, ich hatte dann einen anderen Laptopam Start, bei dem es funktionierte (wusste ich nicht, da Direktoren nur mit mir sprechen, wenn etwas nicht funktioniert, und dem war dann heute mal so). Also habe ich die Profile haarklein verglichen und musste feststellen, dass NetBios Traffic explicit angeschaltet werden muss, da dieser sonst über das entsprechende VPN Profil geblockt wird. Ole Ole!
Schade, dass diese Eigenheit nicht ausfürlich in der Anleitung beschrieben ist, denn NetBios Traffic explicit zulassen zu müssen halte ich an sich für ein gutes Konzept, wenn es irgendwo steht.
In diesem Sinne,
viele Grüße aus Berlin
ich hab die Lösung gefunden und wollte nun alle teilhaben lassen, damit dies für alle Ewigkeiten dokumentiert ist und niemanden mehr Haare kostet.
Vorab bedanke ich mich für die Hilfe und die Vorschläge bei euch.
Also:
Der Lancom Advanced VPN Client ( NCP Client oder auch Watchguard client ) hat in jedem Einwahlprofil eigene Link firewall Einstellungen, welche nun bei Aktivität den Traffic filtern. Da ich für die Clientlaptops die Windows Firewall und für die Absicherung des Intranets ausschliesslich die Firewall des Gateways nutze, lasse ich die VPN Client Firewall aus.
Nun bin ich in meiner Naivität davon ausgegangen, dass ich bei ausgeschalteter Stateful Inspection (so heisste die Option ) nichts weiter beachten muss, denn aus ist aus, so gibt es die Maske intuitiv her.
Ist aber falsch angenommen. Darauf gekommen bin ich durch Traces auf den Clients, der NCP Client (Lancom, Watchdog...) bietet einen klasse Tracer, das LANTrace.exe, welches im Programmroot des clients zu finden ist.
hier tauchten immer wieder folgende Zeilen bei Verbindungsaufbau mit dem Mailserver auf:
Fri Oct 18 11:44:03 2013:Link: ipv4_sndreq - len=52,srcipa=VPN-IP,dstipa=Ziel_Mailserver,srcprt=56693,dstprt=135
Fri Oct 18 11:44:03 2013:Link: ip_sndreq -> filter discard( 56693 , 135 )
Quelle und Ziel habe ich verfälscht und ersetzt, da stehen sonst IP Adressen.
Am Gateway Trace war wie schon angedeutet nichts zu finden, was nun daran lag, das diese Pakete nie dort angekommen sind, die Firewallregeln aber für alles andere gegriffen hat. Naja, ich hatte dann einen anderen Laptopam Start, bei dem es funktionierte (wusste ich nicht, da Direktoren nur mit mir sprechen, wenn etwas nicht funktioniert, und dem war dann heute mal so). Also habe ich die Profile haarklein verglichen und musste feststellen, dass NetBios Traffic explicit angeschaltet werden muss, da dieser sonst über das entsprechende VPN Profil geblockt wird. Ole Ole!
Schade, dass diese Eigenheit nicht ausfürlich in der Anleitung beschrieben ist, denn NetBios Traffic explicit zulassen zu müssen halte ich an sich für ein gutes Konzept, wenn es irgendwo steht.
In diesem Sinne,
viele Grüße aus Berlin
Fazit: Mit dem freien Shrew VPN Client wär das nicht passiert ! https://www.shrew.net
Aber gut wenns nun alles klappt wie es soll.
P.S.: Wir haben schon verstanden das TCP 135 kein Email Port ist
Aber gut wenns nun alles klappt wie es soll.
P.S.: Wir haben schon verstanden das TCP 135 kein Email Port ist
