iOS y Exchange con dos ISP y MX redundantes: FQDN, Autodiscover y failover sin interrupciones

Guía práctica para mantener el acceso a Exchange (OWA/EWS/EAS) desde iOS y otros clientes cuando hay dos ISP con MX redundantes. Aprenderás a fijar FQDN por servicio, diseñar failover con balanceo o DNS y separar claramente el acceso HTTPS del flujo SMTP.

Índice

Resumen de la pregunta

Reto: garantizar que usuarios de iOS (y otros clientes) sigan accediendo a Exchange (EWS/OWA/EAS/MAPI) cuando la organización dispone de dos ISP con sus propias IP públicas y MX redundantes, y el router perimetral está en modo failover o dual‑WAN. ¿Qué hacer con las ExternalUrl de Exchange y con Autodiscover?

Idea clave de arquitectura

Mantén FQDN únicos y estables por servicio (por ejemplo, mail.example.com y autodiscover.example.com) que nunca cambian para los clientes. No publiques nombres “por ISP”. La conmutación de ISP debe resolverse antes de llegar a Exchange (capa DNS o balanceo/reverse proxy). Así, las ExternalUrl de Exchange permanecen fijas y los dispositivos no necesitan reconfiguración.

Clientes (iOS/Outlook) → FQDN estable (DNS/LB) → Reverse Proxy/LB → Exchange (CAS/MBX)
                                     │
                                 ISP A / ISP B

MX ≠ Acceso de clientes. Los MX solo afectan al SMTP entrante. El acceso de clientes es HTTPS (443) vía OWA/EWS/EAS/MAPI. Diseña cada plano por separado.

Opciones de publicación de clientes (HTTPS)

Opción recomendada: Balanceador / Reverse Proxy

Coloca un balanceador (hardware o software) con dos salidas hacia ISP A e ISP B. Publica un único VIP/Virtual Server en 443 y apunta tu FQDN (mail.example.com) a ese VIP.

Health checks a Exchange (HTTP/HTTPS) para retirar del pool un servidor o un camino roto.
Si cada ISP requiere IP distinta, el FQDN puede tener dos registros A/AAAA (uno por ISP). El balanceador y sus sondas decidirán el camino sano.
Preserva cabeceras y negociación TLS: X-Forwarded-For, SNI, ALPN; mantén soporte para HTTP/2 según tu política.

Ventajas

Conmutación rápida y controlada; no dependes de TTL.
Permite offload TLS, WAF, rate‑limit, reescrituras y cabeceras.
Un único punto para observabilidad (logs, métricas).

Consideraciones

Alta disponibilidad del propio balanceador (activo/pasivo o clúster).
Certificados y keystore gestionados correctamente en el proxy.

Opción: DNS con failover y verificación de estado

Mantén un FQDN por servicio con sondas HTTP/HTTPS en tu proveedor DNS. Si el ISP A cae, su A/AAAA se despublica automáticamente; los clientes resolverán al ISP B.

TTL bajo (p. ej., 300 s). Evita round‑robin sin sondas.
Algunos clientes cachean resoluciones; modela la experiencia con pruebas reales.

Opción: DNS dinámico con monitor local

Un script de monitorización local detecta que un ISP no está operativo y actualiza (vía API) el registro A/AAAA del FQDN para dejar activo solo el camino sano.

Útil si no dispones de balanceador ni DNS con sondas.
Requiere robustez en el monitor y control de TTL.

Comparativa rápida

Opción	Time to Recover	Complejidad	Control fino	Dependencia de TTL
Balanceador/Reverse Proxy	Segundos	Media‑Alta	Alta (L7, reglas, WAF)	No
DNS con sondas	TTL + propagación	Media	Media	Sí
DNS dinámico con script	TTL + ejecución	Media	Media	Sí

Configuración de Exchange: URLs externas constantes

Define una sola URL externa por servicio, siempre basada en el FQDN estable. No uses nombres por ISP.

# Autodiscover interno: apunta al FQDN público con certificado válido
Set-ClientAccessService -Identity "EXCHANGESERVER" `
  -AutoDiscoverServiceInternalUri "https://autodiscover.example.com/autodiscover/autodiscover.xml"

EWS
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" `
  -ExternalUrl "https://mail.example.com/EWS/Exchange.asmx"

