v1.20.3 on OpenWRT - Hughes Internet

[antoniovalenzuela]

Hi

v1.20.3 on OpenWRT

4G mobile network works ok.

With Hughes satellite connection I have problems.

INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
INFO:   Got addresses: [192.168.X.X], ns [192.9.X.X, 192.9.X.X]
INFO:   Negotiation complete.
....
ERROR:  Timed out waiting for the ppp interface to be UP.
INFO:   Cancelling threads...
INFO:   Cleanup, joining threads...
Hangup (SIGHUP)
Modem hangup
Connection terminated.
ERROR:  pppd: Terminated because it was sent a SIGINT, SIGTERM or SIGHUP signal.
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
INFO:   Logged out.

With ipcp-accept-remote connects ok, but I can't reach the destination (ping or traceroute)

INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
INFO:   Got addresses: [192.168.X.X], ns [192.9.X.X, 192.9X.X]
INFO:   Negotiation complete.
local  IP address 192.168.X.X
remote IP address 181.212.X.X
INFO:   Interface ppp0 is UP.
INFO:   Setting new routes...
INFO:   Route to gateway exists already.
...
INFO:   Adding VPN nameservers...
INFO:   Tunnel is up and running.

route ok 192.9.x.x * 255.255.255.0 U 3 0 0 ppp0

[DimitriPapadopoulos]

First things first, which is the version of pppd and where did you get openfortivpn from?

If the version of pppd is < 2.5.0, then openfortivpn should have been built with --enable-legacy-pppd. If that's not the case:

• report it as a bug to the packagers,
• use ipcp-accept-remote as a workaround, as you do.

[DimitriPapadopoulos]

For the rest, it's hard to tell without actual routes and IP addresses. Do you ping DNS hostnames or IP addresses?

[DimitriPapadopoulos]

4G mobile network works ok.

With Hughes satellite connection I have problems.

Could be an MTU problem. Satellite connections may have lower MTU values than usual. Look for MTU values in the output of ip addr in either case. Try Troubleshooting MTU size over IPSEC VPN.

[antoniovalenzuela]

First things first, which is the version of pppd and where did you get openfortivpn from?

If the version of pppd is < 2.5.0, then openfortivpn should have been built with --enable-legacy-pppd. If that's not the case:

• report it as a bug to the packagers,
• use ipcp-accept-remote as a workaround, as you do.

pppd version 2.4.9

openfortivpn from https://mirror-03.infra.openwrt.org/releases/23.05.3/packages/arm_cortex-a9_vfpv3-d16/packages/

[antoniovalenzuela]

For the rest, it's hard to tell without actual routes and IP addresses. Do you ping DNS hostnames or IP addresses?

With ipcp-accept-remote ping to IP address no response and the route exist

Forticlient Windows without connection issue through Satellite.

[antoniovalenzuela]

4G mobile network works ok. With Hughes satellite connection I have problems.

Could be an MTU problem. Satellite connections may have lower MTU values than usual. Look for MTU values in the output of ip addr in either case. Try Troubleshooting MTU size over IPSEC VPN.

It's SSL VPN TCP 443.

[antoniovalenzuela]

New background Sat connection.

The console connection (with ipcp-accept-remote) has no problems, the routes work properly.

Luci web connection connected, but without ping response.

I checked the scripts, maybe some need to be modified

[antoniovalenzuela]

Luci use the arg "no-routes"

/lib/netifd/proto/openfortivpn.sh

    [ -n "$port" ] && port=":$port"
    append_args "$peeraddr$port" --ifname="$ifname" --use-syslog  -c /dev/null
    append_args "--set-dns=0"
    append_args "--no-routes"
    append_args "--pppd-use-peerdns=1"

no-routes with ipcp-accept-remote assign this routing table (wrong way) 181.212.X.X * 255.255.255.255 UH 0 0 0 ppp0

only ipcp-accept-remote (default routes yes) 181.212.X.X lte 255.255.255.255 UGH 0 0 0 eth1

Where 181.212.X,X is the remote VPN server.

My routes are manual in OpenWRT.

When commeting or discard this arg, assumes the routes provided by the server and the connectivity to the destination works.

append_args "--no-routes"

I prefer not to use the routes assigned by the server. I think it is better for me to use the Windows client when using the satellite connection.

[DimitriPapadopoulos]

You have to use the routes proposed by the server, as that's often part of the implicit contract when using corporate VPN servers.

I don't know what Luci web is. We don't maintain it and the error is probably in Lucy web.