Exchange 2016 with Static NAT Can't communicate win AD through firewall R80.10

[Viviana_Checa]

Hi guys,

Is good to hear about you, I have an issue about communications between Exchange 2016 on DMZ with Static NAT and Active Directory on Internal Network.

The tests made as follows:

1) The Exchange 2016 (with Hide NAT), communicate successfully with Active Directory on Internal Network,  this means, for example, the Service Microsoft Exchange Active Directory Topology on Exchange 2016 Server, runs well, start as automatic service with no issues.

2) The Exchange 2016 (with Static NAT), can not communicate with Active Directory on Internal Network,  this means, the Service Microsoft Exchange Active Directory Topology on Exchange 2016 Server do not start automatically, then it forces to start an I got an error "The Microsoft Exchange Active Directory Topology service on Local Computer started and then stopped. Some services stop automatically if they are not in use by others services or programs "

Drops on Logs:

ldap traffic dropped from Exchange DMZ to AD Reason: TCP packet out of state: Server to client packet of an old TCP connection

TCP_3268 traffic dropped from Exchange DMZ to AD Reason: TCP packet out of state: Server to client packet of an old TCP connection

Checkpoint Support recommended to set the TCP Session Timeout from 3600 to 7200. But it did not work. The service

Microsoft Exchange Active Directory Topology still not run.

Have you seen this issue?

I will appreciate your valuable comments for fix it!

Greetings

Viviana

[ED]

Hi,

I hope this sk can help you "Smart Connection Reuse" feature modifies some SYN packets

A bad solution just to check if communication goes through is to try to disable drop on TCP out of state on that gateway with an exception in Global properties. 

I hope you get a better solution. Is this persistent problem after a reboot of Exchange server? (if possible). 

[Viviana_Checa]

Hello Enis,

Thank you for your comments, the issue persist after reboot the Exchange server

[Kaspars_Zibarts]

I think we need little more information here. Ideally logs showing original accept with translation info and then the drop log with the same.

Since it's saying that connection did belong to "accepted" traffic and was discarded from table at some point. Could be timer, could be the way policy is pushed and connections re-matched..

[Viviana_Checa]

Hello Kaspars,

Thank you for your comments, what additional information do you need ?

Thanks!

[Vladimir]

Need more data to troubleshoot.

One thing to keep in mind: when you have a host in "Hide" NAT mode, it'll will hide behind gateway's IP on all of its interfaces. I.e. connecting to internal AD, it'll identify itself as the internal interface of the gateway, unless you had a manual NAT rules stating "Internal to DMZ original, original" and "DMZ to Internal original, original".

When you are specifying Static NAT, the traffic between Exchange in DMZ and your AD servers will be untranslated and will originate in a different network.

Please check if your DMZ's subnet is defined in the AD, if either DCs or Exchange referring to each other by name, rather than IP and if the incorrect IPs are cached in the DNS. You may want to clear the cache on DNS and AD servers for Exchange as well as flushdns on Exchange .

I suspect that Microsoft Exchange Active Directory Topology relying on RPC. So depending on which server was initiating connections earlier, the Exchange may have been getting replies on the IP in the same range as the rest of your AD and is now waiting for replies to IP in the different range.

Is the Exchange in DMZ a CAS only or a complete server? If second, please verify that you have unimpeded communication between it and the DCs:

 Exchange, Firewalls, and Support… Oh, my! – You Had Me At EHLO… 

[Viviana_Checa]

Hello Vladimir,

Thank you for your comments, I did some test about NAT with Exchange 2016 on DMZ an Internal servers AD

1) Exchange server 2016 on DMZ with  Hide NAT works fine! all services running.

2) Exchange servers 2016 on DMZ and Internal AD Server with NO NAT (manual NAT) between them, the services not running!

3) Exchange servers 2016 on DMZ with static NAT, the services not running!

The only way for a good communication between Exchange 2016 on DMZ and Internal AD servers is with Hide NAT. ! Why?

About your comments:

Please check if your DMZ's subnet is defined in the AD, if either DCs or Exchange referring to each other by name, rather than IP and if the incorrect IPs are cached in the DNS. You may want to clear the cache on DNS and AD servers for Exchange as well as flushdns on Exchange .

I check this, I flushed DNS on Exchange and AD Servers, the issue persist

Is the Exchange in DMZ a CAS only or a complete server? If second, please verify that you have unimpeded communication between it and the DCs:

This Exchange is a complete server, all ports are open between the Exchange and AD servers.

I appreciate your valuable comments

Thanks!

[Vladimir]

Viviana, when you are saying that you've checked the Active Directory Sites, Subnets & Site-Links and that your DMZ subnet is present and properly configured?

See Step-By-Step: Setting Up Active Directory Sites, Subnets & Site-Links – CANITPRO 

When you are using Static Automatic NAT in the Exchange object's properties, please make sure that there are no proxy ARP remnants lurking in the configuration from your manual NAT configs.

Verify that there are no manual NAT rules superseding Automatic NAT rules that could affect traffic TO or FROM exchange in either direction and for any protocol.

Sorry for asking the obvious, but have you tested any other communication from inside to and from Exchange, such as RDP, for instance?

Additionally, what blades do you have enabled on your gateway?

If you have Application Control enabled, you may have to configure explicit rule for communication between Exchange and AD, especially, if you have AppC as the inline Layer with Implicit Cleanup Action Drop.

Do you log everything that you are dropping as well as Implied rules?

if not, you may be missing some clues.

One more thing, and I know it is pretty vague, but what is the situation with IPv6?

Do you have it enabled on Exchange, DCs and on Check Point Gateway?

I believe it must be, for the proper functionality of a good chunk of MS services and is a requirement of MS.

How exactly its behavior changes, if at all, when you are flipping between hide and static of IPv4, I am uncertain, but it may be one more place that you'll have to look at.

[Viviana_Checa]

Hello Vladimir,

Thank you for your answers, I am going to check the points listed on your comments...

[Viviana_Checa]

Vladimir, let me congratulate for be one of the best on Checkmates, and really you are!

The problem was solved!

What was the clue?

 Active Directory Sites, Subnets & Site-Links and that your DMZ subnet is present and properly configured

I have a meeting with people who manage AD servers, and explain this, so, they configured the DMZ Network into Headquarters Site, and that was the solution.

Let me explain how the config works!

1) Rules properly configured on firewall to allow communication between Exchange DMZ and AD servers

2) NAT Manual between Exchange server on DMZ and AD Servers

3) NAT Static for publish the Exchange Server on DMZ

4) Add the DMZ Network into Headquarters site on Active Directory Configuration

The results:

1) All the services in Exchange Server running fine!

2) Publish the owa on Exchange server  DMZ works fine!

Thank you very much for your valuable help!

Greetings

Viviana

[Vladimir]

You are quite w:)lcome!

Glad you have it sorted out.

[ED]

Good suggestions from Vladimir. Sometimes the most obvious can be the solution. We have all been there. 

Take also look at 

Explanation about Client side NAT and Server side NAT

How to Troubleshoot NAT-related Issues

To show proxy arp for manual NAT, run on GW's:

show arp proxy all

[Viviana_Checa]

Thank you Enis for you comments!

The problem was solved!