Exchange 2013 en IPv6

[Sinna]

Ik loop sinds kort tegen een vervelend probleem aan: verzonden mails blijven haperen in de wachtrij als Exchange de ontvangen mailserver via IPv6 wil bereiken. Externe connectiviteit is hier IPv4-only waardoor Exchange de externe mailserver niet kan bereiken.

Ik dacht dit opgelost te hebben door de Send connector externe DNS-lookups te laten doen, maar dat lijkt niet te helpen. Vreemds van al is dat als ik zelf een Retry forceer van de berichten die in de wachtrij zitten, deze wél verstuurd geraken (en ook aankomen bij de bestemmeling).

Ik heb me al suf zitten zoeken wat er nog meer mis zou kunnen zijn, maar 'k vind het zo snel niet. Tips & Tricks meer dan welkom, zeker nu in coronatijden de collega's nog méér afhankelijk zijn van email dan anders.

[charlez]

Hoe staat je connector ingesteld? ipv4 en ipv6?

[qless]

Als jullie ISP antiek is (geen ipv6 in 2020 is antiek) dan kun je wel nog een ipv6 tunnel aanmaken. Andere optie is alles van ipv6 van de exchange server verwijderen, en accepteren dan een ipv6 only mailserver dan niet meer bereikt kan worden.

[Sasuke]

Ondanks het feit dat wij bij onze klanten nergens ipv6 gebruiken, ben ik ook nog nergens een IPv6 only Exchange tegengekomen eigenlijk.

[Sinna]

Hoe staat je connector ingesteld? ipv4 en ipv6?

Via ECP kan ik geen onderscheid maken tussen IPv4 of IPv6. Enkel de FQDN kan ingevuld en staat nu op '*' (alles dus).
De DNS lookups zouden enkel op IPv4 mogen gebeuren (volgens EAC > Servers > Server > DNS Lookups) maar dat lijkt dus te mislukken.

Als jullie ISP antiek is (geen ipv6 in 2020 is antiek) dan kun je wel nog een ipv6 tunnel aanmaken. Andere optie is alles van ipv6 van de exchange server verwijderen, en accepteren dan een ipv6 only mailserver dan niet meer bereikt kan worden.

Ik kies er opzettelijk voor om (extern) nog IPv4 only te blijven. Zolang ik geen duidelijkheid heb hoe ik een dual-WAN IPv6 (Telenet Schoolnet en edpnet VDSL Pro) op een sluitende manier kan implementeren dan begin ik er liever niet aan. Ik zit hierbij richting NAT66 te denken maar moet mij daar nog verder in verdiepen.

Ondanks het feit dat wij bij onze klanten nergens ipv6 gebruiken, ben ik ook nog nergens een IPv6 only Exchange tegengekomen eigenlijk.

Ik heb dit tot nu toe ook nog niet tegengekomen. De twee maildomainen waar ik nu problemen mee ondervindt keren zowel een IPv4- als IPv6-adres terug bij een MX-lookup. Beide domeinen worden (toevallig?) bij Antagonist gehost.

Ik besef dat er inderdaad een tijd komt waarin mailservers enkel via IPv6 bereikbaar zullen zijn, maar tegen dan hoop ik al lang over te zijn op Exchange Online. Daarom wil ik er nu niet teveel tijd in stoppen, maar het wel uitgeklaard hebben.

[Sasuke]

Ah, het zijn de IPv6 DNS lookups die je de das omdoen ... dan zou ik lokaal IPv6 disablen OF ipv4 responses als 'preferred' zetten ipv standaard ipv6.

Prefer IPv4 over IPv6

Code: Selecteer alles

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0x20 /f

Disable IPv6

Code: Selecteer alles

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f

Uiteraard "reboot required" .. het zou anders geen Windows zijn hé

Nog een ander alternatief is om via een smarthost te werken. Als je bijvoorbeeld reeds O365 licenties hebt, kan je gerust al via connectors ontvangen/versturen via O365.

[lithion]

Ben je zeker dat jouw server geen publiek IPv6 heeft ingesteld staan?

[Sinna]

Ik begrijp niet waarom mijn server een publiek IPv6-adres zou ingesteld hebben staan. De firewall waar deze achter zit, babbelt opzettelijk enkel IPv4 en ik heb (nog) geen IPv6-range aangevraagd, noch bij Telenet, noch bij edpnet.

@Sasuke: ik zal die registry keys meenemen bij het volgende onderhoud. Thx!

Nog een ander alternatief is om via een smarthost te werken. Als je bijvoorbeeld reeds O365 licenties hebt, kan je gerust al via connectors ontvangen/versturen via O365.

Ik durf het nog niet echt aan om via O365 te gaan ontvangen en versturen.
Tot voor kort ervoer ik nl. problemen met berichten van een subdomein wat al op O365 zit en het hoofddomein (nog on-premise) waarbij deze niet doorkwamen omdat Microsoft er voor het gemak van uit ging dat als het subdomein bij hen staat, het hoofddomein ook wel bij hen zal staan. Ze hielden maw. geen rekening met de ingestelde MX-records voor het hoofddomein. Uit een recente test blijkt dat dit probleem opgelost zou zijn, maar ik zie dat graag nog bevestigd.

[Sasuke]

Mja, IPv6 is enabled by default op alle Windows 2008R2 servers en hoger. Als je DNS een IPv6 record in de DNS respons krijgt, word dit, standaard, als 'preferred' response gebruikt. Daarom dat dit soms wél werkt, en soms niet als jouw server/firewall enkel IPv4 kan praten.

[lithion]

Ja, IPv6 stack staat standaard aan op een machine, maar als die niet is ingesteld noch een toestel op het netwerk is aangesloten die een RA's met een config rondspuwt, dan zal een Windows-server steeds verbinden via IPv4 naar publieke servers. Zelfs als die via DNS zowel IPv4 als IPv6 ontvangt.

Daarnaast gaat de TCP/IP stack in Windows ook steeds IPv6 als eerste proberen en als dit niet lukt via IPv4 proberen. (Als die een routeerbaar ipv6 adres heeft natuurlijk.)

PS: exchange 2013 is al enkele jaren EOL.

[Sinna]

Exchange 2013 wordt pas in vanaf 12 april 2023 niet meer ondersteund.