Cannot get SMTP 220 ESMTP banner from outside - It works well from the inside

Here is the problem: 8BITMIME it seems your firewall doesn't supports it. Something similar discussed here
http://social.technet.microsoft.com/forums/en-US/exchangesvrsecuremessaginglegacy/thread/39838203-3363-440f-a520-91effb800213

first thing I would try is to ensure the packet gets thru the firewall ok by using packet-tracer

packet-tracer input outside tcp 4.4.4.4 4000 1.2.3.4 25 detailed

replace the 1.2.3.4 with the public IP of barracuda2.domain.com.  the source info doesn't matter.  post the results of that test.

Thank you amitkulshrestha I will check that out.

Meanwhile here is the packet-tracer out to port 25:

Firewall B#
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,outside) barracuda2 LAN_Barracuda netmask 255.255.255.255
  match ip inside host LAN_Barracuda outside any
   static translation to barracuda2
    translate_hits = 1, untranslate_hits = 1832
Additional Information:
NAT divert to egress interface inside
Untranslate barracuda2/0 to LAN_Barracuda/0 using netmask 255.255.255.255

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp any host barracuda2 eq smtp
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: SSM-DIVERT
    Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: SSM_SERVICE
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: SSM-DIVERT
Subtype:
Result: ALLOW
Config:
    Additional Information:

Phase: 10
Type: SSM_SERVICE
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (inside,outside) barracuda2 LAN_Barracuda netmask 255.255.255.255
  match ip inside host LAN_Barracuda outside any
    static translation to barracuda2
    translate_hits = 1, untranslate_hits = 1832
Additional Information:

Phase: 12
Type: NAT
Subtype: host-limits
Result: ALLOW
    Config:
static (inside,outside) barracuda2 LAN_Barracuda netmask 255.255.255.255
  match ip inside host LAN_Barracuda outside any
    static translation to barracuda2
    translate_hits = 1, untranslate_hits = 1832
Additional Information:

Phase: 13
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 14
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 12960305, packet dispatched to next module

Result:
input-interface: outside
    input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow


* I am wondering about these two outputs:
1 Untranslate barracuda2/0 to LAN_Barracuda/0 using netmask 255.255.255.255

2 translate_hits = 1, untranslate_hits = 1832



Thanks Cyclops3590!

the untranslate just means converting the public IP to the local IP for barracuda2.  it looks like the asa isn't the problem, but I want to make sure I'm clear about something.  So you have two different ASAs (one works and one doesn't) and barracuda and barracuda2 translate to the same exact host on your network?

If so, then I doubt the 8BITTIME is causing the issue as it should on the other ASA.  As both are 5510 ASAs they have the same capabilities obviously.  What is the version of each ASA.  I assume the packet-tracer looks good on the good ASA as well.  The only other issue potentially is protocol inspection.  Can you post the output of "show service-policy global" from each ASA?  And please make sure to label which output came from the working ASA.  Thanks.

Here is the packet tracer from the firewall that is actually working.

 
 OfficE a # packet-tracer input outside tcp 172.16.10.5 25 98.XX.YY.249 25

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,outside) Barracuda_Outside Barracuda_Spam netmask 255.255.255.255
  match ip inside host Barracuda_Spam outside any
    static translation to Barracuda_Outside
    translate_hits = 45027, untranslate_hits = 77915
Additional Information:
NAT divert to egress interface inside
Untranslate Barracuda_Outside/0 to Barracuda_Spam/0 using netmask 255.255.255.255

Phase: 3
Type: ACCESS-LIST
Subtype: log
        Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp any host Barracuda_Outside eq smtp
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: SSM-DIVERT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: SSM_SERVICE
Subtype:
Result: ALLOW
    Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: SSM-DIVERT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: SSM_SERVICE
Subtype:
Result: ALLOW
Config:
Additional Information:
      Phase: 10
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (inside,outside) Barracuda_Outside Barracuda_Spam netmask 255.255.255.255
  match ip inside host Barracuda_Spam outside any
    static translation to Barracuda_Outside
    translate_hits = 45027, untranslate_hits = 77915
Additional Information:

Phase: 11
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) Barracuda_Outside Barracuda_Spam netmask 255.255.255.255
  match ip inside host Barracuda_Spam outside any
    static translation to Barracuda_Outside
    translate_hits = 45027, untranslate_hits = 77915
