SSLVPN traffic over IPsec tunnel

[mdh685]

We are new to the Fortigate world and have two facilities, HQ and Branch. We have successfully configured an IPsec tunnel between the two facilities. At each facility we have also configured SSLVPN connections for our remote workers. The problem we cannot seem to get worked out is allowing HQ SSLVPN users to access Branch resources across the IPsec tunnel.

HQ LAN: 10.10.10.0/24

HQ SSLVPN: 172.1.1.0/24

Branch LAN: 10.60.60.0/24

Branch SSLVPN: 172.2.2.0/24

We've been referring to this article: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Forward-traffic-originating-from-SSLVPN-in...

Unfortunately we are not strong with reading the command line configuration to understand all of the details of that post. We have not been able to find much documentation on setting up a connection like we want to. Are there resources available that would assist with this configuration? What are the best troubleshooting options to tell where the

[ede_pfau]

Your post's title is a bit misleading but your task is not too complicated, fortunately.

Just regard your SSLVPN subnet as a regular, additional subnet. An IPsec VPN tunnel can carry an unlimited number of subnets. In order to get from one subnet in HQ to another one in Branch, you need to

1- allow this subnet in both phase2 selectors in the IPsec VPN setups (both sites)

2- allow this subnet in at least one outbound (at HQ) and one inbound (in Branch) policy

3- create a route back to where this subnet originates (HQ subnet -> one additonal route in Branch)

- to make life easier, for pt. 1 you can use a wildcard address '0.0.0.0/0' with Fortigates, so you will not create one phase2 selector for each subnet. Any subnet will match the wildcard.

That's all, and it's no different from how you would transport any other ('regular') subnet between sites. Just forget about that the users on the SSLVPN subnet are remote.

[mdh685]

Thank you for your help.It certainly makes sense, and we originally forgot to add the route back to HQ from Branch. However, once we added that it still doesn't work.

Here is what we've done:

1: Added the SSLVPN subnet to the phase2 selectors for the IPset tunnel

2: Set the 3 policies up as shown here: https://imgur.com/a/K3dbN0V

Something still seems to not be correct. Does anything stand out in the policies?

[Debbie_FTNT]

Hey mdh,

you might need a policy on the branch FGT, from IPSec to SSLVPN.

From the current setup you mentioned, provided all routing is in place, I would expect SSLVPN users can ping the internal servers behind HQ FortiGate.
Perhaps you can do a traceroute from command line on an SSLVPN client to see what hops the traffic takes?
'tracert <internal server IP>'

-> run that in Command Line (Win+R, type 'cmd')

That should give you an idea if the traffic hits Branch/HQ FortiGate and where it might go wrong.

Also, if your SSLVPN has split tunneling - add the internal servers to the split-tunneling routes on Branch HQ :)

[ede_pfau]

As Debbie_FTNT just stated, you always need an even number of policies in this scenario. So, IPsec tunnels to SSLVPN policy is missing.

And routing needs to be consistent all across all networks - so your end user needs to have a route to the branch subnet, in addition to the subnets in HQ. There is only one case where you won't need to change anything in the FClient, that is if you route ALL traffic from enduser to HQ (via default route 0.0.0.0/0). If not, you use "split tunneling", and that's where you need to add the branch subnet. Again, Debbie mentioned all of that already.