[exch2016] port 443 niet open/listening

[Operations]

Ik heb hier een Server 2012 R2 machine ingericht met daarop Hyper-V. Exchange 2016 staat als VM (met server 2012 R2) geïnstalleerd.

Het probleem is dat de telefoons geen verbinding kunnen maken met de exchange 2016 (error: kan niet aanmelden).

De testconnectivy site van Microsoft geeft aan dat port 443 not open/listening is, dus op zich logisch dat de telefoons niet kunnen connecten (volgens mij).

In de router heb ik de port netjes doorgezet (ook als DMZ werkt niet), er is een SSL certificaat geïnstalleerd.
remote.domein.nl (verwijst door naar /owa, heb HTTP redirect opgevoerd) werkt ook gewoon.
De bindings (binnen IIS) op default website en exchange backend kloppen ook (wijzen naar juiste SSL).

De eventvwr geeft een aantal errors op performance counters, maar dat is voor zover ik heb kunnen vinden niet zo spannend en relevant.

Iemand enig idee waar ik dit moet zoeken?

[Meekoh]

Windows Firewall?

[Operations]

Meekoh schreef op woensdag 18 mei 2016 @ 10:58:
Windows Firewall?

Vergeten te melden.. Die staat uit op zowel Hyper V host als de machine waar exchange 2016 op staat.

[MAX3400]

Ga eerst een troubleshooten of de poort intern uberhaupt open staat en daarna of de poort van buitenaf te bereiken is. De troubleshooter van Microsoft is leuk maar doet niets af aan het feit dat je ook zelf even een paar testjes over poorten/protocollen kan uitvoeren.

Neem aan dat de virtual switches en alle bijbehorende OS'en ook geen issues hebben met 443?

[Jester-NL]

Het probleem is dat de telefoons geen verbinding kunnen maken met de exchange 2016
(...)
er is een SSL certificaat geïnstalleerd(...)

Mijn ervaring in (heel veel) van dit soort gevallen... je hebt wel het certificaat zelf, maar niet de intermediate geinstalleerd staan. Gooi de juiste URL hier even doorheen: https://www.ssllabs.com/ssltest/analyze.html

[Jazzy]

De Windows Firewall kun je gewoon aan laten staan, is ook best practice. Exchange heeft tijdens de installatie de juiste uitzonderingen aangemaakt.

Ik mis ook de basics. Eerst controleer je op de server of er wel een proces luistert op poort 443: netstat -ano | findstr :443, dat zal wel het geval zijn. Vervolgens gebruik je telnet om naar localhost op 443 te verbinden: telnet localhost 443. Volgende stap is dat je dit van de Hyper-V server test: telnet exchange01 443, etcetera.

[Operations]

Jester-NL schreef op woensdag 18 mei 2016 @ 11:06:
[...]

Mijn ervaring in (heel veel) van dit soort gevallen... je hebt wel het certificaat zelf, maar niet de intermediate geinstalleerd staan. Gooi de juiste URL hier even doorheen: https://www.ssllabs.com/ssltest/analyze.html

Had de sslcheck van xolphin al gedaan, maar deze website levert dit op:

1 Sent by server remote.domein.nl
Fingerprint SHA1: 36c63e79c516268e8e2d8c036fddddd56c02e3b2
Pin SHA256: rMaNw0k5yV+u+MMDmExcHdn5hPPcJWKs76CFPrKpz7A=
RSA 2048 bits (e 65537) / SHA256withRSA
2 Sent by server COMODO RSA Domain Validation Secure Server CA
Fingerprint SHA1: 339cdd57cfd5b141169b615ff31428782d1da639
Pin SHA256: klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=
RSA 2048 bits (e 65537) / SHA384withRSA
3 In trust store COMODO RSA Certification Authority Self-signed
Fingerprint SHA1: afe5d244a8d1194230ff479fe2f897bbcd7a8cb4
Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
RSA 4096 bits (e 65537) / SHA384withRSA

nummer 3 is "self-signed" dit is toch geen probleem?

@Jazzy

Als https://remote.domein.nl werkt van buitenaf (en intern) dan is poort 443 toch te bereiken?

netstat -a had ik al gedaan, maar het commando wat jij voorstelt levert dit op:

TCP 192.168.200.225:443 (juiste interne IP) 192.168.200.78 (client IP):60041 ESTABLISHED
(En nog een aantal van deze regels met een ander client poort nummer)
TCP 192.168.200.225:59017 (juiste interne IP) 82.*.*.* (externe IP van server):443 ESTABLISHED

Telnet localhost 25 werkt wel, maar localhost 443 niet.. Dus zal toch wel iets mis zijn met poort 443, maar waar check ik dit nu? Snap ook niet zo goed waarom ik hier tegenaan loop heb 9 a 10 van deze zelfde installaties gedaan zonder enige problemen. Maar goed elke situatie is en blijft natuurlijk anders.

Enige verschil met eerdere installaties is dat de Exchange server nu een dedicated NIC heeft binnen Hyper-V. Voorheen gebruikte ik maar een NIC. Maar ik neem aan dat dit niet het probleem zou kunnen veroorzaken. Zal toch voor de zekerheid vanavond dit even testen.

[ Voor 14% gewijzigd door Operations op 18-05-2016 13:21 ]

[Jester-NL]

Nummer 3 is de root van Comodo, en nee, het is geen probleem dat die self-signed is, want dat is met alle root-certificaten het geval.

[Jazzy]

Als https://remote.domein.nl werkt van buitenaf (en intern) dan is poort 443 toch te bereiken?

Wat bedoel je met 'werkt'? Als je inlogt op deze url dan wordt je geredirect naar /owa? Dus je kunt inloggen op webmail?

[ Voor 25% gewijzigd door Jazzy op 18-05-2016 13:54 ]

[Question Mark]

Operations schreef op woensdag 18 mei 2016 @ 12:19:
[...]
netstat -a had ik al gedaan, maar het commando wat jij voorstelt levert dit op:

Nee... Jazzy gaf aan om "netstat -aon" te gebruiken, niet "netstat -a".

De opdrachtregel van Jazzy geeft een compleet overzicht van de combinatie ip-adressen en poorten op de server. Hiermee kun je controleren of de server zelf uberhaubt al luistert op poort 443.

Jazzy schreef op woensdag 18 mei 2016 @ 11:13:
De Windows Firewall kun je gewoon aan laten staan, is ook best practice. Exchange heeft tijdens de installatie de juiste uitzonderingen aangemaakt.

Niet als de firewall tijdens de installatie al disabled was (ik weet het voor exchange 2016 niet 100% zeker, maar bij veel andere applicaties is dit wel het geval). Als TS de Firewall weer enabled (en dat zou ik zeker doen), dan moet hij wel even heel goed de ingestelde FW-rules controleren.

[ Voor 37% gewijzigd door Question Mark op 20-05-2016 12:53 ]