Port-Forwarding 443 / HTTPS funktioniert nicht mit 1721 VPN

OnkelSAM · Beitrag von **OnkelSAM** » 25 Jan 2011, 09:43

Hallo Zusammen,

seit ca. 3 Tagen versuche ich das Port-Forwarding (443/HTTPS) einzurichten und bekomme es nicht hin.

Ziel: Verschidene Mobilgeräte (iPhone, Windows Mobile 6) sollen über das Internet auf den Exchange 2003 mit ActiveSync / Push-Mail zugreifen können.

System-Umfeld:
DC - W2K3 SP2; IP:192.168.130.102
Exchange 2003 Standard incl SP2; OS W2K3 SP2; IP:192.168.130.101
Lancom 1721 VPN; LAN-IP: 192.168.130.243

Lancom 1721 VPN: erst mit LCOS 7.6 und jetzt mit LCOS 8.0
per DynDNS aus dem Internet erreichbar
Port-Forwarding im Lancom konfiguriert 443 -> 192.168.130.101
Konfiguration über HTTPS für extern und intern steht auf "nicht erlaubt"
Exchange 2003:
OMA / ActiveSync aus dem LAN im Browser aufrufbar - aus dem Internet funktioniert das nicht

Ich vermute zur Zeit ein Problem beim Port-Forwarding, denn die Webseiten des IIS auf dem Exchange sind vom LAN aus errecihbar. Und im LOG des IIS sind auch die Zugriffe protokolliert. Wenn ich über das Internet versuche zuzugreifen (per Browser nicht mit einen Mobile-Device) wird auch im IIS-Log nichts protokolliert. So als kommen da überhaupt keine Pakete an. Auch das Abschalten der Firewall im Lancom bringt keine Lösung.

Ich hoffe einer von Euch kann mir weiter helfen.

Gruß OnkelSAM

Dr.Einstein · Beitrag von **Dr.Einstein** » 25 Jan 2011, 17:00

Hallo OnkelSAM,

- Der Exchange Server hat den Lancom Router als Standard Gateway hinterlegt?
- Firewall des Exchange Server würde Anfragen von öffentlichen IPs zulassen?
- Existieren weitere Regeln im Lancom z.B. Firewall, die die Portweiterleitung verhindern könnten (Stichwort Deny-All)

Wenn du nicht genau weißt, wo die Baustelle ist, mach über Telnet oder Lanmonitor einen IP-Router Trace. Dort kannst du genau sehen, ob die Anfragen ins Lan geschickt werden, oder ob die Datenpakete gefiltert werden.

Gruß Dr.Einstein

OnkelSAM · Beitrag von **OnkelSAM** » 25 Jan 2011, 21:09

Hallo Dr.Einstein,

hier die Antworten auf deine Fragen:

- Der Exchange Server hat den Lancom Router als Standard Gateway hinterlegt?
JA
- Firewall des Exchange Server würde Anfragen von öffentlichen IPs zulassen?
Firwall ist deaktiviert
- Existieren weitere Regeln im Lancom z.B. Firewall, die die Portweiterleitung verhindern könnten (Stichwort Deny-All)
Deny Regel gibt es nicht, habe aber trotzdem eine Regel erstellt in der HTTPS erlaubt ist.

Aber wie schon geschrieben funktioniert es auch mit abgeschalteter Firewall im Lancom nicht.

Den Trace mit dem Lanmonitor schaue ich mir jetzt mal an.

Hier habe ich schon mal ein Ausschnitt aus der Verbindungsliste:
Quell-Adresse Ziel-Adresse Prot. Quell-Port Ziel-Port Rtg-Tag Timeout Flags Filterregel Quell-Route Ziel-Route
83.216.241.60 192.168.130.101 6 58691 443 0 5 80104038 DEFAULT (ACCEPT-ALL) T-DSLBIZ
83.216.241.60 192.168.130.101 6 58692 443 0 0 80104068 DEFAULT (ACCEPT-ALL) T-DSLBIZ
83.216.248.157 192.168.130.101 6 58689 443 0 4 80104038 DEFAULT (ACCEPT-ALL) T-DSLBIZ
83.216.248.157 192.168.130.101 6 58690 443 0 4 80104038 DEFAULT (ACCEPT-ALL) T-DSLBIZ
83.216.241.60 192.168.130.101 6 58691 443 0 5 80104038 DEFAULT (ACCEPT-ALL) T-DSLBIZ
83.216.241.60 192.168.130.101 6 58692 443 0 0 80104068 DEFAULT (ACCEPT-ALL) T-DSLBIZ
83.216.248.157 192.168.130.101 6 58689 443 0 4 80104038 DEFAULT (ACCEPT-ALL) T-DSLBIZ
83.216.248.157 192.168.130.101 6 58690 443 0 4 80104038 DEFAULT (ACCEPT-ALL) T-DSLBIZ

