PDA

View Full Version : Using Identity Awareness with NAT between CMA & Domain Controllers



northlandboy
2015-03-12, 17:27
Has anyone tried using Identity Awareness in an environment where you need to use NAT between the CMA + Management Clients and the Domain Controllers?

In this case, the firewalls themselves can connect directly to the Domain Controllers, with no NAT. That's not a problem. But the CMA needs to connect to the Domain Controller for initial setup, and the Managment Client workstation needs to connect to the Domain Controller.

The CMAs and the firewalls have public IP addresses, so normal management is not a problem. But I can't directly route between the CMAs and the privately addressed Domain Controllers. In an MSP environment, there's too much overlapping address space between various customers' use of RFC1918 space.

Anyone else in this situation? I haven't yet found any docs that talk about how to handle this, or if it even can work.

msjouw
2015-03-12, 18:57
For this issue we use a VS on our VSX system with VPN's to the customers Gateways, on the VS only the remote AD servers are part of the VPN domain and we only have with host routes for these servers on our Management network pointing to the VS.

Having said that, the only other way I know to do this would be to use NAT on one of the customer's gateway into their network to One AD server. You can try inbound-only Manual NAT (as the AD server definition) or try Automatic NAT.

So you have your management network, with the destination address from the NAT pool of the customer's GW, this NATs on their GW to one specific AD server, now just add all other AD servers, (you only need to be able to access 1) your gateways will be able to connect to the normal IP servers, just set the other GW's directory access Priority to the NATted AD server lower and set the NATted AD server as your primary management connection server.

When you make sure the NAT is set to be handled by the one gateway, that gives you the access, this should do fine for that GW to access that server, using NAT as well from that GW.

northlandboy
2015-03-12, 19:34
Thanks a lot Maarten.

Check Point support has said I can use NAT, but I don't think they've fully thought through the implications. The bit I've been worried about is that the gateways will try and connect to the NAT IP.

What you're suggesting, re: changing the priorities makes sense. As long as it's mainly only that gateway that does the NAT that uses the NAT IP, it should be OK. I think I can make it work through some routing trickery, even if the other gateways do decide to query the NAT IP.

pat13b
2015-03-16, 13:44
Thanks a lot Maarten.

Check Point support has said I can use NAT, but I don't think they've fully thought through the implications. The bit I've been worried about is that the gateways will try and connect to the NAT IP.

What you're suggesting, re: changing the priorities makes sense. As long as it's mainly only that gateway that does the NAT that uses the NAT IP, it should be OK. I think I can make it work through some routing trickery, even if the other gateways do decide to query the NAT IP.


We were not successfull in getting this to work. It's buried in the pdf that IA AD query does not work with NAT. So we moved one of AD servers into a DMZ off the Check Point without NAT.
The gatweways will see the DCs through NAT though. It was just the AD query piece that was not working for us.

-pat13b

northlandboy
2015-03-16, 19:45
It's buried in the pdf that IA AD query does not work with NAT. .

-pat13b

The only references I could find to NAT in the PDF were in relation to NAT between the clients & the gateways (because then the AD-logged IP didn't match up with what the gateway sees). I couldn't find anything related to NAT between the mgmt server/mgmt clients & the DC.

Support has told us that it should work, in a similar setup to what Maarten described above. Going to need some testing though. I don't want to end up in the position where it works, but later breaks, and then Check Point says "oh yeah, that's not supported"

mcnallym
2015-03-17, 08:57
For this issue we use a VS on our VSX system with VPN's to the customers Gateways, on the VS only the remote AD servers are part of the VPN domain and we only have with host routes for these servers on our Management network pointing to the VS.

Having said that, the only other way I know to do this would be to use NAT on one of the customer's gateway into their network to One AD server. You can try inbound-only Manual NAT (as the AD server definition) or try Automatic NAT.

So you have your management network, with the destination address from the NAT pool of the customer's GW, this NATs on their GW to one specific AD server, now just add all other AD servers, (you only need to be able to access 1) your gateways will be able to connect to the normal IP servers, just set the other GW's directory access Priority to the NATted AD server lower and set the NATted AD server as your primary management connection server.

When you make sure the NAT is set to be handled by the one gateway, that gives you the access, this should do fine for that GW to access that server, using NAT as well from that GW.

We took this one stage further and used the Advanced Routing in a VR to do Source and Destination combination routing. Then deploy VDI for the Desktops.

Use 1 VDI per VS.
Use DNS as in

customer1vdi.x.y
customer2vdi.xy

etc so that for each customer get to the correct VDI for the customer and thus don't have to worry about NAT as long as you have customers where the AD Servers overlap on different VDI and VS when connected. Gateways see the AD Server by the correct IP and as can do the routing to include the VDI for the Customer then no need to worry about using NAT for when connecting from the Dashboard machine.

northlandboy
2015-04-12, 22:00
Coming back around to this, I've had a chance to implement my strategy for NAT with Identity Awareness.

Here's what I did:


Created a NAT rule + object to NAT from a public IP to the private IP of one of the DCs
Created a rule allowing access from CMA + Mgmt Clients through to that NAT IP
Added a new LDAP Account Unit. Add server, with host set to the NAT IP. Set default priority to 100. (Can't choose >1000 at this step).
Add more servers for each of the real IPs. Set their default priority to 5.
On the LDAP AU Objects Management tab, manage objects using the NAT object
On the gateway object, Other -> User Directory, select "Selected Account Units list". Add all Account Units, and change the default priorities. Set the NAT object to 1001. All the others can be 5. >1000 means it will be ignored.
Install policy. The firewall will now query the real IPs, and ignore the NAT IP. (Can be seen with "adlog a dc"). But when you're adding new Access Roles, SmartDashboard will connect to the NAT IP.



So far this seems to be working OK.

jflemingeds
2015-04-13, 09:48
Coming back around to this, I've had a chance to implement my strategy for NAT with Identity Awareness.

Here's what I did:


Created a NAT rule + object to NAT from a public IP to the private IP of one of the DCs
Created a rule allowing access from CMA + Mgmt Clients through to that NAT IP
Added a new LDAP Account Unit. Add server, with host set to the NAT IP. Set default priority to 100. (Can't choose >1000 at this step).
Add more servers for each of the real IPs. Set their default priority to 5.
On the LDAP AU Objects Management tab, manage objects using the NAT object
On the gateway object, Other -> User Directory, select "Selected Account Units list". Add all Account Units, and change the default priorities. Set the NAT object to 1001. All the others can be 5. >1000 means it will be ignored.
Install policy. The firewall will now query the real IPs, and ignore the NAT IP. (Can be seen with "adlog a dc"). But when you're adding new Access Roles, SmartDashboard will connect to the NAT IP.



So far this seems to be working OK.

This is a really great post, thanks for the follow up.

northlandboy
2015-05-21, 02:07
I've written some of this up in a bit more detail on my blog (http://lkhill.com/using-check-point-identity-awareness-with-nat/).

Ugly diagrams, but you get the idea.