-
Notifications
You must be signed in to change notification settings - Fork 327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not connecting over some internet connections Ubuntu 19.04 & 20.04 #764
Comments
I suspect this a malfunction of the satellite connection, have a look at the path MTU using |
See also: |
The path MTU is 1500 for the satellite connection and 1430 for the tethered connection. The satellite connection works to establish the VPN if I boot up windows and use Windows FortiClient 6.0.4.0182, so there has to be something else going on as well. |
The Windows FortiClient might be using VPN IPSec instead of VPN SSL. You'd have to make sure you're using VPN SSL when testing on Windows. Can you show the output of
|
I believe you are right that my Windows client is using IPSec, I remember seeing that somewhere. Thank you for helping with this, by the way. Here are the results of using
and for the cell phone network:
The first time I try the slightly too large, I see a response as follows: |
Maybe the issue is from the high latency? Also, when I connect using the network manager interface (kde), it fails immediately after I complete the two-factor authentication, but from the command line, it eventually just times out. Here's the relevant network manager log for a working connection (cell phone):
and here's the log from trying and failing (satellite):
in case that information may be helpful somehow. I'm using version 1.12.0 |
Indeed it's nor an MTU issue as far as I can see. Perhaps a latency issue as you say. That's the main characteristic of a satellite connection, especially if the satellite is geostationary - which is the case for HughesNet. |
Can you try VPN SSL from WIndows with FortiClient? It would be great if we could compare openfortivpn and FortiClient and find whether they differ or not. Perhaps there's a time out on the VPN gateway that needs to be modified (for VPN SSL only). |
I can confirm that the VPN SSL from Windows with FortiClient successfully establishes a VPN. |
Here are some relevant lines from a logfile using FortiClient, representing a successful connection and disconnection to an SSL VPN:
I don't see anything here that looks useful, but I'm just a user |
I really don't know. Hard to tell anything useful without debugging the connection myself. There's one thing of interest though:
Almost 3 minutes between Then there might be a timeout in the underlying TCP stack that could be modified by a system-level option. Anything useful in the system log while openfortivpn waits for this apparent timeout? Could you get access to a recent FortiClient for Linux with VPN support? The one freely available on internet does not support VPN. It would be great if you could find whether the FortiClient VPN SSL client is able to connect to the same VPN gateway from the same Linux machine - or not. |
The connection takes 20 seconds to be fully established on windows, but the log doesn't get updated until the session disconnects for some reason. I will check other logs, and look for a recent FortiClient for Linux with VPN support. |
I've downloaded the forticlient-sslvpn And It works on my satelite connection, but the openfortivpn don't work, on windows it's normal too. |
I've come across a weird error that is outside my skills to fix, but I assume the problem may rest with openfortivpn. When I attempt to connect to my university VPN (which requires TFA) over a satellite connection (HughesNet, very slow), the two-factor authentication comes up successfully, and the service is authenticated, but the tunnel is never established. The error I'm seeing is
ERROR: Timed out waiting for the ppp interface to be UP.
I can successfully connect the VPN if I use my phone's USB tethering. I have attached a sample of the verbose output with the timeout, and of the working connection.
forti_error.log
forti_tethering_working.log
The text was updated successfully, but these errors were encountered: