-
Notifications
You must be signed in to change notification settings - Fork 321
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
Incorrect tunnel peer IP #1177
Comments
That's https://github.com/adrienverge/openfortivpn/wiki#reporting-issues |
openfortivpn 1.21.0 output
pppd 2.5.0 log
ppp v2.4.9 log (started by openfortivpn 1.20.5)
Replaced the server IP address in the logs with |
So you believe the problem with pppd 2.5.0 lies here:
as opposed to pppd 2.4.9:
However, this seems beyond the control of openfortivpn, that's a negotiation between pppd and the FortiGate. I am not sure how to fix that, this looks like a misconfiguration on the FortiGate or a bug in the version of pppd you are using. |
I see the same problem on an older FortiGate. 169.254.0.0/16 is reserved for link-local addresses, according to https://en.wikipedia.org/wiki/Reserved_IP_addresses That IP is set in src/tunnel.c, line 257. The first time it shows up (ppp 2.4.9), is when the server sends Eventually ppp 2.4.9 and the fortigate agree to disagree, and the tunnel is configured with a link-local address anyway. but negotiation is "complete", so the tunnel is set up with ppp 2.4.9 ppp 2.5.0 drops the tunnel. The ipcp-accept-remote tells ppp to accept , as opposed to the link-local address. My fortigate server sends it's public IP as it's link IP. If the fortigate is running a firewall, it will now receive private (vpn) traffic with public ips, and drop the packets. So the bugs:
However, these bugs cancel each other out. Next step: Remove the option ":169.254.2.1" from src/tunnel.c and try again. |
So removing option ":169.254.2.1" in src/tunnel.c also removes the need for "ipcp-accept-remote". However, it does not fix connectivity to FortiGate servers where the FortiGate is giving an incorrect link-local IP address. |
Is that a problem? From the pppd(8) man page:
I have already tried omitting remote_IP_address, but (some version of) |
I'm happy to apply a patch if you can work out a solution, but it has to work with 2.4.9 (when configured with |
No, I do think this is a mistake in the configuration on the server. I do not think it's possible to fix this inside openfortivpn with pppd 2.5.0. pppd 2.4.9 worked by accident, because it configures a different remote IP than the remote wants. This is a mistake, but in this case two wrongs make a right. pppd 2.5.0 won't work with the same server configuration. This is a behavioural change towards correctness. pppd would need to add an option "ipcp-override-remote" to restore the incorrect 2.4.9 behaviour. |
I built ppp-2.5.0-r7 as well as ppp-2.5.1-r1 with openfortivpn-1.22.1 which supports --pppd-accept-remote=1 but I still get wrong peer IP 185.x.x.x instead of 169.254.2.1 By the way, nothing's changing when I set --pppd-accept-remote=0 or --pppd-accept-remote=1 |
openfortivpn version: 1.21.0
ppp version: 2.5.0
OS: arch linux
When attempting to make a connection the peer IP of the tunnel is set to the IP of the server. It works correctly on openfortivpn 1.20.5 with ppp 2.4.9.
The text was updated successfully, but these errors were encountered: