Technical Tip: Configuring Agentless FSSO Polling via IPsec VPN tunnel

ESCHAN_FTNT · ‎06-21-2018

Description
This article describes how to configure Agentless FSSO Polling via IPsec VPN tunnel between two FortiGates.

Scope

Refering to the network diagram above, AD server is only reachable by FGT-A by IPsec VPN tunnel to FGT-B. By using FSSO Agent, we can specify the source IP to reach FGT-B. However, there is no such option in Agentless FSSO polling.

LDAP is configured to specify source IP, but performing sniffer on FGT-A with port 445 reveals it was being sent out using another source IP:

config user ldap
    edit "AD"
        set server "10.125.1.11"
        set source-ip 10.149.1.21
        set cnid "sAMAccountName"
        set dn "dc=ces,dc=com"
        set type regular
        set username "cn=Administrator,cn=Users,dc=ces,dc=com"
    next
end

FGT-A # diagnose sniffer packet any 'port 445' 4
interfaces=[any]
filters=[port 445]
0.624513 VPN-AtoB out 2.2.2.2.11209 -> 10.125.1.11.445: syn 2524384594
4.636167 VPN-AtoB out 2.2.2.2.11209 -> 10.125.1.11.445: syn 2524384594
25.233656 VPN-AtoB out 2.2.2.2.11211 -> 10.125.1.11.445: syn 2949233177
26.224879 VPN-AtoB out 2.2.2.2.11211 -> 10.125.1.11.445: syn 2949233177
2.2.2.2 is the public IP of FGT-A and it is not supposed to be traversing through the IPsec VPN tunnel VPN-AtoB, thus traffic will be dropped by remote FGT.

Solution
By configuring IP address on the IPsec VPN tunnel, we can force the FSSO traffic to use the VPN tunnel IP address instead of the lowest index IP address as source IP.

config system interface
    edit "FGT-KVM36"
        set vdom "root"
        set ip 172.16.1.2 255.255.255.255
        set type tunnel
        set remote-ip 172.16.1.1 255.255.255.252
        set snmp-index 12
        set interface "port1"
    next
end

FGT-A # diagnose sniffer packet any 'port 445' 4
interfaces=[any]
filters=[port 445]
7.309059 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: syn 751818537
7.310877 VPN-AtoB in 10.125.1.11.445 -> 172.16.1.2.21873: syn 1602721448 ack 751818538
7.310938 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: ack 1602721449
7.327293 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: psh 751818538 ack 1602721449
7.328787 VPN-AtoB in 10.125.1.11.445 -> 172.16.1.2.21873: psh 1602721449 ack 751818732
7.328816 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: ack 1602721658
7.329148 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: psh 751818732 ack 1602721658
7.330492 VPN-AtoB in 10.125.1.11.445 -> 172.16.1.2.21873: psh 1602721658 ack 751818902
7.330673 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: psh 751818902 ack 1602722080
FGT-A is now using the VPN interface IP 172.16.1.2 to send the FSSO packet. On remote FGT-B, the route 172.16.1.2 is now a directly connected route via IPsec VPN tunnel VPN-BtoA, therefore it knows how to route the traffic back to FGT-A.

FGTB # get router info routing-table all

Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

S*      0.0.0.0/0 [10/0] via 2.2.2.254, port1
C       10.47.0.0/22 is directly connected, port1
S       10.125.0.0/23 [10/0] via 172.16.1.1, VPN-BtoA
C       10.149.0.0/23 is directly connected, port2
C       172.16.1.0/30 is directly connected, VPN-BtoA
C       172.16.1.2/32 is directly connected, VPN-BtoA
Hence the agentless FSSO polling is now working as expected:

FGT-A # diagnose debug fsso-polling detail 1
AD Server Status(connected):
ID=1, name(10.125.1.11),ip=10.125.1.11,source(security),users(0)
port=auto username=Administrator
read log eof=1, latest logon timestamp: Sun May 27 16:41:54 2018

polling frequency: every 10 second(s) success(508), fail(0)
LDAP query: success(0), fail(0)
LDAP max group query period(seconds): 0
LDAP status: connected

Related Articles

Technical Note: Self-originating traffic over IPSec VPN (For example ping)

Technical Note: tracert/traceroute behavior over IPsec VPN tunnel