routing to subnet behind sslvpn client

[pbrown134]

I have a partially working SSLVPN setup between 2 fortinets.
The tunnel itself comes up fine.
What I'd like to be able to do, is route packets from/through the main router, to a subnet that is BEHIND the client.

eg:

desktop -> MainFGT   <-VPNSSL  <- subFGT = officesubnet

and I want "desktop" and "officesubnet" to be able to communicate.

packet capture on MainFGT says that packets for "officesubnet" enter the virtual
SSL-VPN(ssl.root) interface...
but they dont seem to  emerge on the "subFGT" router.

I've tried adding a static route for the subnet to the IP address that subFGT gets assigned for the tunnel..
but the route table always zeros out the Gateway IP to 0.0.0.0
Can anyone help me out with this?

[Toshi_Esumi]

I see. Thanks.

Toshi

[gfleming]

If you've been routing to devices *behind* your SSL VPN clients for decades then fill your boots and use the same mechanism for this scenario. It's not meant nor designed to be used in this way, however.

And just to clarify, dialup IPSec VPN is very different than SSL VPN. So no, you shouldn't expect consistency between the two protocols. IPSec is an open standard protocol that by default allows for bidirectional communication using a virtual network link. SSL VPN is a proprietary protocol that is meant specifically for a client to access resources behind a gatewa, more akin to a reverse proxy.

[pbrown134]

proprietary vs open standard means nothing to the argument.
transport protocol means nothing to the argument.

At some point, the VPN solution has to interface with the kernel, to transfer the encapsulated IP packets into the network stack.
The coder then has a choice to do it in a portable way, such as using a "tun" virtual device, or using sneaky (aka lazy) direct kernel hooks to inject data.
It's clear that currently, fortinet uses the lazy way to implement it.

They COULD do it through more user-manipulatable APIs. They choose not to.
End of story.

[gfleming]

It wasn't an argument. I was just trying to help you understand why there's not full consistency between IPSec and SSL VPN on the Fortigate. The point I was making about it being proprietary was to help you understand that just because OpenVPN does SSL VPN one way doesn't mean everyone's SSL VPN will be the same.

Fortinet designed their SSL VPN protocol in a certain way. You are trying to use it in a way that it's not designed to be used. Fortinet's SSL VPN is basically an SSL reverse proxy. They design it this way so you can connect using a client or through a regular old web page for ease of use and clientless operations. I don't think OpenVPN does this. It doesn't need to so it can behave like a traditional tunnel where connections are multiplexed and encapsulated into a UDP or TCP stream and doesn't need to preserve compatibility with regular old HTTPS protocols.

You can do IPSec, GRE or VXLAN between the FortiGates. If those are all blocked then you have to think outside the box. I could make more suggestions.

[PRosenlind]

This might be a bit of a shady suggestion.. but what if you make a GRE or IPsec tunnel från a local loopback/physical interface of the client fortigate and route it through the SSL VPN tunnel? I guess that could solve your issue.