- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Unable to connect to the account unit LDAP servers...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unable to connect to the account unit LDAP servers behind the IPSec tunnel
Hello,
I have problem accessing the LDAP account unit servers of the external company that is behind the IPSec tunnel.
This is my topology:
mgmt --> DCGW --> PerimGW ---IPsec--> Fortinet --> ExtLDAPs
|
IntLDAPs
- mgmt: Check Point SMS server, R81.20 JHFA Take 53
- DCGW: Check Point DataCenter gateway. Active-Standby cluster. R81.20 JHFA Take 53. Active Identity Awareness (both PDP and PEP). Open servers.
- PerimGW: Check Point perimeter gateway. Active-Standby cluster. R81.20 JHFA Take 53. Active Identity Awareness (both PDP and PEP). Open servers.
- IntLDAPs: Internal Active Directory servers used in 1st LDAP account unit
- IPsec: domain based tunnel, NAT disabled inside the VPN community. IPsec works without any problems; a lot of communication in both directions.
- Fortinet: VPN gateway of the external company
- ExtLDAPs: Active Directory servers of the external company used in 2nd LDAP account unit
From two account units only the 1st one works as expected. Regarding the 2nd one which doesn't work at all I observe the following (strange) behavior:
- When port 389 is used in LDAP account unit definition, it is not possible to make TCP connection to ExtLDAPs because TCP SYN packet is not sent by PerimGW to the IPSec tunnel (instead it is NATed by PerimGW to the public VIP address). Making the TCP connection to the port 636 (nc -v server 636) works without any problem (goes to the IPSec tunnel).
- When port 636 is used in LDAP account unit definition, it is not possible to make TCP connection to ExtLDAPs because TCP SYN packet is not sent by PerimGW to the IPSec tunnel (instead it is NATed by PerimGW to the public VIP address). Making the TCP connection to the port 389 (nc -v server 389) works without any problem.
- When I remove one of the LDAP servers from LDAP account unit definition, both 389 and 636 ports of the not-used server can be accessed by running the "nc -v server port" command.
- When communication is NATed, no logs can be seen in SmartConsole. When communication goes to the IPSec tunnel, logs are there. Turning on implied rules logging doesn't change anything.
Why my perimeter gateway does NAT instead of sendnig the communication to the IPsec tunnel?
What can I do in order to change this behavior?
- Labels:
-
Identity Awareness
-
NAT
-
Site to Site VPN
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The outbound LDAP connects from the gateway to the Account Unit LDAP Server are handled by the implied rules by default.
The implicit rule takes effect before the access policy. Therefore, no logs are written and the VPN domains are not applied.
The implied rule does not apply to ports or servers that are not configured in the account unit. The explicit rules take effect and logging / VPN routing is applied.
You can deactivate the implied rule by commenting out the following line in the $FWDIR/lib/implied_rules.def file on the management server.
#define ENABLE_LDAP_SERVER
Please note that explicit rules must then exist for both the internal and external account units.
Oliver
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The outbound LDAP connects from the gateway to the Account Unit LDAP Server are handled by the implied rules by default.
The implicit rule takes effect before the access policy. Therefore, no logs are written and the VPN domains are not applied.
The implied rule does not apply to ports or servers that are not configured in the account unit. The explicit rules take effect and logging / VPN routing is applied.
You can deactivate the implied rule by commenting out the following line in the $FWDIR/lib/implied_rules.def file on the management server.
#define ENABLE_LDAP_SERVER
Please note that explicit rules must then exist for both the internal and external account units.
Oliver
