Nous envoyons du courrier avec des caractères asiatiques unicode à notre serveur de messagerie de l'autre côté de notre WAN ... immédiatement après la mise à niveau d'un FWSM exécutant 2.3 (2) vers un ASA5550 exécutant 8.2 (5), nous avons vu des échecs sur les travaux de messagerie qui contenaient unicode et tout autre texte codé en Base64.
Les symptômes sont assez clairs ... en utilisant l'utilitaire de capture de paquets de l'ASA, nous avons accroché le trafic avant et après qu'il ait quitté l'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
J'ai téléchargé les pcaps de l'ASA en allant sur https://<fw_addr>/pcap_inside/pcap
et https://<fw_addr>/pcap_outside/pcap
... quand je les ai regardés avec Wireshark> Suivez le flux TCP, le trafic interne entrant dans l'ASA ressemble à ceci
EHLO metabike
AUTH LOGIN
YzFwbUlciXNlck==
cZUplCVyXzRw
Mais le même courrier laissant l'ASA sur l'interface extérieure ressemble à ceci ...
EHLO metabike
AUTH LOGIN
YzFwbUlciXNlck==
XXXXXXXXXXXX
Les caractères XXXX sont préoccupants ... J'ai résolu le problème en désactivant l'inspection 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 question à 5 $ ... notre ancien FWSM utilisait le correctif SMTP sans problèmes ... le courrier est tombé au moment exact où nous avons mis les nouveaux ASA en ligne ... qu'est-ce qui est spécifiquement différent de l'ASA qu'il brise maintenant ce courrier?
Remarque: les noms d'utilisateur / mots de passe / noms d'application ont été modifiés ... ne vous embêtez pas à essayer de décoder ce texte en Base64.