SMB 1400 Mesh VPN and Identity Awareness with ADQuery

[Dylan_Merida]

Hi guys,

I've got a a mesh / site-to-site VPN question with SMB 1400s and Identity Awareness. It may or may not apply to GAIA proper as well. The environment is working currently like this:

1) 9 x SMB 1400s in a mesh VPN community with no NAT inside the community.

2) SMS is R80.10 on a VMWare VM and the SMB 1400s are on the latest R77.20 firmware.

3) VPN Community is set to default encryption for phase 1 and 2 with certificate based authentication.

4) Accept all encrypted traffic is not checked.

5) Permanent tunnels are on with RIM, but I've tried with RIM on and off.

6) The management server is behind one of the gateways at a central building.

7) The gateways' main IPs and objects are configured as their public addresses aside from the gateway local to the mgmt server. The local gateway in layer 2 with the mgmt server has its object configured as the local layer 2 private IP.

😎 The AD servers used in AD Query are at three main building sites that each have an SMB 1400 gateway.

9) Firewall rules are set up to allow all traffic between the internal private IP subnets for each gateway in the VPN community.

10) Manual NAT is set so that private IP to private IP traffic is always original and never translated.

11) All VPN traffic between clients and the VPN subnets is working with no issues. The AD servers are able to communicate with each other directly with no problems.

12) Identity sharing is enabled between the gateways and only the sites with AD servers are sharing.

The issue we're having is that AD query is only working between the local gateway and local AD server at the three main buildings. I'm getting monitor errors every 30 seconds or so one or more AD servers are unreachable. When I investigated with fw monitor and tcpdump, it appears that each gateway is using its public IP address as the source for AD query traffic to tcp/389 and also for log traffic over the VPN. When attempting to ping or telnet directly from the CLI to one of the AD servers or any other host over the VPN, the same is true about the source address.

What we're seeing is that the source address for gateway traffic to a VPN IP is always its public address. This appears to follow convention with the route table. My understanding is that the internal address should present itself over the VPN. Short of a VTI and real routing, is there any way to control this source address for AD query, logs, etc? Should I bite the bullet and try to allow these gateway public addresses over the tunnel and to each private subnet?

Thank you and kind regards!

[Terry_Greensil1]

Did you manage to find a solution to this as we have the same issue.

[Norbert_Bohusch]

Main problem might be that LDAP is part of implied rules and therefore sent in clear and not via VPN.

Check sk26059.

For your request to use internal IP, I see no way to achieve this but also no reason to prefer internal IP over just using the GW objects in rulebase to allow this traffic via VPN.

Edit:

Btw.

It may be even better to use AD query only with local AD where it exists and use identity sharing to get all identities to all gateways

[Dylan_Merida]

Thanks for the replies fellas.

Terry - We haven't resolved it yet, but we have been using identity sharing in the meantime while AD query is still enabled. My plan is to open a CP support ticket to get the best practice configuration and then share back to the thread.

Norbert - This is good incite into where part of the problem lies. I've looked at the implied rules and it's possible the LDAP traffic is caught before encrypt. I know through testing that if I allow any to the DCs for ICMP, the remote gateways can ping directly without any NAT. The private address for the DCs are showing on both sides of the tunnel while sniffing with tcpdump, so I know at least that some of the public addresses for the remote gateways can work over the tunnel for certain services not caught by implied rules. The one issue with using the gateway objects is that three out of my five gateway objects use dynamic IPs and are set up with dynamic IP gateway objects.

I like the idea of disabling AD query. I have identity sharing configured correctly now, but query is still on. I assume I just need to go into the identity sources for each remote gateway object without local AD, uncheck AD Query and push policy, correct?

Thanks!

[Norbert_Bohusch]

Yes, on the gateways where no local AD is attached you can disable AD query and rely only on Sharing.

On all other gateways you have to specify the Domain Controllers which are not local with priority 1001 as described in IA Admin Guide. Here a link to the relevant section (To specify domain controllers for each Security Gateway): Identity Awareness R80.10 Administration Guide 

With this config really only local DCs are queried per gateway!

Btw. as you talk about asking Check Point Support for best practices, what I outlined is documented in Best Practices - Identity Awareness Large Scale Deployment

When an organization consists of multiple geographical sites, it is recommended to configure ADQuery on each site, querying only the site's local Domain Controllers and sharing identities with other sites as necessary (for example, if users from Branch Office "B" need access to resources in Branch Office "A", then Identity Security Gateway "B" should share identities with Identity Security Gateway "A").
Identity Sharing is configured via the 'Get identities from other gateways' option in Security Gateway properties - 'Identity Awareness' pane. 

[Terry_Greensil1]

The problem we have is we have a global network and small sites authenticate to an AD server in AWS where there is currently no Check Point Gateway so we cant use identity sharing from that site. So logins for the sites in question would not be seen from our main site where we do have a gateway and AD.

[Maarten_Sjouw]

for each gateway create 2 host objects, one with the external and one with the internal IP and create a NAT rule for traffic headed for the AD server using these objects, do not use the Gateway object as this will not work most of the times.