FortiGate CLI LDAP Test

The Symptoms

A client was having an issue with IPsec VPN connections to their FortiGate. Users were getting non-descriptive error messages and not able to connect. The issue was affecting all users. We couldn’t find anything in the FortiClient or FortiGate logs to indicate what the problem was. As far as we could see, the FortiClient connection was simply timing out.

The FortiGate Web GUI showed us LDAP was working. Looking at packet traces on the FortiGate we could see the IPsec traffic come in, but we weren’t seeing any traffic going back to the source.

The Problem

The Web GUI was lying to us. I believe because caching for LDAP was turned on, but that doesn’t make things better…

When we ran the LDAP test commands from the CLI we finally saw that the FortiGate wasn’t able to talk to the LDAP servers.

The command, by the way, is diagnose test authserver ldap <LDAP Server Name> <username> <password>

The Root Cause

The actual reason that this stopped working was a change we made to the SD-WAN rules on this FortiGate. It was not able to talk to the LDAP server because the traffic wasn’t being routed correctly.
As we’ve been working through SD-WAN deployments we’ve found some quirks to the way the FortiGates handle local-source traffic, by default it doesn’t always behave as you might expect.
The change to the SD-WAN rules meant that LDAP traffic was now trying to go out the wrong interface, because it was no longer matching our defined rules, it was matching the Implicit SD-WAN rule.

The Fix

To fix the actual problem we set the source ip for LDAP to one of the internal IPs, so that it would match the SD-WAN rule that would route the traffic correctly.

config user ldap
set interface-select-method sdwan
set source-ip x.x.x.x
end

I’ve added the interface-select-method option because it is also required, but was already in place for us.