Technical Tip: ‘Poll Active Directory Server’ as an external connector down over IPsec VPN

[kmohan]

Description	This article describes how to troubleshoot on the FortiGate when the Poll Active Directory Server external connector is down.
Scope	FortiGate, Fabric Connector, Poll Active Directory Server.
Solution	The External Connector is down over the IPsec VPN both ends FortiGate Firewall:  LDAP Server ------ FGT1 ------ IPsec ------ FGT2 ------ Poll Active Directory Server. For self-originating (ping, backup, SNMP) traffic through VPN, when source-ip is not configured, FortiGate will use the IP from the egress interface (interface with the lowest index shown in 'diagnose ip address list'), as described here: Technical Tip: Self-originating traffic over IPSec VPN (For example ping)  Step 1: Verify the LDAP server connectivity, if the LDAP connectivity is reachable, still the external connector is showing down. Step 2: Take the debug log below with a particular destination port or default port 445.   diagnose sniffer packet any " port 445 " 4 0 a  Take the packet capture towards the AD server initiate a connection, and see with which source IP traffic is going out. As this is self-originating traffic, FortiGate will not use the IP of the local LAN that can reach the remote site. Also, it's not possible to set the source IP on the Fabric Connector. Follow the steps below to solve it:  config system interface edit <phase1 interface>  <- IPsec tunnel interface name. set ip <ip address> <subnet mask> <- IP address of the tunnel interface. set remote-ip <ip address> <subnet mask>  <-Remote IP address of the tunnel interface. end The tunnel IP and remote IP must be configured on both sides of the tunnel. Note: The traffic from the configured IP address must be allowed by the phase2 selectors of the tunnel.  The traffic must also be allowed by a firewall policy on the remote FortiGate. To configure phase2 of an IPsec VPN please see the documentation: Phase 2 configuration Afterwards, try to connect the External Connector, it will work. If the issue still persists, follow the troubleshooting steps below on both sides. Take a sniffer on both ends with the default port 445: diagnose sniffer packet any " port 445 " 4 0 a Observe the output of the following debug logs on the remote firewall: diag debug reset  diag debug flow show function-name enable diag debug flow filter dport 445 diag debug flow filter proto 6 diag debug flow trace start 100 diag debug enable Check for any errors like 'Denied by forward policy check (policy 0)'. Make sure to create an address object for each tunnel interface IP and add the address objects to the address groups used in the phase2 connectors of the VPN if those IP addresses are not already added.   Verify the Policy for IPsec tunnel from IPsec to LAN/LAN to IPsec. Check on both the Inbound/Outbound Policy.   Check to see whether the source IP address of the outgoing traffic was added. Once it has been added on the Policy, the external connector will work fine.    For example: the source IP 40.40.40.4 is outgoing traffic, so it was added to the IPsec tunnel policy:       Now, try to connect again from an external connector, and it will work. Related article: Technical Tip: How to set source IP address for FSSO, LDAP and Radius