Additional Information:

Phase: 12
Type: IP-OPTIONS
    Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 13
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 3794961, packet dispatched to next module

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow

how about the show service-policy global outputs?

Firewall with the problem# show service-policy global

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns migrated_dns_map_1, packet 3603213, drop 111790, reset-drop 0
      Inspect: ftp, packet 636, drop 0, reset-drop 0
      Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: rsh, packet 0, drop 0, reset-drop 0
      Inspect: rtsp, packet 218, drop 0, reset-drop 0
      Inspect: sqlnet, packet 0, drop 0, reset-drop 0
      Inspect: skinny , packet 42, drop 0, reset-drop 0
      Inspect: sunrpc, packet 0, drop 0, reset-drop 0
      Inspect: xdmcp, packet 0, drop 0, reset-drop 0
      Inspect: sip , packet 20, drop 0, reset-drop 0
      Inspect: netbios, packet 1289174, drop 0, reset-drop 0
      Inspect: tftp, packet 0, drop 0, reset-drop 0

Firewall working:

 show service-policy global

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns preset_dns_map, packet 3300105, drop 146254, reset-drop 0
      Inspect: ftp, packet 6290, drop 0, reset-drop 0
      Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: rsh, packet 0, drop 0, reset-drop 0
      Inspect: rtsp, packet 0, drop 0, reset-drop 0
      Inspect: sqlnet, packet 0, drop 0, reset-drop 0
      Inspect: skinny , packet 16, drop 0, reset-drop 0
      Inspect: sunrpc, packet 0, drop 0, reset-drop 0
      Inspect: xdmcp, packet 0, drop 0, reset-drop 0
      Inspect: sip , packet 0, drop 0, reset-drop 0
      Inspect: netbios, packet 1807945, drop 0, reset-drop 0
      Inspect: tftp, packet 0, drop 0, reset-drop 0

just dawned on me.  how are you taking care of return traffic?  so the packet comes in on the second ASA and gets to the barracuda.  The barracuda then looks at where the packet came from and sends the response in the direction; my guess is the first ASA.  been awhile since I've dealt with a barracuda but can you add a second IP to its interface?  If not then you need to do an outside policy nat on the second ASA.  What version of ASA OS do you have?  Chances are this will be easiest in ASDM anyway.  Its different depending if you have pre or post 8.3 code.  In my opinion its easier in post 8.3

BTW, if you do this, make sure you don't auto-trust by the IP you use for the outside nat; most likely the inside interface IP or else you could turn your barracuda into an open relay.

I think you are 100% right. Barracuda only knows how to get to the outside using the current network. I dont think it knows how to get to the outside using the second ASA firewall network.

I am wondering if a DNS entry in active directory might help with this issue

The Barracuda itself does not know how to get to the outside other than its current primary ASA firewall situation. I need to have the traffic between this Barracuda here have access to the internet through the secondary ASA firewall.

The software version that I have is Cisco Adaptive Security Appliance Software Version 8.0(3)

try the following:

access-list smtp-pol-nat permit tcp any **barracuda public IP** eq smtp

nat (outside) 10 access-list smtp-pol-nat outside
global (inside) 10 interface

clear xlate

what that should do is traffic coming into the outside interface, if it matches the ACL, will PAT according to that NAT 10 policy.  In this case the outside host will be PAT'ed to the inside interface.  In this case, when the traffic gets to the barracuda, it will route back properly.  However, this is why I said you need to make sure you exclude the inside IP (or if you choose to specify a different IP) from being auto-trusted to send email to non-domain email addresses or the barracuda can become an open relay because it thinks the email is coming from the second ASA.  It doesn't know its actually from an outside host.

keep in mind this is an odd configuration to perform.  i'm pretty sure this should work for you though.

This is what I already have and I am having trouble adding an additional access-list for the ASA:

static (inside,outside) barracudaOutside LAN_Barracuda netmask 255.255.255.255

access-list inside_mpc extended permit tcp any any eq smtp

access-list outside_access_in extended permit tcp any host barracuda2 eq smtp

Should I erase this and redo?

I learned that the internet traffic between offices had to be allow by AT&T. They had to allow all traffic 0.0.0.0. It was an internal BGP thing between offices.

 Everything was fine in the firewall, it was just that the Barracuda was not able to respond back.

Thanks for your time with this Cyclops3590.