9
Exchange hinter Bintec R232bw mit 2 WAN Anschlüssen und Policy Based Routing
Hallo mal wieder =)
so die Probleme hören nicht auf!
Unsere Mitarbeiter nutzen unseren Exchange-Server auch von ausserhalb. Dafür ist im Outlook in den erweiterten Kontoeinstellungen eingetragen, dass eine Verbindung auch über HTTP herzustellen ist. Hinterlegt ist dann ein DNS-Name https://xyz.firma.de über den es bisher immer funktioniert hat. Seitdem ich die beiden Standardrouten eingerichtet habe um den HTTP(s) Verkehr der rausgeht über den einen WAN Anschluss zu schicken, kommen die Mitarbeiter nicht mehr auf den Exchange. Abruf privater Mails von z.B. gmx mit verschlüsseltem Passwort via Thunderbird funktioniert auch nicht mehr...
Hat da jemand eine Idee?
Viele Grüße
Steve
so die Probleme hören nicht auf!
Unsere Mitarbeiter nutzen unseren Exchange-Server auch von ausserhalb. Dafür ist im Outlook in den erweiterten Kontoeinstellungen eingetragen, dass eine Verbindung auch über HTTP herzustellen ist. Hinterlegt ist dann ein DNS-Name https://xyz.firma.de über den es bisher immer funktioniert hat. Seitdem ich die beiden Standardrouten eingerichtet habe um den HTTP(s) Verkehr der rausgeht über den einen WAN Anschluss zu schicken, kommen die Mitarbeiter nicht mehr auf den Exchange. Abruf privater Mails von z.B. gmx mit verschlüsseltem Passwort via Thunderbird funktioniert auch nicht mehr...
Hat da jemand eine Idee?
Viele Grüße
Steve
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: 193203
Url: https://administrator.de/contentid/193203
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
9 Kommentare
Neuester Kommentar
Hi Steve,
manchmal hilft das Aufzeichnen einer Route mit dem Bleistift.
Der Exchange wird über eine feste IP ereicht. Der Verkehr zurück wird über eine Policy nach getrennten Regeln geleitet.
Kann das überhaupt ankommen?
Zum Problem Thunderbird stehe keine Inof ob der von intern oder extern, via VPN oder eben nur http(s) (POP3, SMTP, IMAP) genutzt wird. Während bei mir diese Klammer zulässig ist, ist sie bei deiner Antwort verboten. Du musst es wissen und nicht raten.
Gruß
Netman
manchmal hilft das Aufzeichnen einer Route mit dem Bleistift.
Der Exchange wird über eine feste IP ereicht. Der Verkehr zurück wird über eine Policy nach getrennten Regeln geleitet.
Kann das überhaupt ankommen?
Zum Problem Thunderbird stehe keine Inof ob der von intern oder extern, via VPN oder eben nur http(s) (POP3, SMTP, IMAP) genutzt wird. Während bei mir diese Klammer zulässig ist, ist sie bei deiner Antwort verboten. Du musst es wissen und nicht raten.
Gruß
Netman
Hallo,
der DSL1 Anschluss hat eine feste IP, unter der der OWA bisher immer erreichbar war.
Dafür gibt es eine Portweiterleitung auf unseren SBS auf dem OWA und Exchange läuft.
Jetzt gibt es zusätzlich eine Standardroute der Form
Quelle: Intranet
Protokoll: https (Quellport beliebig, Zielport 443)
über Schnittstelle DSL1
Die gleiche Standardroute noch für HTTP.
Seitdem funktioniert der OWA nichtmehr, bzw ist von extern nicht zu erreichen.
@Thunderbird: ich benutze IMAP mit SSL/TLS und verschlüsseltem Passwort bei GMX (also externer Anbieter).
Wenn ich das Passwort auf unverschlüsselt setze, kann ich damit Emails empfangen. Bei verschlüsseltem Passwort nicht mehr.
Grüße
Steve
der DSL1 Anschluss hat eine feste IP, unter der der OWA bisher immer erreichbar war.
Dafür gibt es eine Portweiterleitung auf unseren SBS auf dem OWA und Exchange läuft.
Jetzt gibt es zusätzlich eine Standardroute der Form
Quelle: Intranet
Protokoll: https (Quellport beliebig, Zielport 443)
über Schnittstelle DSL1
Die gleiche Standardroute noch für HTTP.
Seitdem funktioniert der OWA nichtmehr, bzw ist von extern nicht zu erreichen.
@Thunderbird: ich benutze IMAP mit SSL/TLS und verschlüsseltem Passwort bei GMX (also externer Anbieter).
Wenn ich das Passwort auf unverschlüsselt setze, kann ich damit Emails empfangen. Bei verschlüsseltem Passwort nicht mehr.
Grüße
Steve
Du wolltest die Routen im Einzelnen noch einmal nachprüfen.
Zur Not mittels Wireshark und
Telnet ip 443
Gruß
Netman
Zur Not mittels Wireshark und
Telnet ip 443
@Thunderbird: ich benutze IMAP mit SSL/TLS und verschlüsseltem Passwort bei GMX (also externer Anbieter).
Wenn ich das Passwort auf unverschlüsselt setze, kann ich damit Emails empfangen. Bei verschlüsseltem Passwort nicht mehr.
Dann liegt es ja wohl kaum an deinem Router ... Start TLS oder so.Wenn ich das Passwort auf unverschlüsselt setze, kann ich damit Emails empfangen. Bei verschlüsseltem Passwort nicht mehr.
Gruß
Netman
Da steh ich gerad leider auf dem Schlauch.
Wie kann ich die Routen direkt prüfen?
Ich weiss dass wir https und https mittlerweile immer über den DSL1 herauskommen.
xyz.firma.de wird auch per ping richtig aufgelöst. Mit telnet komme ich nicht von aussen auf den Server.
Ich habe schon "telnet xyz.firma.de 443" ausprobiert und diese Verbindung ist immer gescheitert. Der "normale" Aufruf via Browser funktioniert dementsprechend auch nicht...
Wie kann ich die Routen direkt prüfen?
Ich weiss dass wir https und https mittlerweile immer über den DSL1 herauskommen.
xyz.firma.de wird auch per ping richtig aufgelöst. Mit telnet komme ich nicht von aussen auf den Server.
Ich habe schon "telnet xyz.firma.de 443" ausprobiert und diese Verbindung ist immer gescheitert. Der "normale" Aufruf via Browser funktioniert dementsprechend auch nicht...
Das Kombination Telnet und Wireshark liefert dir Ergebnisse, wer nämlich nicht weiter kommt oder was zurück kommt. Und mit dem internen Telnet kannst du jeden beliebigen Port verwenden, auch die, die du mit Policy based Routing verarbeitest.
Ich habe jetzt von extern mit Wireshark gearbeitet...
Ich bekomme da keine Antwort von der IP. Also ich sende Packete und sehe das in der Destination Spalte, aber in der Source-Spalte kommt nix von der IP. Kann ich das als Hinweis werten? Die IP is richtig und wird dementsprechend auch aufgelöst...
Wenn ich es von intern mache, funktioniert es. Da kommt dann SYN ACK etc... also jetzt rein über Telnet.
btw: Sollte ich immernoch in die falsche Richtung bohren, versuch es bitte in einfachen Worten. Ich hab das Gefühl das ich hier stark im Dunklen tappe...
Ich bekomme da keine Antwort von der IP. Also ich sende Packete und sehe das in der Destination Spalte, aber in der Source-Spalte kommt nix von der IP. Kann ich das als Hinweis werten? Die IP is richtig und wird dementsprechend auch aufgelöst...
Wenn ich es von intern mache, funktioniert es. Da kommt dann SYN ACK etc... also jetzt rein über Telnet.
btw: Sollte ich immernoch in die falsche Richtung bohren, versuch es bitte in einfachen Worten. Ich hab das Gefühl das ich hier stark im Dunklen tappe...
Das Dreiwege Hanshake gilt immer, von uinnen nach aussen oder von aussen nach innen. Jetzt hast du nur die Bestätigung, dass es keine Antwort gibt.
Also gehören drei Pakte zu einer Anfrage (bei mehr Verkehr werden welche eingespart)
Anfrage von source nach destination (syn)
acknowlegde von destinatin nach source (syn ack)
acknowlegde von source nach destinatin (ack)
Die Intention dabei war, heraus zu finden, wie die Antwortpakete bei funktionieren den Applikationen aussehen und wie bei den anderen.
Also gehören drei Pakte zu einer Anfrage (bei mehr Verkehr werden welche eingespart)
Anfrage von source nach destination (syn)
acknowlegde von destinatin nach source (syn ack)
acknowlegde von source nach destinatin (ack)
Die Intention dabei war, heraus zu finden, wie die Antwortpakete bei funktionieren den Applikationen aussehen und wie bei den anderen.
Ok. Das ist nun klar.
Fakt ist ich bekomme über DSL1 keine Antwort^^
Ich habe aber nun die Möglichkeit über meinen zweiten Anschluss auf den Exchange zu kommen. Die NAT-Regeln sind exakt gleich. Nur für den DSL1 gibt es halt noch die Routen die HTTP und HTTPS betreffen.
Da stellt sich mir die Frage ob ich den Server irgendwie von den Routen ausnehmen kann. Also dass Pakete die ihn betreffen nicht betroffen sind...
Um ehrlich zu sein, ich hab keine Ahnung wie es weitergehen soll...
Grüße
Fakt ist ich bekomme über DSL1 keine Antwort^^
Ich habe aber nun die Möglichkeit über meinen zweiten Anschluss auf den Exchange zu kommen. Die NAT-Regeln sind exakt gleich. Nur für den DSL1 gibt es halt noch die Routen die HTTP und HTTPS betreffen.
Da stellt sich mir die Frage ob ich den Server irgendwie von den Routen ausnehmen kann. Also dass Pakete die ihn betreffen nicht betroffen sind...
Um ehrlich zu sein, ich hab keine Ahnung wie es weitergehen soll...
Grüße
Loadbalancing ohne Mithilfe des Providers mit einer entsprechenden Konfiguration geht eben nur in eine Richtung und somit nur über einen Anschluß. Vielleicht sollte für die Server eine Fallback Szenario konfiguriert werden. Oder sie werden manuell und nicht dynamisch auf die Anschlüsse verteilt.
