Hi all
Maybe you can give me a hint with the following situation:
We've setup an IPSec S2S connnection from our local FortiGate to Azure (virtual gateway, not a full FortiGate Virtual Appliance), following the cookbook: https://docs.fortinet.com/document/fortigate/5.4.0/cookbook/587640
This worked like a charm so far, great :)
Now I tried to add the ability to dial into our local network via the existing SSL-VPN connection (FortiClient) and then access the ressources on the remote side of the IPSec tunnel.
I tried this cookbook as references, but as it's not Fortigate-to-Fortigate, the Wizard won't provide the same settings: https://cookbook.fortinet.com/ssl-vpn-to-ipsec-vpn-56/index.html
Basically it's not working, I can't ping an Azure ressource via SSL-VPN remotely, while I can ping it from our local network.
I have checked:
1. Additional policies for SSL-VPN --> IPSec tunnel and back 2. A static route that routes everything for the Azure subnet range down the IPSec tunnel 3. In the SSL-VPN Portal Split Tunneling settings, the Azure subnet range is in the "Routing Address" table, together with the local address range 4. In the IPSec VPN tunnel I changed the "Phase 2 Selectors" from 0.0.0.0 - 0.0.0.0 to two new selectors: "Local to Azure" and "SSLVPN to Azure". Both selectors show Status "Up".
I don't really have a clue about phase 2 selectors though.. I tried to deduce this from the second cookbook, where the wizard was used - so I assume I might have gotten something wrong there? I'm not all certain about the various Encryption/Authentication pairs and the other settings there.
Any help or hints would be appreciated!
Thank you guys & stay safe
Solved! Go to Solution.
Have you added the subnet of the SSLVPN to the Azure local gateway so it negociates it in ipsec tunnel?
Everything else sounds correct based on what you listed. You really only need 3 things to make this happen:
1. Routing - Sounds like this is setup properly by adding the Azure subnet to the client routes
2. IPV4 Policy - Sounds like this is setup properly based on you saying you created SSL > Ipsec and reverse rules
3. Phase 2 - It sounds like the fortigate side is setup properly, but you don't mention adding SSL VPN subnet to Azure side
You need policy and phase2 for the SSLvpn client ranges
diag debug flow # is your friend
on phase2 look for the src subnet in the vpn tunnel details
e.g
diag vpn tunnel list name <azure-tunnel-ph1-name> | grep -i 'src:\|dst:'
if the SSLVPN does not match the proxy-id you need to get that sorted out 1st.
Ken Felix
PCNSE
NSE
StrongSwan
Have you added the subnet of the SSLVPN to the Azure local gateway so it negociates it in ipsec tunnel?
Everything else sounds correct based on what you listed. You really only need 3 things to make this happen:
1. Routing - Sounds like this is setup properly by adding the Azure subnet to the client routes
2. IPV4 Policy - Sounds like this is setup properly based on you saying you created SSL > Ipsec and reverse rules
3. Phase 2 - It sounds like the fortigate side is setup properly, but you don't mention adding SSL VPN subnet to Azure side
You need policy and phase2 for the SSLvpn client ranges
diag debug flow # is your friend
on phase2 look for the src subnet in the vpn tunnel details
e.g
diag vpn tunnel list name <azure-tunnel-ph1-name> | grep -i 'src:\|dst:'
if the SSLVPN does not match the proxy-id you need to get that sorted out 1st.
Ken Felix
PCNSE
NSE
StrongSwan
Hi Brycemd
That actually did the trick. I didn't think about the Azure side also needing to know about the second "local" subnet.
Thank you very much for your swift help!
User | Count |
---|---|
2087 | |
1181 | |
770 | |
451 | |
344 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.