Received bad header from gateway about openfortivpn

[adrienverge]

Hi,

This "magic" header was figured out empirically by studying how the VPN gateway communicates. I have no official specs or docs, so I don't know what 0x686f could be. My guess is that your company uses a different version of Fortinet than mine. It would require a new study...

Happy hacking :)

[jpoet]

For now, I will just have to use the 'official' client, even though I don't like it.
I don't supposed you have notes somewhere describing the process you used to figure this out? I don't mind digging into it, but I don't even know where to start.

Thanks,

John

[ksyz]

Stuck on a same place. But got "ERROR: Received bad header from gateway: 0d0a 0012 5050". There is 0x5050, but it doesn't look like it should be interpreted in that way. But, no idea. Mine, jpoets and yours "header" values look quite distinctive.

[lkundrak]

Fwiw "e2e 686f 7374" is the ASCII "n.host" string. I've fixed an error with HTTP header read buffering in my fork; I'm yet to try it against an actual SSLVPN server instance.

As for @ksyz's packet, "0d0a" is \r\n which is a HTTP header separator; the rest (0012 5050) looks like usual length and magic fields. We probably stopped reading the HTTP header too soon; that might be fixed as well. Will do a pull request shortly.

@jpoet, you may want to install some MITM HTTPS proxy; e.g. Burp. Run it, turn off Proxy->Intercept and set it as --proxy in the official client. You'll be able to see the actual traffic -- see if you see the "**** 5050 ****" response to your sslvpn request and whether you can find the "6e2e 686f 7374"/"n.host" string somewhere.

[jpoet]

Thanks for the tips lkundrak. I will give that a try.

[adrienverge]

First of all, sorry for this late answer.

I found the 0x5050 and the rest by digging around, but maybe other versions of Fortinet VPNs use different magic codes.

@lkundrak, thank you for these precious advices, I'm sure this will help @ksyz and @jpoet solving their issues.

I've modified the code to display more useful information when such error occurs; please recompile openfortivpn at commit 6ea631c!

[lkundrak]

@jpoet: here's the tools I've used in my protocol analysis and testing; you may find them helpful: https://git.gnome.org/browse/network-manager-fortisslvpn/tree/contrib

[lkundrak]

Please take a look at pull request #9, it might fix this. If not, there's a link to the tooling that can obtain useful traces.

[jpoet]

Pull request #9 DOES fix this for me. Thank you lkundrak!

Now I just need to figure out the best way to get this working with a split tunnel. I assume I need to pass "--no-routes --no-dns" and then 'manually' add a route for the subnets behind the VPN.

[lkundrak]

@jpoet yeah. The VPN server exports these in /remote/fortisslvpn or /remote/fortisslvpn_xml resources, but we don't attempt to parse it; it would need some effort (I'm sure the upstream would welcome the patches though).

If you're using the NetworkManager plugin (which is unlikely as I just did a first release a while ago), then you can just add the routes in IPv4->Advanced->Routes (see https://blogs.gnome.org/lkundrak/2015/09/24/fortigate-ssl-vpn-support-added-to-networkmanager/).

[adrienverge]

Thanks @lkundrak!

[pawiecki]

Hello!
After software update of FortiGate, I had similar problem on version 1.0.1, but 1.1.3 fixed this, thanks!