OWA
Set-OwaVirtualDirectory -Identity "owa (Default Web Site)" `
  -ExternalUrl "https://mail.example.com/owa"

ActiveSync (EAS para iOS nativo)
Set-ActiveSyncVirtualDirectory -Identity "Microsoft-Server-ActiveSync (Default Web Site)" `
  -ExternalUrl "https://mail.example.com/Microsoft-Server-ActiveSync"

MAPI over HTTP (Exchange 2016/2019)
Set-MapiVirtualDirectory -Identity "mapi (Default Web Site)" `
  -ExternalUrl "https://mail.example.com/mapi"

(Opcional) ECP
Set-EcpVirtualDirectory -Identity "ecp (Default Web Site)" `
  -ExternalUrl "https://mail.example.com/ecp"

Certificados: el certificado público debe incluir al menos mail.example.com y autodiscover.example.com (SAN o wildcard válido). No cambies CN/SAN por ISP. Asegura cadena intermedia correcta y OCSP stapling cuando sea posible.

HTTP redirect y rutas “limpias”

Publica https://mail.example.com/owa como URL canónica y redirige https://mail.example.com/ → /owa en el proxy o IIS (HTTP 301/302).
Evita exposiciones innecesarias (/ecp) desde Internet; restringe por IP o MFA perimetral.

Autodiscover: alta disponibilidad real

Autodiscover debe tener la misma disponibilidad que mail.example.com porque es la pieza que permite a los clientes descubrir las rutas de servicio sin cambios de configuración.

Usa autodiscover.example.com como FQDN principal y no lo vincules a un ISP concreto.
Si implementas Autodiscover HTTP Redirect, asegúrate de que el host de redirección comparte la misma lógica de failover.
Si tienes split‑brain DNS, alínealo: internos resuelven a IP interna o al VIP del LB; externos, a IP pública(s).

Flujo de correo (MX/SMTP) totalmente independiente

Publica dos MX (prioridades 10 y 20) que apunten a hostnames con IP en cada ISP, o a un único FQDN con dos A/AAAA.
Abre TCP 25 en ambos ISP hacia tu(s) Exchange/Edge; mantén NAT coherente.
Salida (SMTP saliente): si envías por ambos ISP, incluye ambas IP en SPF, configura PTR/rDNS y ajusta DKIM/DMARC. Evita saltar entre IP con mala reputación.
Considera dos Send Connectors o uno con dos smart hosts con costos/pesos, para conmutación controlada.

Firewall, NAT y sondas de salud

Permite 443/TCP (y 80/TCP si haces redirección) por ambos ISP hacia el VIP o CAS.
Configura health checks reales:
- OWA: GET /owa/healthcheck.htm → 200 OK.
- EWS: HEAD /EWS/Exchange.asmx → 200/401 esperado.
- MAPI: GET /mapi/healthcheck → 200 (según versión).
- EAS: OPTIONS /Microsoft-Server-ActiveSync → 200/401.
Ajusta timeouts para EAS: mantener conexiones largas (Direct Push). Evita inactividad < 30 min.
Habilita NAT hairpin/loopback si los clientes internos resuelven al FQDN público y acceden desde la LAN.

iOS y apps: detalles prácticos

La app nativa de iOS usa Exchange ActiveSync (EAS). Algunas apps de terceros usan EWS (p. ej., apps de calendario); ambas deben apuntar a mail.example.com.
El Autodiscover es crítico para que el dispositivo reprograme rutas tras cambios de IP; de ahí la importancia del FQDN estable y la alta disponibilidad del DNS/LB.
Cuando un ISP cae, iOS puede persistir conexiones: el failover visible puede tardar hasta que reintenta o vence la caché DNS del sistema/app. TTL bajos ayudan.

DNS: registros de ejemplo

; Zona example.com
; FQDN únicos por servicio
autodiscover  300  IN  A     203.0.113.10   ; ISP A (o VIP LB)
autodiscover  300  IN  A     198.51.100.10  ; ISP B (si procede)
mail          300  IN  A     203.0.113.10
mail          300  IN  A     198.51.100.10

; MX para SMTP entrante
example.com   3600 IN  MX 10 mx-a.example.com.
example.com   3600 IN  MX 20 mx-b.example.com.

mx-a          300  IN  A     203.0.113.25
mx-b          300  IN  A     198.51.100.25

; (Opcional) AAAA si tienes IPv6 funcional en ambos ISP

Nota IPv6: publica AAAA solo si ambos caminos son sólidos. De lo contrario, Happy Eyeballs podría preferir IPv6 roto y degradar el acceso.

Ejemplo de reverse proxy (HAProxy)

frontend https_front
  bind *:443 ssl crt /etc/haproxy/certs/example.pem
  mode tcp
  tcp-request inspect-delay 5s
  tcp-request content accept if { reqsslhello_type 1 }
  usebackend beexchange if { req.sslsni -i mail.example.com } or { req.sslsni -i autodiscover.example.com }

backend be\_exchange
mode tcp
option ssl-hello-chk
balance roundrobin
server ex1 10.0.0.11:443 check ssl verify none
server ex2 10.0.0.12:443 check ssl verify none

Para comprobaciones L7 con rutas específicas, mueve el terminación TLS al proxy y usa http-check con GET /owa/healthcheck.htm.

Pruebas de conmutación: plan paso a paso

Prueba controlada de caída de ISP: desconecta ISP A.
Verifica que autodiscover.example.com y mail.example.com resuelven/alcanzan el camino sano (dig/nslookup, curl).
Abre OWA, inicia sesión, navega correo y calendario.
Revisa sincronización EAS en iOS; crea/cancela eventos, verifica latencia.
Repite con caída de ISP B.

Revisión de cachés y TTL

En Windows: ipconfig /flushdns.
En macOS: sudo killall -HUP mDNSResponder.
En iOS: alterna Modo Avión o reinicia Wi‑Fi para despejar cachés.

Monitoreo y operación diaria

IIS logs (W3C): latencias, códigos HTTP, rutas. Activa Advanced Logging si necesitas campos extra.
Performance counters: EWS, OWA, ActiveSync.
Eventos en Exchange: errores de conectividad, autenticación, certificados.
Pruebas sintéticas: sondas cada 1–5 min contra /owa/healthcheck.htm y /EWS/Exchange.asmx.

Seguridad y hardening

Deshabilita TLS 1.0/1.1; prioriza TLS 1.2/1.3 según soporte.
Limita cipher suites débiles; usa PFS (ECDHE).
Implementa MFA en el borde (proxy con IdP) cuando sea posible.
Revisa lockout y rate limiting ante ataques de fuerza bruta.
Audita exposición de /ecp y desalienta su publicación directa.

Errores comunes (y cómo evitarlos)

Publicar ExternalUrl por ISP: obliga a reconfigurar clientes y rompe Autodiscover durante incidentes. Solución: FQDN único.
Round‑robin sin sondas: apunta a IP caídas. Solución: balanceador o DNS con health checks.
TTL alto: dilata el failover. Solución: TTL 300 s (o lo que tu proveedor soporte) y pruebas reales.
AAAAs asimétricos: IPv6 solo en un ISP. Solución: simetría o sin AAAA.
Timeouts agresivos en el proxy: rompen Direct Push EAS. Solución: aumenta inactividad.

Checklist de implementación

Definidos mail.example.com y autodiscover.example.com como FQDN únicos.
Certificado público con SAN adecuados instalado y vigente.
ExternalUrl configuradas y probadas (OWA/EWS/EAS/MAPI/ECP).
Balanceador o DNS con sondas configurado y con health checks reales.
Firewall/NAT abiertos en 443/80 en ambos ISP y reglas coherentes.
MX diseñados aparte; SPF, DKIM, DMARC y PTR/rDNS revisados.
Pruebas de caída de cada ISP documentadas con resultados.
Alertas por expiración de certificados y por cambios de salud.

Preguntas frecuentes

¿Puedo fijar dos ExternalUrl (una por ISP)? No. Mantén una sola por servicio y resuelve la conmutación en el borde (DNS/LB).
¿Autodiscover debe ir al mismo FQDN que OWA? Puede ser distinto (autodiscover.example.com vs mail.example.com), pero ambos deben tener la misma HA.
¿Los MX influyen en iOS/OWA? No. MX solo para SMTP. El acceso de usuarios es HTTPS.
¿Necesito cambiar perfiles de iOS al conmutar ISP? No, si mantienes FQDN estables y failover perimetral.

Plantilla de pruebas con comandos útiles

# Comprobar resolución
nslookup mail.example.com
nslookup autodiscover.example.com

Verificar endpoints

