FTD NAT to Exchange server help

[Ken C. Musk]

I am banging my head here trying to figure out why I can't get Exchange email to flow.  I have this same setup at a different site with no issues.  I have the settings mirrored to this new site and Exchange email will just not flow.

I currently have a newly built 5516x with FTD image to replace a current ASA.  Internet will work with no issues as to my site-to-site tunnels.  However Exchange email will not flow when I place the FTD in place of the ASA.  When I do a packet tracer coming from an Outside IP to the Exchange Outside IP the hits are all allowed.  I can even see the hit counters on the ACP going up for the Exchange rule.

Attached is the packer tracer output, but I xx.xx the real outside IP.

My NAT rule is:
(Inside) to (Outside_Primary) source static C-EXCHANGE-INSIDE C-EXCHANGE-OUTSIDE no-proxy-arp
translate_hits = 11, untranslate_hits = 2

My ACP rule is:

access-list CSM_FW_ACL_ line 13 advanced permit tcp ifc Outside_Primary any ifc Inside object C-EXCHANGE-INSIDE object-group SMTP rule-id 268449832 (hitcnt=8) 0x3039f661
access-list CSM_FW_ACL_ line 13 advanced permit tcp ifc Outside_Primary any ifc Inside host 10.10.50.51 eq smtp rule-id 268449832 (hitcnt=8) 0x991e5e44

The rules are being hit, and I have verified that the inside/outside IPs for Exchange are correct.

What could I be missing?  I might have to call TAC on this one, but I can't do this live during hours, so would have to schedule something after hours when I can take it down again.  

Any other show/debug type commands I can do when I put this back in line to test again..?

Thanks,

[Rob Ingram]

@Ken C. Musk Take a packet capture on the inside interface to determine if the exchange server is responding to the real traffic flow.

You can also run the command "system support firewall-engine-debug" from the CLI and apply a filter to monitor the real time communication.

I assume the exchange server has a route back to the internet via the FTD and routing is working ok?

[Ken C. Musk]

Hi Rob,

So I can "test" these commands on a live FTD that is working just so I can see what the output should look like, minus the different IPs. 

As for a Packet Capture on the inside interface I am not seeing how this would work.  An inside host would never be going through the FTD to hit Exchange since Exchange is on-premise.  

Would this be how you would setup the debug:

- system support firewall-engine-debug

- Please specify an IP protocol: tcp
- Please specify a client IP address: 10.10.48.88 <-- Generic host on the inside
- Please specify a client port: 1235
- Please specify a server IP address: 10.10.50.51 <-- Exchange server
- Please specify a server port: 25

Then from that Generic host try to hit exchange and should see something..?  I just don't see how any traffic will work since Exchange is on-premise so no need for it to hit the FTD.

Our Exchange server is hosted internally and mapped to a real outside IP.  Only http, https, smtp are port forwarded from any outside to internal exchange.

As for routing we have a XR Core switch with all the SVIs on it, which in turn have a default route to the FTD.

Thanks,

Ken~

[Rob Ingram · Accepted solution]

@Ken C. Musk your issue was from outside to inside, from the internet to the exchange server. So capturing traffic on the inside interface we can determine if traffic flows through the firewall and if the exchange server responds.

I wasn't suggesting filtering on a generic host on the inside network communicating with the exchange server.

With the "system support firewall-engine-debug" command don't apply the source port you'd never get a match filtering on a port of 1235, just leave blank. You are concerned with the exchange IP address and optionally the port. This command does not simulate traffic like packet-tracer does, it monitors real traffic flow.

[Ken C. Musk]

Hi Rob,

I was able to test again and discovered that when I apply the Static NAT rule for exchange for inside IP mapped to outside exchange IP then my internal exchange server can no longer reach inet.  If I remove that NAT rule, then the internal exchange server can ping out with no issues.

Never seen this before and we have another site that is setup the exact same way with no issues.  We have no dynamic routing in place.  We have ip route 0.0.0.0 0.0.0.0 (outside IP)

ip route 10.10.48.0 255.255.248.0 (inside IP)

Everything on the inside network can access inet with no issues, just not Exchange once the NAT rule is in place.  I have been over by working config and this config for hours via command line, and nothing is jumping out at me for being different (besides IP addresses)

The Exchange server can ping its default gateway with no issues.  It can even ping the inside interface of the FTD with no issues.  I can see the NAT rule getting hit for Exchange, but return traffic is what is not working.  Locally all email works since the client are inside the network.

Thanks,

Ken~

[Ken C. Musk]

I finally have things working as they should.  Turns out it was a provider issue with an upstream device holding onto the mac/arp table.  I have an on-prem provider device that I kept rebooting, but that never solved the issue.  By doing the command above and not seeing any traffic got me thinking more.  So I mirrored the MAC address from old ASA over to the new one and email started flowing like it should.

I am sure I could have called the provider and had them reboot whatever the upstream device was, but I didn't have their info on hand   

Thanks,

Ken~