Hi all, I have a bit of a problem with bounce verification and I am hoping someone can help me. It could be to do with the way we have mail routing and I am hoping I can explain the routes enough for you to understand. We have 2 x C300 in place in two locations in the world. One is in Australia and the other is in Vancouver. We have several domains and depending on the domain used the email will either come in via the Australian or Vancouver ESA.
All AU users go out via the AU ESA, all American / Canadian users go out via the VN ESA.
A user in AU can have an email address of user@VN.ESA and will exit the AU ESA and then when replied to will come in via the VN ESA.
Visa versa, a User in VN can have an email address of user@AU.ESA and it will exit via the VN ESA and enter via the AU ESA.
Any user in AU with a user@AU.ESA will exit and enter via AU and any VN user with a user@VN.ESA will exit and enter via the VN ESA. These type of emails work fine.
Still with me?
I have setup bounce verification on both ESA to have the same Key (is this a bad thing?)
When the user@VN.ESA in AU sends an email, it exits via the AU ESA and then the reply comes back in via the VN ESA and gets rejected, I believe this is because the VN ESA sees the correct KEY, however the IP address is wrong.
This is the error. (some details changed to protect the innocent) "< mail.AU.ESA #5.0.0 smtp; 5.1.0 - Unknown address error 550-"5.7.1 <firstname.lastname@example.org>... recipient denied, because MX 10 'smtp.VN.ESA.' [192.168.1.1] for <email@example.com> rejected address saying: #5.1.0 Rejected by bounce verification." (delivery attempts: 0)>"
Setting a matching BV key for each of your IronPort's is imperative for your setup, so that is fine. ( I would double-check them *just to make sure*, as any extra whitespace, etc.. can alter the output the key creates )
That being said, you don't mention what version of AsyncOS you are running on these units.
On some older versions of AsyncOS there was a defect which prevented the appliances from correctly recognizing the encoded tags. This meant that all NDR's were rejected, even valid ones. This defect is fixed in the latest builds of versions 5.5.1, 5.5.2, 6.0.0, 6.1.0, 6.1.5 and 6.3.5, but not for older versions (4.x, 5.1.x, 5.0.x, and so on). If your appliance runs on one of these older versions, you would need to upgrade before employing BV.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :