Problem accessing SSL-VPN from one VDOM to another

[mrw]

Hi,

We have a FG1500D that has lots of VDOMs set up for lots of customers. And now we have noticed that if I´m connected to one of these VDOMs I can´t connect to another VDOMs SSL-VPN using FortiClient. It just hangs at around 40% then timeouts. If I put the same computer on a completely external network the same VPN connection works fine.

The VPN connection point to a public ipaddress.

Any idea on what we need to do to fix this? Or atleast how to troubleshoot it?

Thanks in advance,

//Andreas..

[Toshi_Esumi]

You need to explain a little more than just "lots of VDOMs" including the VDOM topology/how they're supposed to be connected each others and where the SSL-VPN client is located/connected to in the topology. I'm assuming there is no connection between customer VDOMs. So you must be connecting to a management vdom or else, which is supposed to have connection to all customer vdoms.

[mrw]

Thanks for your answer.

Ok, to clarify a bit, most VDOMs are completely separate. We have some specific VDOMs that have interVDOM-policys enabled on the same firewall but I don´t think these are involved here.

I am sitting on a customers VDOM(just a laptop on the internal subnet of that VDOM) and tries to access another customers VDOM using the SSL VPN that is set up in that VDOM. That SSL-VPN is used for that customers employees.

Not sure if that explanation helps?

[Toshi_Esumi]

Let's say VDOM A your laptop is in, then VDOM B is the SSL-VPN's destination. Then how VDOM A and B get out to the internet? Via a root vdom or both vdom have separate internet circuit/interface in the VDOMs?

[mrw]

The VDOMs have separate WAN interfaces with their own public ipaddresses. Not sure exactly now if the physical interfaces are separated. I could check that if it would help. We have VLAN tags on the external switches and I'm not sure how everything there is connected.

If I do a tracert from my laptop to the other VDOMs external ip I get 2 hops. First in my local internat GW, then it´s the destinations public ip. So the traffic never leaves the firewall since it knows that the destination is local to the hardware. I suspect this is why I get this problem and not when I´m on another external network.

[Toshi_Esumi]

Since you saw two hops from the laptop both public IPs on both VDOMs must be in the same subnet on the same vlan. But as long as ping/traceroute can get responses, routing/switching shouldn't be the issue. I think you need to run sslvpn application debugging (diag debug app sslvpn -1) while you try from the laptop.

[mrw]

Yes, those two public ips are in the same subnet.

Where do I see those new logs after I activate it using "diag debug app sslvpn -1"?

Advanced diags on a Fortigate is not my strong side.. ;)

[mrw]

Ok, did some googling.

Typed "diagnose debug enable" and then I got some live logs.

So when I tried connecting I got these that are related:

;--

[326:VDOM-845:88d4]allocSSLConn:295 sconn 0x7f8a6a9a9400 (116:VDOM-845) [326:VDOM-845:88d4]SSL state:before SSL initialization (<my src pub ip>) [326:VDOM-845:88d4]SSL state:before SSL initialization (<my src pub ip>) [326:VDOM-845:88d4]got SNI server name: <target pub ip fqdn> realm (null) [326:VDOM-845:88d4]client cert requirement: no [326:VDOM-845:88d4]SSL state:SSLv3/TLS read client hello (<my src pub ip>) [326:VDOM-845:88d4]SSL state:SSLv3/TLS write server hello (<my src pub ip>) [326:VDOM-845:88d4]SSL state:SSLv3/TLS write certificate (<my src pub ip>) [326:VDOM-845:88d4]SSL state:SSLv3/TLS write key exchange (<my src pub ip>) [326:VDOM-845:88d4]SSL state:SSLv3/TLS write server done (<my src pub ip>) [326:VDOM-845:88d4]SSL state:SSLv3/TLS write server done:system lib(<my src pub ip>) [326:VDOM-845:88d4]Timeout for connection 0x7f8a6a9a9400. [326:VDOM-845:88d4]Destroy sconn 0x7f8a6a9a9400, connSize=7. (VDOM-845) ;--

I can´t see anything interesting here except that it does a timeout.

[Toshi_Esumi]

If that's really all you got, the server side doesn't seem to receive anything after the "client hello". I would compare with successful login output when you connect the same laptop from outiside/internet. Whatever the issue is the issue seems to be on the source VDOM side.

[mrw]

Well, when a SSLVPN connection works it just gives a lot more messages and continuing with key exchanges and so on. Nothing there tells me what the problem is.

So I think it is a network issues somewhere. I will test doing this between some other VDOMs to see if this is isolated to one VDOM, several or all. My initial guess is that I need to do something in regarding policys/NATs or something to make it allow when the VDOMs are on the same firewall.