[Exchange 2010] Imap werkt intern niet

[DaVaRiOuS]

Ik heb op de Exchange 2010 server (Op een SBS 2011 server) IMAP geconfigureerd en dit werkt allemaal naar behoren voor extern gebruik.
Echter als de laptop intern word gebruikt, dan kan die geen verbinding maken via IMAP.

Het is als volgt opgebouwd:

WAN IP: 1.2.3.4
LAN: 192.168.1.*

Firewall: 192.168.1.1
SBS2011: 192.168.1.2
Computers netwerk: 192.168.1.10 - 192.168.1.50

IMAP SSL poort: 993

HOST: mail.domein.nl > 1.2.3.4
Port forwarding: WAN 1.2.3.4:993 > LAN 192.168.1.2:993

Op de server heb ik een DNS zone aanmaakt zodat mail.domein.nl naar 192.168.1.2 verwijst.
Bij het pingen intern gaat dat dus ook goed.

Ik weet niet wat ik nu nog over het hoofd zie, maar de Outlook client geeft dus simpelweg aan dat de verbinding naar de imap server mislukt.
Extern kan ik zonder problemen mail ontvangen en verzenden via deze de host mail.domein.nl.

[Killah_Priest]

Waarom zou je in hemelsnaam IMAP gebruiken met Outlook op een Exchange server?

[Brahiewahiewa]

DaVaRiOuS schreef op maandag 7 augustus 2017 @ 18:24:
...Ik weet niet wat ik nu nog over het hoofd zie...

loopback

[DaVaRiOuS]

Killah_Priest schreef op dinsdag 8 augustus 2017 @ 08:29:
Waarom zou je in hemelsnaam IMAP gebruiken met Outlook op een Exchange server?

Allereerst is dit geen antwoord op mijn vraag, maar een onnodige wedervraag.
Maar om je gerust te stellen...

Omdat er middels een POP verbinding mails worden binnengehaald van meerdere domeinen die niet in eigen beheer zijn (zoals hotmail, mail adres van andere organisaties, mail van een ISP domein zoals bijv. [e-mail], etc...) Op deze manier worden al deze mails op de Exchange bewaard en kunnen de gebruikers deze onderling wel op meerdere apparaten synchroniseren en word het meegenomen in de backup (en daarbij komt dat bepaalde aanbieders van de mailadressen zelf geen imap of exchange ondersteunen).

Deze IMAP functie word alleen gebruikt voor de domeinen die niet in eigen beheer zijn, omdat je hiervoor zelf geen mailadressen in je Exchange omgeving kan aanmaken.
Voor de domeinen die wel in eigen beheer zijn die worden standaard via Exchange gesynchroniseerd.

[ Voor 14% gewijzigd door DaVaRiOuS op 08-08-2017 18:21 ]

[DaVaRiOuS]

Brahiewahiewa schreef op dinsdag 8 augustus 2017 @ 09:20:
[...]

loopback

Daar dacht ik dus ook aan, maar is er een mogelijkheid dat deze loopback niet plaatsvind?

[FreakNL]

Loopback is onzin want hij heeft intern DNS.

Wat geeft een nslookup op de client naar mail.domein.nl ?

En krijgt de client de interne DNS wel mee (als enige, dus niet stiekem nog een secondary externe dns).

Als test kun je op een client mail.domein.nl tijdelijk in de host file zetten (naar intern ip) , sluit je iig dns issues uit.

[ Voor 88% gewijzigd door FreakNL op 08-08-2017 18:37 ]

[Vorkie]

Zitten die werkplekken in het domein?

Mogelijk speelt authenticatie dan een rol in het niet werken. (er is dan een DC beschikbaar etc etc)

https://technet.microsoft...a998850(v=exchg.141).aspx

[DaVaRiOuS]

FreakNL schreef op dinsdag 8 augustus 2017 @ 18:33:
Loopback is onzin want hij heeft intern DNS.

Wat geeft een nslookup op de client naar mail.domein.nl ?

En krijgt de client de interne DNS wel mee (als enige, dus niet stiekem nog een secondary externe dns)

Bij de ISP waar het domein gehost word staat er DNS record:

mail.domein.nl > WAN IP 1.2.3.4

en intern in de eigen DNS server heb ik dus een DNS zone aangemaakt dat mail.domein.nl naar LAN IP 192.168.1.2 verwijst.

[FreakNL]

ThaNetRunner:
Waarom zou het extern wel werken dan??

[ Voor 16% gewijzigd door FreakNL op 08-08-2017 18:38 ]

[DaVaRiOuS]

Vorkie schreef op dinsdag 8 augustus 2017 @ 18:37:
Zitten die werkplekken in het domein?

Mogelijk speelt authenticatie dan een rol in het niet werken. (er is dan een DC beschikbaar etc etc)

https://technet.microsoft...a998850(v=exchg.141).aspx

Nee, de laptops hangen niet in het domein.
Hier is bewust niet voor gekozen i.v.m. flexwerkers.

[FreakNL]

Je antwoord niet op mijn vraag, je herhaalt alleen.

Leuk dat je intern dns hebt maar als je client die niet pakt.... Sluit eerst dat uit.

Kun je telnetten naar de server op poort 993?

[DaVaRiOuS]

FreakNL schreef op dinsdag 8 augustus 2017 @ 18:40:
Je antwoord niet op mijn vraag, je herhaalt alleen.

Leuk dat je intern dns hebt maar als je client die niet pakt.... Sluit eerst dat uit.

Kun je telnetten naar de server op poort 993?