SO habe die Traces als ZIP angefügt.

Gruß OnkelSAM

ft2002 · Beitrag von **ft2002** » 26 Jan 2011, 09:35

Hallo OnkelSAM,

Ich glaube Du musst den HTTPS Port für den Lancom Umschreiben auf einen anderen Port weil nur Sperren, bedeutet ja das er die anfragen nicht annimmt aber der Port ist ja gesetzt.

Im Webinterface unter :

LCOS-Menübaum/Setup/HTTP

Gruß ...

backslash · Beitrag von **backslash** » 26 Jan 2011, 12:07

Hi OnkelSAM

hier liegt das Probem eindeutig am Client oder Server, denn der Router-Trace zeigt, daß Die Pakete sauber zum Server weitergeleitet und von ihm auch beantwortet werden, der Client die Session aber abwürgt:

Der Client schickt das erste Paket (SYN):

[IP-Router] 2011/01/25 22:47:49,660
IP-Router Rx (T-DSLBIZ, RtgTag: 0):
DstIP: 192.168.130.101, SrcIP: 83.216.241.60, Len: 52, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 443, SrcPort: 60663, Flags: S
Seq: 730843225, Ack: 0, Win: 8192, Len: 0
Option: Maximum segment size = 1452
Option: NOP
Option: Window scale = 2 (multiply by 4)
Option: NOP
Option: NOP
Option: SACK permitted
Route: LAN Tx (INTRANET):

Der Server bestätigt dies (SYN/ACK):

[IP-Router] 2011/01/25 22:47:49,660
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 83.216.241.60, SrcIP: 192.168.130.101, Len: 52, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 60663, SrcPort: 443, Flags: SA
Seq: 30823135, Ack: 730843226, Win: 64240, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
Route: WAN Tx (T-DSLBIZ)

Der Client beendet den 3-Wege-Handschake (ACK) und damit ist die Session offen:

[IP-Router] 2011/01/25 22:47:49,750
IP-Router Rx (T-DSLBIZ, RtgTag: 0):
DstIP: 192.168.130.101, SrcIP: 83.216.241.60, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 443, SrcPort: 60663, Flags: A
Seq: 730843226, Ack: 30823136, Win: 16698, Len: 0
Route: LAN-1 Tx (INTRANET):

Nur statt nun mit der SSL-Verhandlung anzufangen, beendet der Client die Session sofort (FIN/ACK):

[IP-Router] 2011/01/25 22:47:49,750
IP-Router Rx (T-DSLBIZ, RtgTag: 0):
DstIP: 192.168.130.101, SrcIP: 83.216.241.60, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 443, SrcPort: 60663, Flags: FA
Seq: 730843226, Ack: 30823136, Win: 16698, Len: 0
Route: LAN-1 Tx (INTRANET):

Das wird noch vom Server bestätigt (ACK):

[IP-Router] 2011/01/25 22:47:49,760
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 83.216.241.60, SrcIP: 192.168.130.101, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 60663, SrcPort: 443, Flags: A
Seq: 30823136, Ack: 730843227, Win: 64240, Len: 0
Route: WAN Tx (T-DSLBIZ)

Der Client hat seine Session schon weggeworfen und antwortet nur noch mit einem Reset (RST/ACK):

[IP-Router] 2011/01/25 22:47:49,760
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 83.216.241.60, SrcIP: 192.168.130.101, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 60663, SrcPort: 443, Flags: RA
Seq: 30823136, Ack: 730843227, Win: 0, Len: 0
Route: WAN Tx (T-DSLBIZ)

Da mußt du das Problem schon woanders suchen...

Gruß
Backslash

OnkelSAM · Beitrag von **OnkelSAM** » 26 Jan 2011, 13:12

OK, Danke backalsh!

Dann kann es nur am Zertifikat liegen auf dem Exchange. Ich werde aber noch mal testen nur mit HTTP (Port 80).
Wenn ich dann zum Exchange durchkomme ist es auf jeden Fall das Zertifikat.

Gruß OnkelSAM

OnkelSAM · Beitrag von **OnkelSAM** » 26 Jan 2011, 13:21

Hallo Zusammen,

ja, es ist das Zertifikat!!!
Denn nach Einrichten des Port-Forwarding (Port 80, HTTP) auf den Exchange, bekomme ich ein Logon und OWA/OMA funktioniert aus dem Internet.

Allen Beteiligten danke für die Mithilfe.

Gruß OnkelSAM