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?

[pbrown134]

would still be helpful, for internal "documentation" purposes.

[Toshi_Esumi]

what I did was just searching "fortigate as sslvpn client", then found this:
https://community.fortinet.com/t5/Support-Forum/Fortigate-as-SSL-VPN-Client-Reverse-Path-routing-pos...

[PRosenlind]

Now that I think about it, check the NSE4 material. It has a section about Fortigate as an IPsec client and having devices behind it. Maybe there's a good answer in that training.

[pbrown134]

no, ipsec client configs result in normal devices, with normal IP addresses assigned to the virtual device on each side.
VPNSSL is... odd. I dont understand it fully. Hence why i'm here.

[gfleming]

This should have all of the info you need:

https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/508779/fortigate-as-ssl-vpn-...

[pbrown134]

Hi Graham,
unfortunately, that does not help me.
I already have a working sslvpn connection. I was asking about routing to the client.
That doc only addresses routing to the server side.

As I mentioned,

---

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.

---

[gfleming]

As the document states:

"The FortiGate can be configured as an SSL VPN client, using an SSL-VPN Tunnel interface type. When an SSL VPN client connection is established, the client dynamically adds a route to the subnets that are returned by the SSL VPN server. Policies can be defined to allow users that are behind the client to be tunneled through SSL VPN to destinations on the SSL VPN server."

It makes no mention of allowing the reverse traffic initiated from behind the VPN Server to be able to reach endpoints behind the client.

You are free to try manipulating routes and FW policies and seeing if it can work. You are also free to try creating a second SSL VPN connection in the reverse directly to see if that can work for you (doubtful). Unfortunately, if you do get it working I doubt it would be supported by TAC.

at the end of the day the functionality is not meant to work this way.

It's the same as having a home user connect to the VPN using their PC. There's no way to route to that user's home network through the PC. It's not the intended purpose of the SSL VPN Client/Server relationship.

[pbrown134]

---

@gfleming wrote:

....

It makes no mention of allowing the reverse traffic initiated from behind the VPN Server to be able to reach endpoints behind the client.

....

It's the same as having a home user connect to the VPN using their PC. There's no way to route to that user's home network through the PC. It's not the intended purpose of the SSL VPN Client/Server relationship.

---

It doesnt say it cant be done. However, neither does it explicitly say it cannot be done.
But it seems that is the case.

as far as "home user" and dialup VPN...
I've been using dialup VPN for decades
In every situation I've been in up until now, so long as you controlled the machines at both sides of the tunnel, there was a way to do routing back through to the dialup side.
And in fact, Fortinet supports one-way dialup VPN site-to-site routing ALREADY. 
We use it right now, with fortinet-to-fortinet IPsec.

I thought that it would then be logical to presume I could take the same two routers, that are already working in a HUB+dialup VPN configuration using IPsec, and just switch them over to using dialup SSLVPN as the transport.

Silly me for thinking Fortinet would be consistent.

[Toshi_Esumi]

Those IPsec tunnel options are at L3 layer. That's why it works to route subnets through the "node" (not a client). SSL VPN on the other hand works at Application layer. That's not so easy to route L3 protocol through it. For that regards, FortiGate is I think very consistent, or predictable.

If you can find a device that works as you want, please let us know. at least I'm very interested in personally. Most likely that would be a server/VM based software-based FW, not a chassis-based.

Toshi

[pbrown134]

Since you ask: yes I know of at least one solution that works in our exact location and situation:
OpenVPN.
Its mostly thought of as a server-base solution, and its how we will have to use it.
But there are a few routers that can handle being openvpn clients directly.

I was hoping for a solution that could be used directly from our existing fortinet router. Disappointing.

PS: while sslvpn TRANSPORT is at application layer... that doesnt matter.
openvpn uses effectively application layer as well, I think?
But it exposes its vdev interfaces so you can do routing with it and through it.
fortinet does not.
Boo, fortinet.