Nog vergeten bij te vermelden.
Telnetten werkt op de een of andere manier niet naar 993 (ook niet extern), maar kan dus wel extern via Outlook een imap verbinding maken via SSL.

Ook op de server zelf kan ik niet telnetten naar poort 993.


Heb voor een test ook poort 143 open gezet, en die kan ik wel telnetten en ook gebruiken voor me imap verbinding

[ Voor 5% gewijzigd door DaVaRiOuS op 08-08-2017 18:55 ]

[Vorkie]

FreakNL schreef op dinsdag 8 augustus 2017 @ 18:38:
ThaNetRunner:
Waarom zou het extern wel werken dan??

Daar heb je wel een punt, maar dat komt eigenlijk uit die OWA en Activesync URL's.

Ben wel benieuwd wat er hier staat:

In powershell:

code:

Get-ImapSettings | fl

En dan de volgende 2:

code:

InternalConnectionSettings
ExternalConnectionSettings

Als voorbeeld zie ik op mijn eigen Exchange 2016 dit als default:

code:

InternalConnectionSettings        : {hostname.int.domein.nl:993:SSL, hostname.int.domein.nl::143:TLS}
ExternalConnectionSettings        : {}

/edit

wel een beetje vreemd dat je niet kan TELNETTEN intern, dat lijkt mij iets anders te zijn dan bovenstaande.

/edit2

Wat staat er bij:

code:

X509CertificateName

[ Voor 14% gewijzigd door Vorkie op 08-08-2017 18:51 ]

[DaVaRiOuS]

Vorkie schreef op dinsdag 8 augustus 2017 @ 18:48:
[...]

Daar heb je wel een punt, maar dat komt eigenlijk uit die OWA en Activesync URL's.

Ben wel benieuwd wat er hier staat:

In powershell:

code:

Get-ImapSettings | fl

En dan de volgende 2:

code:

InternalConnectionSettings
ExternalConnectionSettings

Als voorbeeld zie ik op mijn eigen Exchange 2016 dit als default:

code:

InternalConnectionSettings        : {hostname.int.domein.nl:993:SSL, hostname.int.domein.nl::143:TLS}
ExternalConnectionSettings        : {}

/edit

wel een beetje vreemd dat je niet kan TELNETTEN intern, dat lijkt mij iets anders te zijn dan bovenstaande.

/edit2

Wat staat er bij:

code:

X509CertificateName

InternalConnectionSettings : {SBS2011.domein.local:993:SSL, SBS2011.domein.local:143:TLS}

[Vorkie]

DaVaRiOuS schreef op dinsdag 8 augustus 2017 @ 18:52:
[...]


InternalConnectionSettings : {SBS2011.domein.local:993:SSL, SBS2011.domein.local:143:TLS}

Je zou het netjes kunnen doen (omdat je EXT url intern gebruikt) en onderstaand uit voeren. (geen garantie dat alles blijft werken ) Heb je wel netjes een CERTIFICATE ingeladen van een externe CA?

MAP4 settings Run the Set-IMAPSettings cmdlet with the ExternalConnectionSettings parameter. Use the format Set-ImapSettings -ExternalConnectionSetting {<FQDN>:993:SSL}. For example, run Set-IMAPSettings -ExternalConnectionSetting {Dublin01.Contoso.com:993:SSL} if you want clients that connect through the server with FQDN Dublin01.Contoso.com to be able to look up their own IMAP setting.

[DaVaRiOuS]

Vorkie schreef op dinsdag 8 augustus 2017 @ 18:55:
[...]


Je zou het netjes kunnen doen (omdat je EXT url intern gebruikt) en onderstaand uit voeren. (geen garantie dat alles blijft werken ) Heb je wel netjes een CERTIFICATE ingeladen van een externe CA?


[...]

Ja heb zowel intern als externe certificaat ingeladen.

[Vorkie]

DaVaRiOuS schreef op dinsdag 8 augustus 2017 @ 18:56:
[...]


Ja heb zowel intern als externe certificaat ingeladen.

klopt het X509 certificaat met je externe URL? Zoals gevraagd.

/edit
Je hebt in ieder geval weer even stof tot nadenken

TLS kan ook untrusted zijn en nog steeds werken, SSL daarentegen niet. Mijn theorie ligt het ook aan Autodiscover die intern goed bereikbaar is. Als ze intern zitten, wordt door Outlook autodiscover het eea opgezocht, inclusief IMAP settings en deze verwijzen dan naar de SBS2011 URL ipv externe URL.

[ Voor 42% gewijzigd door Vorkie op 08-08-2017 19:01 ]

[DaVaRiOuS]

Vorkie schreef op dinsdag 8 augustus 2017 @ 18:57:
[...]

klopt het X509 certificaat met je externe URL? Zoals gevraagd.

/edit
Je hebt in ieder geval weer even stof tot nadenken

TLS kan ook untrusted zijn en nog steeds werken, SSL daarentegen niet. Mijn theorie ligt het ook aan Autodiscover die intern goed bereikbaar is. Als ze intern zitten, wordt door Outlook autodiscover het eea opgezocht, inclusief IMAP settings en deze verwijzen dan naar de SBS2011 URL ipv externe URL.

Ja die komt overeen.

Bedankt voor je informatie.
Ik heb zeker even wat stof om na te denken... Ik ga het nu even loslaten.. Wellicht krijg ik morgen ineens een helder idee

[ Voor 11% gewijzigd door DaVaRiOuS op 08-08-2017 19:03 ]