Enviamos correo con caracteres asiáticos Unicode a nuestro servidor de correo al otro lado de nuestra WAN ... inmediatamente después de actualizar de un FWSM con 2.3 (2) a un ASA5550 con 8.2 (5), vimos fallas en los trabajos de correo que contenían Unicode y otro texto codificado como Base64.
Los síntomas son bastante claros ... usando la utilidad de captura de paquetes del ASA, enganchamos el tráfico antes y después de que saliera del ASA ...
access-list PCAP line 1 extended permit tcp any host 192.0.2.25 eq 25
capture pcap_inside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface inside
capture pcap_outside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface WAN
Descargué los pcaps del ASA yendo https://<fw_addr>/pcap_inside/pcap
y https://<fw_addr>/pcap_outside/pcap
... cuando los miré con Wireshark> Seguir TCP Stream, el tráfico interno que entra al ASA se ve así
EHLO metabike
AUTH LOGIN
YzFwbUlciXNlck==
cZUplCVyXzRw
Pero el mismo correo que sale del ASA en la interfaz externa se ve así ...
EHLO metabike
AUTH LOGIN
YzFwbUlciXNlck==
XXXXXXXXXXXX
Los caracteres XXXX son preocupantes ... Solucioné el problema desactivando la inspección ESMTP:
wan-fw1(config)# policy-map global_policy
wan-fw1(config-pmap)# class inspection_default
wan-fw1(config-pmap-c)# no inspect esmtp
wan-fw1(config-pmap-c)# end
La pregunta de $ 5 ... nuestro antiguo FWSM usó la reparación de SMTP sin problemas ... el correo cayó en el momento exacto en que pusimos en línea los nuevos ASA ... ¿Qué es específicamente diferente del ASA que ahora está rompiendo este correo?
Nota: se cambiaron los nombres de usuario / contraseñas / nombres de aplicaciones ... no se moleste en decodificar Base64 este texto.