Can not connect using FortiToken about openfortivpn

[dsgwork]

Hi @patrickhanft

I wrote the patch to add two-factor support to the client, so I think I can give you some more information. As far as I know, there is no documentation for the protocol used by the FortiVPN. The two-factor support I wrote was simply done by some simple reverse-engineering of the protocol. Unfortunately, I can only test things as my company has them set up, and we don't use the tokens (our setup has the OTP generated by the FortiGate, which then sends an email which gets converted to an SMS), so the tokens have never been tested (but based on what you say, they probably do not work).

Based on my experience, I expect adding support for the tokens would be quite an easy job, but still needs a VPN account associated with a token for testing. Most likely it's only needed to figure out how the initial login_check response differs from the normal one (to check if we need to do token auth) and in which parameter to the second login_check call we should stuff the OTP code.

If anyone wants to give this a go, the way I used to reverse the protocol was to just set up a stunnel that listens locally, with a self-created key+cert, and then makes an SSL connection to the actual VPN host/port. Then set up a tcpdump on the local port, make a successful connection to it with the official fortinet client and disconnect immediately. Then you can configure wireshark with the self-generated key to decrypt the communications, open the capture file and see what parameters are being sent over the wire.

[patrickhanft]

Hi @dsgwork

Thanks for your comment!

I tried to do a setup to intercept my communication with the fortigate. In the hope that you or anyone else might be able to draw the right conclusions from this, I have two logs created with stunnel and socat.

• First try with openfortivpn which failed
• Second try with fortinets own client which was successful using 6-digit OTP 330230.

Hopefully I did not expose too much here ;-), while being informative enough to someone willing to integrate support for this?

At least I would be very happy, if someone likes to add support!

[dsgwork]

Hi @patrickhanft

Thanks for the trace info. If I'm reading it right, it should be even easier than I though to add support. The two-factor negotiation happens exactly the same with the tokens, it's just that the tokeninfo= parameter does not contain anything, and the code assumes that's invalid.

Can you please apply this patch and try again:
https://gist.github.com/dsgwork/d24cbd2ae22f7ded4554

I suspect that's all it takes. The check for empty tokeninfo doesn't really serve any purpose here, we already handle the case where ret != 1 which should handle all failures.

If this works for you, I will submit it as a pull request, as I've verified it has no effect on the VPNs I have access to (with or without two-factor).

-Davíð

[patrickhanft]

It probably took me longer to apply your patch (it somehow got rejected, but that's probably my fault, I did it manually then), than it did you to write it. ;-)

Still fantastic! 👍

patrick@patrick-x240 ~ % sudo openfortivpn 
VPN account password: 
INFO:   Connected to gateway.
2factor authentication token: 
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
INFO:   Got addresses: [172.25.49.32], ns [172.25.0.11, 172.25.0.11]
INFO:   Interface ppp0 is UP.
INFO:   Setting new routes...
INFO:   Adding VPN nameservers...
INFO:   Tunnel is up and running.

Thank you very much!

[adrienverge]

@dsgwork Thanks for being active here, I couldn't have written a better answer.

Pull requests will be most welcome!

[patrickhanft]

@adrienverge well, from my POV we could consider this closed, but I don't know if you want to close this only after you tagged a future release? So, do as you prefer.

Thanks again and BR!

[adrienverge]

I consider this solved. :-)

Thanks to both of you for bringing this enhancement.