curl -I [https://mail.example.com/owa/healthcheck.htm](https://mail.example.com/owa/healthcheck.htm)
curl -I [https://mail.example.com/EWS/Exchange.asmx](https://mail.example.com/EWS/Exchange.asmx)
curl -I [https://mail.example.com/mapi/healthcheck](https://mail.example.com/mapi/healthcheck)
curl -X OPTIONS -i [https://mail.example.com/Microsoft-Server-ActiveSync](https://mail.example.com/Microsoft-Server-ActiveSync)

Exchange (desde el servidor)

Test-WebServicesConnectivity -ClientAccessServer EXCHANGESERVER -TrustAnySSLCertificate:\$true
Test-ActiveSyncConnectivity -MailboxCredential (Get-Credential) -UseAutodiscoverForClientAccessServer

Diseños de referencia

Balanceador perimetral con doble ISP

Internet ──→ [ISP A] ─┐
                      ├─→ [LB/Reverse Proxy] ─→ Exchange (CAS/MBX)
Internet ──→ [ISP B] ─┘

El FQDN mail.example.com apunta al VIP del LB. El LB decide por qué ISP salir y comprueba salud del backend.

DNS con sondas

mail.example.com → A 203.0.113.10 (ISP A)  ✅ si /owa/healthcheck.htm OK
                   A 198.51.100.10 (ISP B)  ✅ si /owa/healthcheck.htm OK

Cuando falla una sonda, el proveedor despublica el registro correspondiente.

Consejos de rendimiento

Activa HTTP/2 si tu proxy lo soporta y valida compatibilidad con clientes.
Usa compresión prudente para EWS/OWA (texto/JSON/HTML), evita comprimir binarios.
Haz offload TLS en el proxy si necesitas inspección L7; calibra CPU y curvas de tráfico.

Gobernanza de certificados

Renovaciones automatizadas y alertas (≥30 días antes del vencimiento).
Evita comodines excesivos; incluye solo SAN necesarios (mail, autodiscover).
Comprueba la cadena completa desde Internet tras cada renovación.

Cuándo considerar un servicio perimetral en la nube

Si no cuentas con balanceador ni DNS con sondas, una alternativa moderna es colocar Exchange detrás de un servicio de edge/balanceo en la nube con comprobaciones de salud y conmutación automática. Aun así, tus FQDN siguen siendo únicos y estables para los clientes; solo cambias la capa de publicación.

Resumen ejecutivo

Usa un FQDN estable por servicio (mail.example.com y autodiscover.example.com). Implementa la conmutación entre ISP en el DNS con sondas o en un balanceador/reverse proxy y mantén las ExternalUrl de Exchange fijas. Diseña por separado el acceso de clientes (HTTPS) y el flujo de correo (MX/SMTP). Prueba fallos reales, monitoriza de forma continua y endurece seguridad y certificados.

Comandos de referencia (consolidado)

# ExternalUrl fijas por servicio
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -ExternalUrl "https://mail.example.com/EWS/Exchange.asmx"
Set-OwaVirtualDirectory          -Identity "owa (Default Web Site)" -ExternalUrl "https://mail.example.com/owa"
Set-ActiveSyncVirtualDirectory   -Identity "Microsoft-Server-ActiveSync (Default Web Site)" -ExternalUrl "https://mail.example.com/Microsoft-Server-ActiveSync"
Set-MapiVirtualDirectory         -Identity "mapi (Default Web Site)" -ExternalUrl "https://mail.example.com/mapi"
Set-EcpVirtualDirectory          -Identity "ecp (Default Web Site)" -ExternalUrl "https://mail.example.com/ecp"

Autodiscover interno

Set-ClientAccessService -Identity "EXCHANGESERVER" \`
-AutoDiscoverServiceInternalUri "[https://autodiscover.example.com/autodiscover/autodiscover.xml](https://autodiscover.example.com/autodiscover/autodiscover.xml)"

Buenas prácticas rápidas

Un FQDN por servicio, siempre.
Health checks de verdad (rutas válidas, no solo ping/443 abierto).
TTL controlado y pruebas con usuarios piloto.
SPF/DKIM/DMARC/PTR para salida SMTP en ambos ISP.
TLS moderno y protección de /ecp.

Si aplicas estos principios, los iPhone, iPad, Outlook y apps EWS seguirán funcionando durante fallos de ISP sin intervención del usuario ni cambios en Exchange.