IPv6 on SSL client tunnel

[kotheram]

Hi,

I am having trouble setting up IPv6 on Windows 10 SSL tunnel with FortiClient VPN app.

I have configured IPv6 address group to be assigned to users, enabled IPv6 on SSL-VPN portal, checked that IPv6 is enabled on Windows PPP interface, ... but my computer still get only IPv4 address.

Have anybody successfuly configured and used IPv6 on SSL VPN through Forticlient VPN app?

So far I have found this post http://socpuppet.blogspot.com/2013/09/sslvpn-forticlient-ipv6.html which has not been resolved and some known issues with IPv6 on full Forticlient https://docs.fortinet.com/document/forticlient/6.2.0/windows-release-notes/991883/known-issues.

Thanks

[ispcolohost]

Any chance you figured this out?  Trying to do dual stack with 6in4 via Forticlient.

[kotheram]

Actualy a I opened a support ticket a day ago.

I will post resolution here as soon as I have one.

[ispcolohost]

I had one, they're suggesting what I'm attempting to do is not something you can achieve with both 1) an external user, and 2) lack of EMS license.  This instance has users are defined on the fortigate but auth'd via radius, and I'm just attempting with standard 6.0 or 6.2 client unlicensed, i.e. vpn-only.  I of course can't find any docs on Fortinet's site that confirm or deny this suggestion; they have nothing on their site about setting up dual stack Forticlient, or anything that suggests it is actually capable of 6in4 tunnels.  I can get either a v6 or a v4 address depending on which protocol I connect over, but then the other protocol is free to split tunnel even though I have those options disabled in my SSL VPN definition.  Kind of a mess.

[kallbrandt]

SSLVPN is to my knowledge still EITHER IPV4 or IPv6. I have never heard of anyone succeding in having dual stack in SSLVPN, and support know this is kinda embarrassing and doesn't really answer your questions...

However, it is perfectly possible to use IPSEC VPN with Forticlient and run dual stack.

[ispcolohost]

Hmm that's unfortunate.  Ipsec is a bit too cumbersome for mass rollout and support for non-technical users; I've got that setup currently using pfsense+openvpn auth'ing off a radius server hooked into Duo for MFA and policy enforcement.  Very clean, no users on the firewall, one stop shop for locking someone out companywide.  Just doesn't have the performance of fortigate vpn, HA, etc. and is of course one more thing to support.

[kallbrandt]

I don't understand why IPSec would be cumbersome - It is more to setup in the firewall obviously, but the same for the users, unless you go with fully manual setup on the client side. That doesn't scale even for SSLVPN, and would be impossible with IPsec VPN due to the plethora of settings that need to match on both ends. I bake the FortiClient msi/exe with the build tool so that all settings are included. It is then easy to push out with AD policies or your package deployment tool of choice. Or just offer the baked client for downloading in the VPN-portal/elsewhere. All the users have to do is to type their credentials correctly (hard enough...).

[ispcolohost]

I was just thinking from the perspective of either certificate management and/or not wanting a common pre-shared key.  We have a lot of BYOD among our users, and ssl-based with radius auth makes it quite easy for them to self configure on any device type of their choosing by just knowing the target.  The auth and 2fa work the same regardless of device type and they don't require possession of, or knowledge of, anything beyond their normal credentials.  If they lose a device or they quit/term, we only have one change to make and they're out of every system.

[kallbrandt]

SSLVPN will always be easier, both to set up and to manage. It sucks that they haven't fixed the dual stack issue, since the competition (Palo Alto, Cisco and others) can run dual stack SSLVPN without any problems. But for the time being, the only solution with a Fortigate is to go IPSec. And a commonly known, hardcoded PSK in the client isn't that big of a deal, since you would use XAUTH + 2FA in addition to the PSK if you go with the free FortiClient IPSec (IKE1 only). Basically, the PSK is just there in the client because it has to be (in our case, we chose not to use certificates, just because we have non-internal devices too). We use a PrivacyIdea radius server for handling the 2FA (+ any TOTP app of your choice), wich in our case is a 6-digit TOTP code that the users append after their password. Same solution för SSLVPN as for the IPSec. Actually for everything that utilize 2FA. It works and scales well, and since the FortiClient is pre-baked with all the settings, there really is no difference between SSLVPN/IPsec in the handling from the users perspective.

There seems to be a bug in 6.0.9 regarding SSLVPN also. Some models (like 600D) seems to suffer from severe packet loss, making for example RDP almost impossible. So we had to deploy both SSLVPN and IPsec as backup way in. IPsec is rock solid. Dual stack is basically just icing on the cake mostly for the IT staff, since they had to go IPsec anyway...

[kotheram]

Support ticket resolution:

>>>

This configuration is currently not supported by either the firewall or FortiClient. They 've been already NFR's regarding this feature but still is not available. 0251189 NFR - Dual stack IPv4/IPv6 over Forticlient access IPSec and SSL VPN 0266721 Forticlient Support for simultaneous IPv4 and IPv6 address assignment over IPSec and SSL tunnel Please feel free to talk with your sales representative about NFR. All NFR(new feature request) or development roadmap cases have to be worked through Fortinet regional sales partner channel or the Systems Engineer (SE) that covers your territory.

<<<

So, guys, please, contact your partners and ask them to escalate those NFRs.

Right now, you can use IPv6 tunnel over IPv6 connectivity and IPv4 tunnel over IPv4 connectivity.