https over rpc für exchange 2003

[wipien]

besteht die möglichkeit https over rpc über die securepoint zu machen. ist für den owa.

[oliver]

hallo,

ich habe es selber noch nicht getestet. prinzipiell muesste es aber
funktionieren. evtl. muss der port, wenn nicht 443, als ssl port im
proxy template ergaenzt werden.

[lst-escheburg]

Funktioniert definitiv... Ich selber habe bei jedem Kunden von mir dieses im Einsatz!!!

[Thomas Hofmann]

Hallo Ist-Escheburg?
kannst Du näher beschreiben, wie das auf der SecurePoint abgebildet werden kann?

Danke

[achim]

eigentlich muss da nicht groß was konfiguriert werden...
in welcher Richtung soll das denn ablaufen /an welcher stelle gibts probleme?

z.B. homeoffice -> Router -> Internet -> Securepoint -> Exchange-Server (eingehend) oder
LAN1 -> Securepoint -> Internet -> Router -> LAN2 mit Exchange? (ausgehend)

[Thomas Hofmann]

Hallo Achim,

Ich verstehe deine Nachricht nicht wirklich!

Natürlich soll über das Internet, also ohne VPN, auf den Exchange zugegriffen werden. Der HTTPS-Port ist bereits auf den Server umgeleitet. Ein Zugriff von außen auf den Dienst (z.B. OWA) funktioniert schon. Allerdings erst nachdem eine entsprechende Regel auch für den Rückweg angelegt wurde.

Trotzdem: ein Zugriff über RPC via https klapp nicht.

Ist denn diese Mechanismus nicht mehr in der Firewall, als die Portumleitung 443 auf ein Gerät? Die Firewall muss doch intern andere Ports und Anwendungen stuerern, als nach außen bekannt sind!

Ich begreife das nicht. Gibt es dazu vielleicht eine Beispilekonfiguration von Securepoint?

[lst-escheburg]

Hallo Herr Hoffmann,
auf der Firewall muss wirklich nur der Port 443 Freigegeben werden. Sobald dies gemacht wurde sind die Dienste sofort verfügbar. Was möchten Sie genau machen? RPC over HTTPS? Mit Outlook 2003 oder 2007 von aussen auf Mails zugreifen? Oder Handys mit Active-Sync an den Exchange Server binden?

[Thomas Hofmann]

Hallo,

ich habe es zwischenzeitlich geschafft. Offenbar war in meiner Routing-Tabelle ein Eintrag "gehängt". Nach einem Neustart der Maschine ist alles in Ordnung. Das heißt, ich kann von außen wunderbar auf OWA zugreifen.

Hinweis: Ich habe 2 Gateways. Die eine soll standardmäßig zum surfen verwendet werden (also Port 80 und 443), die andere aber für den Zugriff von außen. In diesem Zusammenhang gibt es dann aber das Problem, dass alle Zugriffe von außen über die Portumleitung zwar beim OWA Server ankommen, aber über die falsche Schnittstelle beantwortet werden. Deshalb ist es in diesem Fall notwendig, zusätzlich eine Rückroute für HTTPS und HTTP zu legen.

[Thomas Hofmann]

Ich habe aber immer noch ein Zugriffsproblem, wenn ich mit Outlook auf den Exchange zugreifen will. Hat hierzu bereits jemand ein konfigurationsbeispiel?

alle Anfragen erreichen den Exchange Server. Danach wird aber folgendes geblockt:
----------------------------
Zuerst kommt die Anfrage auf 443 und wird zugelassen auf die DST=192.168.35.51
----------------------------
Firewall ACCEPT
IN=eth2 OUT=eth1 SRC=62.158.89.46 DST=192.168.35.51
LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=61398 DF PROTO=TCP SPT=36083 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
----------------------------
Dann wird aber ein IDS Portscan angezeigt und geblockt:
----------------------------
IDS Engine
[2124]: [122:3:0] (portscan) TCP Portsweep {PROTO255} 62.158.89.46 -> 192.168.35.51

Firewall DROP
IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:13:72:2e:3d:13:08:00 SRC=192.168.35.51 DST=192.168.35.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=10583 PROTO=UDP SPT=138 DPT=138 LEN=209

Outlook als Client löst wohl diesen TCP Portsweep aus. Ich weiss darüber aber zu wenig, wie das genau stattfindet. Danach wird der DST Port aber auf eine MAC Adresse (?) zurück gegeben. Das blockt die Firewall ja dann entsprechend.

Ich weiß nicht, wo ich hier ansetzen kann. Wenn jemand dazu helfen kann, freue ich mich. Ich kann mir nicht vorstellen, dass dies noch nicht in der SecurePoint gelöst wurde!

Das ist auch ein Aufruf an den Suport von SecurePoint (Moderatoren).

Danke

[oliver]

Hallo,

die Anfrage wird nicht gedropped. Was Sie dort als Drop sehen ist ein
Windows-Broadcast-Paket was mit der Verbindung nichts zu tun hat.

Falls Sie Multipath-Routing verwenden, müssen Sie in der aktuellen Version
ein Source-Routing-Eintrag hinzufügen, das garantiert wird, dass das Paket
über die richtige Leitung rausgeht. In etwa so:

ExchangeServer -> ppp0 -> 0.0.0.0/0

In der aktuellen Beta (CLI: update firewall current) ist das schon geändert
und dann nicht mehr nötig. Sprich das ganze wird komplett über das
Regelwerk gesteuert.

[Thomas Hofmann]

Hallo Oliver,

Danke für die Nachricht (trotz Feiertag / Wochenende).

Ich habe eine entsprechende Route gelegt und siehe da, alles klappt wunderbar. Vielen Dank.

Zum besseren Verständnis:
Ich benutze tatsächlich Multi-Pass Routing über mehrere Default Gateways. Insofern ist die Route (Webserver => eth2 (IP-Adresse) => 0.0.0.0/0) wohl der Schlüssel zum Glück gewesen.

Was heißt denn: "in der aktuellen Beta ..." Wird es in naher Zukunft eine neue Firmware geben, die die Rückroute automatisch erkennt? Das wäre schön. Denn mit der jetzigen Route werden natürlich alle externen Verbindungen des Servers über die 2. Schnittstelle ins Internet geroutet. Ich bin nicht sicher, ob das immer gewollt ist.

Können Sie dazu schon etwas sagen, wann hier eine neue Firmware in Aussicht steht?

[oliver]

Hallo,

das Update wird in zirka zwei Wochen zur Verfügung stehen und es funktioniert
dann so, wie Sie es schon beschrieben haben. Es wird allein übers Regelwerk
gesteuert, kein zusätzlicher Routing-Eintrag nötig und der Host kann weiterhin
Multipath-Routing nutzen, trotz Static-NAT.

Die Beta kann man folgendermaßen testen:

Firewall auf Beta wechseln:

update firewall current

Firewall zurück auf Stable wechseln:

update firewall

Nach jedem Update ist ein Reboot notwendig. So kann man
zwischen den Versionen hin und her wechseln.

[Thomas Hofmann]

Hallo Oliver,

für die Firmware sollten wir sicher einen neuen Topic eröffnen.