Skip to content
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

openfortivpn won't connect, ppp timeout, modem hanging up #1138

Closed
Czechball opened this issue Sep 19, 2023 · 14 comments
Closed

openfortivpn won't connect, ppp timeout, modem hanging up #1138

Czechball opened this issue Sep 19, 2023 · 14 comments

Comments

@Czechball
Copy link

My system

  • Manjaro Linux 23.0.2
  • Kernel 6.5.3-1-MANJARO
  • openfortivpn verson 1.20.5

My config (very basic, hasn't been changed recently)

host = IP
port = PORT
username = MY_USERNAME
password = MY_PASSWORD
trusted-cert = CERT_STRING

The problem

When I start openfortivpn, it will get stuck for a few seconds, then exit with status code 16. I have tried connecting with the same configuration using the official Forticlient software and it has worked without a problem.

Log (shortened)

$ sudo openfortivpn -v

INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
INFO:   Got addresses: [redacted], ns [redacted, redacted], ns_suffix [redacted]
INFO:   Negotiation complete.

This is where the seemingly suspicious parts of the log output start:

DEBUG:  Got Address: redacted
DEBUG:  if_config: not ready yet...
DEBUG:  gateway ---> pppd (12 bytes)
DEBUG:  pppd ---> gateway (12 bytes)

The last two lines (gateway ---> pppd) then get repeated a bunch of times, then a single instance of the first two lines is repeated. This whole thing is again repeated a few times, then this follows:

INFO:   Negotiation complete.
Peer refused to agree to his IP address
DEBUG:  pppd ---> gateway (6 bytes)
Connect time 0.1 minutes.
Sent 1101 bytes, received 1081 bytes.
DEBUG:  pppd ---> gateway (28 bytes)
DEBUG:  gateway ---> pppd (6 bytes)
DEBUG:  Got Address: redacted
DEBUG:  if_config: not ready yet...

And then again, the lines Got Address: redacted, if_config: not ready yet... are repeated a lot of times in the output, then finally openfortivpn crashes:

ERROR:  Timed out waiting for the ppp interface to be UP.
INFO:   Cancelling threads...
INFO:   Cleanup, joining threads...
DEBUG:  Disconnecting
DEBUG:  Waiting for pppd to exit...
Hangup (SIGHUP)
Modem hangup
Connection terminated.
DEBUG:  waitpid: pppd exit status code 16
ERROR:  pppd: The link was terminated by the modem hanging up.
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
DEBUG:  SO_KEEPALIVE: OFF
DEBUG:  TCP_KEEPIDLE: 7200
DEBUG:  TCP_KEEPINTVL: 75
DEBUG:  TCP_KEEPCNT: 9
DEBUG:  SO_SNDBUF: 16384
DEBUG:  SO_RCVBUF: 131072
DEBUG:  server_addr: redacted
DEBUG:  server_port: redacted
DEBUG:  gateway_ip: redacted
DEBUG:  gateway_port: redacted
DEBUG:  Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4
DEBUG:  Setting minimum protocol version to: 0x303.
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Logged out.
@DimitriPapadopoulos
Copy link
Collaborator

The PPP protocol is handled by pppd. There have been breaking changes in version 2.5.0, perhaps that's the case here.

  • Which version of pppd does your system have? 2.5.0?
  • It might be that pppd is misconfigured (or rather configured in a way incompatible with openfortivpn. Have you added or modified files under /etc/ppp? Have you tried from a freshly installed (possibly virtual) machine?
  • For that reason it woud dbe worth testing the tun branch which bypasses pppd and supports PPP internally.

@trevorludgate
Copy link

Same issue as you on ArchLinux. pppd was recently updated to 2.5.0
I tried uncommenting "ipcp-accept-remote" in /etc/ppp/options - it allowed the tunnel to establish, but it timed out after a few seconds since it couldn't reach the remote network.
I ended up downgraded pppd to 2.4.9 and it works for now

@Xplouder
Copy link

Same problem here.
Like @trevorludgate i had to downgrade networkmanager-pptp (1.2.12-3 => 1.2.12-1) and ppp (2.5.0-1 => 2.4.9-3).

@FBRosito
Copy link

Like @Xplouder said, i had to downgrade ppp (2.5.0-1 => 2.4.9-3). I'm on Manjaro with 6.1.53-1 Kernel.

@rodarima
Copy link

The ipcp-accept-remote option was removed here and is now only added if you specify the --pppd-accept-remote flag.

Try enabling the --pppd-accept-remote option for openfortivpn. For systemd use % sudo systemctl edit --full openfortivpn.service to edit the file directly, and set:

ExecStart=/usr/bin/openfortivpn --pppd-accept-remote

In arch is in the /etc/systemd/system/openfortivpn.service file (or use an override). Seems to work fine for me with 1.20.5:

...
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Interface ppp0 is UP.
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Setting new routes...
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Adding VPN nameservers...
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Tunnel is up and running.

@DblD
Copy link

DblD commented Sep 22, 2023

The ipcp-accept-remote option was removed here and is now only added if you specify the --pppd-accept-remote flag.

Try enabling the --pppd-accept-remote option for openfortivpn. For systemd use % sudo systemctl edit --full openfortivpn.service to edit the file directly, and set:

ExecStart=/usr/bin/openfortivpn --pppd-accept-remote

In arch is in the /etc/systemd/system/openfortivpn.service file (or use an override). Seems to work fine for me with 1.20.5:

...
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Interface ppp0 is UP.
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Setting new routes...
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Adding VPN nameservers...
Sep 22 11:10:32 hop openfortivpn[943414]: INFO:   Tunnel is up and running.

Adding flag --pppd-accept-remote resolves for me on
6.5.4-arch2-1
openfortivpn Version : 1.20.5-1

@ipha
Copy link

ipha commented Sep 22, 2023

--pppd-accept-remote lets it connect(or at least it thinks it connects,) but I can't pass any traffic.

@trevorludgate
Copy link

trevorludgate commented Sep 22, 2023

--pppd-accept-remote works for me as well. VPN establishes, stays established, and traffic is passing through.
ppp: 2.5.0-1
openfortivpn: 1.20.5
6.5.3-arch1-1 (and 6.5.4-arch2-1)

EDIT: I tried to disconnect and reconnect to the VPN (after successfully connecting on ppp 2.5.0-1) and it established but wouldn't pass traffic. Rebooted and now it's working.

@trevorludgate
Copy link

I haven't had time to diagnose the issue, but traffic won't pass through the VPN after the VPN is disconnected until a reboot. Has anyone else run into this issue? I want to avoid rolling back ppp if possible.

Thanks!

@DimitriPapadopoulos
Copy link
Collaborator

DimitriPapadopoulos commented Oct 4, 2023

@trevorludgate Your post does not provide actionable information (Linux distribution, logs, error messages). Did you really mean to write "traffic won't pass through the VPN after the VPN is disconnected"? Perhaps "traffic won't pass through the VPN after the VPN is stopped and restarted"? Maybe a routing issue, such as routes not being properly reset when leaving openfortivpn. Try comparing the logs of the first run and second run of openfortivpn. How do they differ?

@trevorludgate
Copy link

Yes, "traffic won't pass through the VPN after the VPN is stopped and restarted" is phrased better.
I mentioned it because @ipha had the same issue (VPN establishes but traffic wouldn't pass) after adding the "--pppd-accept-remote" flag. I wanted to see if anyone else was having the issue.
Logs of the first and second run of openfortivpn were identical for me. I didn't have a chance to enable verbose logs.

In the end, my issue is that I had both network-manager and dhcpcd services enabled. Dhcpcd was adding a second IP address on the same interface and duplicating my routes. I suspect this was causing the issue.
After disabling dhcpcd, the routes were normal and the VPN was able to establish and pass traffic after restarting the VPN.
Hopefully this helps anyone else having the same issue.

@Utini2000
Copy link

Yup, same problem here and the solution from @rodarima seems to work.

Is there any way to pass this parameter also via networkmanager gui?
I would not like to edit my .service file in case this change gets reverted or the .service file updated/overwritten in the future.

Repository owner deleted a comment from JfrAziz Nov 5, 2023
Repository owner deleted a comment from fpf3 Nov 5, 2023
@DimitriPapadopoulos
Copy link
Collaborator

It looks like there are two different issues here:

  1. The initial issue with pppd 2.5.0 appears to be fixed by ipcp-accept-remote. The fix has been known for a long time and is very simple to implement for pppd ≥ 2.5.0. It is more complex to take into account both pppd ≥ 2.5.0 and pppd < 2.5.0. My initial intent was to detect the version of pppd at runtime - but it turns out I hardly have time to implement that. Therefore, I have decided the next version will support pppd ≥ 2.5.0 by default, with build-time option configure --enable-legacy-pppd to support pppd < 2.5.0.
    → Should be fixed by 1a6d2e9, please test and report back if it doesn't work.
  2. @trevorludgate You're experiencing a different issue, where ipcp-accept-remote does help you, but the VPN connection doesn't work properly afrer a stop/start cycle. Please open a different issue, as this issue will be closed when the next version is released.

@DimitriPapadopoulos
Copy link
Collaborator

DimitriPapadopoulos commented Nov 6, 2023

Fixed by #1148 and #1153.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants