Visitor III

Question

routing to subnet behind sslvpn client

Forum|Forum|3 years ago
May 3, 2023
6 replies
11301 views

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?

FortiGate

PRosenlind

Explorer III

I guess a simple solution would be to change VPN type to a classic Site-to-site tunnel, but I assume that's not possible in your case?

pbrown134Author

Visitor III

exactly. ipsec is blocked, we have to use sslvpn

msanjaypadma

Staff

Hi @pbrown134 ,

Are you using FortiGate as SSLVPN client, if yes , can you just check and confirm did you configured as below article?
https://docs.fortinet.com/document/fortigate/7.0.0/new-features/508779/fortigate-as-ssl-vpn-client

If this is not the case, can you share relevant routing logs and sniffer and debug flow logs?

Thanks, Mayur Padma

pbrown134Author

Visitor III

routing.. "logs"?

Toshi_Esumi

SuperUser

I remember we had the same conversation a month or two before. It's not designed to do routing through without NAT. That's why it's NATed in the policy.

If IPsec is blocked you might want to try IPsec over GRE. It might not look inside of the GRE tunnel to block it.

Toshi

pbrown134Author

Visitor III

Trying to do business through UAE.
They look for anything that looks like vpn traffic and block it.
So, it HAS to be sslvpn

PRosenlind

Explorer III

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.

pbrown134Author

Visitor III

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

Staff

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-client

pbrown134Author

Visitor III

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

Staff

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.

PRosenlind

Explorer III

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.

Sign up

Login with SSO

Login to the community

Login with SSO