New Member

Question

FortiGate doesn't see a domain controller over IPSec VPN

Forum|Forum|1 year ago
December 23, 2024
5 replies
3977 views

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.

FortiGate

Renante_Era

Staff

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

Staff

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_24Author

New Member

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.

CleanShot 2024-12-24 at 09.48.27@2x.jpg

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

CleanShot 2024-12-24 at 09.52.52@2x.jpg

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

SuperUser

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_24Author

New Member

Thanks @Toshi_Esumi

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

Toshi_Esumi

SuperUser

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_24Author

New Member

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

CleanShot 2024-12-24 at 11.50.48@2x.jpg

FG_User_24Author

New Member

Just in case someone needs the same in the future.

This is how it was resolved.

edit "DC-IN-AZURE"
set server "10.55.35.4"
set source-ip "192.168.7.5" <== this is what was added in the CLI
set cnid "sAMAccountName"
set dn "dc=company,dc=name"
set type regular

Issue has been resolved.

dingjerry_FTNT

Staff

Hi @FG_User_24 ,

Can you explain what "192.168.1.5" is?

And can you let us know whether you have specific source/destination addresses applied in your VPN firewall policy on FGT and the remote peer?

I guess that you do have specific source/destination addresses in policies on both VPN peers so if you do not specific the source IP in the LDAP server settings, and no IP is assigned to your VPN interfaces, FGT will pick up a random interface IP which is not allowed by the policies.

FG_User_24Author

New Member

Sorry, made a typo.

Not 192.168.1.5 but 192.168.7.5.

192.168.7.5 is an IP address of the interface on the FortiGate.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded