Closed jpoet closed 8 years ago
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 :)
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
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.
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.
Thanks for the tips lkundrak. I will give that a try.
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!
@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
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.
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.
@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/).
Thanks @lkundrak!
Hello! After software update of FortiGate, I had similar problem on version 1.0.1, but 1.1.3 fixed this, thanks!
Hi,
When I try openfortivpn against my companies new VPN, I get: ERROR: Received bad header from gateway: 6e2e 686f 7374
Looking at the code, it looks like I am getting a magic of 0x686f instead of 0x5050. Can I ask how you determined that it should be 0x5050 and how you figured out that total=size+6?
Thanks,
John