FortiGate doesn't see a domain controller over IPSec VPN

[FG_User_24]

Hi Fortinet Community,

There are two sites (on-prem and Azure) interconnected via IPSec VPN tunnel.

Each site has one domain controller.

Remote users when connect to on-prem get authenticated against the on-prem domain controller.

The future plan is decommission on-prem infrastructure. 

However, when I try to point FortiGate router to the Azure domain controller there is no connection to it.

1) Is it normal that FortiGate router itself doesn't see the other side of the VPN tunnel?

2) Is it possible to make it communicate with resources running on the other side of the VPN tunnel?  

Thanks.

[Renante_Era]

The endpoint should be able to reach the device across the IPsec tunnel as long as you're allowing the source and destination subnet in Phase2.

Try to temporarily disable the software firewall (Windows Firewall, or anti-virus firewall) and see if the remote device is going to reply if you send an icmp echo request.

You could use the following commands on the destination device to confirm if the packet reached there:

di sni pa any 'host w.x.y.z and icmp' 4 0   <-- Press CTRL+C to cancel; where w.x.y.z is the source or destination IP address.

You can also use debug flow to get more details
di de res

di de fl filter cl

di de cons t en

di de fl sh f en

di de fl filter add w.x.y.z

di de fl filter proto 1

di de fl tr start 99

di de en

Then send an icmp echo request (ping) and don't forget to disable debug flow once done: di de res

[dingjerry_FTNT]

Hi @FG_User_24 ,

What is the Azure domain controller IP?  Does it belong to the IPSec VPN phase2 selector settings?  And do you have firewall policy allowing traffic to this Azure domain controller?

Please run the debug flow commands to collect some outputs while reproducing the issue:

diag debug flow show iprope enable

diag debug flow filter addr x.x.x.x  //  This is the Azure domain controller IP

diag debug flow filter port yyy  //  This is optional filter and it is the port listening on the Azure domain controller

diag debug flow trace start 100

diag debug enable

Then reproduce the issue.

[FG_User_24]

Hi All,

I possibly didn't explain my question right.

Right now there are no issues with communication between on-prem to Azure and FortiGate is successfully communicating with the on-prem domain controller. 

However, when I specify the IP address of the domain controller in Azure I get this error. 

It makes me think the FortiGate itself doesn't take part in an IPSec tunnel communication either by design or configuration.

Is that correct?

[Toshi_Esumi]

If you can't ping 10.55.35.4 from the FGT, check the routing table first if there is a route into the tunnel.
If it does have a proper route, must be the source IP for the access, which unlikely in the phase2 network selector.
Sniff the packets when you run the test connectivity and verify what IP it's picking for the source IP. You can change it with:
config user ldap
  edit "server_name"
    set source-ip "one_of_FGT's_interface_IPs"
  next
end
You need to choose an IP, which is in the network selectors.

Toshi

[FG_User_24]

Thanks @Toshi_Esumi 

My understanding is a FortiGate itself cannot be part of the IPSec VPN communication.

[Toshi_Esumi]

In our case, we always set an IP on both sides of the tunnel interface, just like Cisco's "Tunnel" interface. Then we can ping each other over the tunnel after adding it in as a new network selector pair if not 0/0<->0/0.
If you assign the IP on the tunnel interface/phase1-interface, all traffic initiated by the FGT itself picks it as the source IP for LDAP test/queries to the opposite side, as long as it's in the network selectors.
But I didn't assume you assigned an IP on the interface, that's why I suggested specifying "source-ip" in the LDAP config.
Only reason it can't be the part of VPN communication is because you don't include the IP in the network selectors.

Toshi

[FG_User_24]

This is how IPSec VPN tunnel is configured on the FortiGate. 

[Toshi_Esumi]

You're using the default 0/0<->0/0 selector. So you should be able to ping as long as the Azure side has the route for the source IP on the FGT.
Then go back to my original suggestion, sniff the packet to find out the source IP, then check if the Azure side has a route back to that IP.
If not, you need to change the source IP.

Toshi