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.

Sign up for GitHub

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

Jump to bottom

[Help] Can't execute /etc/ppp/ip-up: Permission denied #768

Closed
Mihai-B opened this issue Aug 10, 2020 · 30 comments
Closed

[Help] Can't execute /etc/ppp/ip-up: Permission denied #768

Mihai-B opened this issue Aug 10, 2020 · 30 comments
Labels
question

Comments

@Mihai-B
Copy link

Mihai-B commented Aug 10, 2020

So I was using OpenFortiGui for some time now and it works fine but I switched to this package + NetworkManager-fortisslvpn since it integrates better with GUI.
The problem is, I can create a successful connection, but I cannot access resources from the other part of the VPN's pipe.
Checking the logs I see this:

pppd[6976]: pppd 2.4.7 started by root, uid 0
aug 06 20:40:32 dellBox pppd[6976]: Using interface ppp0
aug 06 20:40:32 dellBox NetworkManager[6976]: Using interface ppp0
aug 06 20:40:32 dellBox NetworkManager[6976]: Connect: ppp0 <--> /dev/pts/2
aug 06 20:40:32 dellBox pppd[6976]: Connect: ppp0 <--> /dev/pts/2
aug 06 20:40:32 dellBox NetworkManager[5809]: <info>  [1596735632.4506] manager: (ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/6)
aug 06 20:40:32 dellBox NetworkManager[6976]: {/tmp/.01KVO0} {/tmp}
aug 06 20:40:32 dellBox NetworkManager[6976]: {/tmp/.01KVO0} {.01KVO0}
aug 06 20:40:32 dellBox NetworkManager[6975]: INFO:   Got addresses: [10.10.12.15], ns [192.168.1.8, 192.168.1.9], ns_suffix [xyz.local zyz.com]
aug 06 20:40:32 dellBox NetworkManager[6975]: INFO:   Negotiation complete.
aug 06 20:40:33 dellBox NetworkManager[6975]: INFO:   Negotiation complete.
aug 06 20:40:33 dellBox NetworkManager[6976]: Cannot determine ethernet address for proxy ARP
aug 06 20:40:33 dellBox NetworkManager[6976]: local  IP address 10.10.12.15
aug 06 20:40:33 dellBox NetworkManager[6976]: remote IP address 192.0.2.1
aug 06 20:40:33 dellBox pppd[6976]: Cannot determine ethernet address for proxy ARP
aug 06 20:40:33 dellBox pppd[6976]: local  IP address 10.10.12.15
aug 06 20:40:33 dellBox pppd[6976]: remote IP address 192.0.2.1
aug 06 20:40:33 dellBox NetworkManager[5809]: <info>  [1596735633.5687] device (ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
aug 06 20:40:33 dellBox pppd[6976]: Can't execute /etc/ppp/ip-up: Permission denied
aug 06 20:40:33 dellBox NetworkManager[6976]: Can't execute /etc/ppp/ip-up: Permission denied
aug 06 20:40:33 dellBox NetworkManager[5809]: <info>  [1596735633.5719] device (ppp0): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'external')

Am I doing something wrong or there is some problem with this plugin? It
I am on Manjaro and I using networkmanager-fortisslvpn 1.4rc1-2 and openfortivpn 1.14.1-1.

If I have to provide anything else let me know. If I am doing something wrong, any help is appreciated
@DimitriPapadopoulos
Copy link
Collaborator

Could you please run openfortivpn directly from the command line (verbose mode) and send the sanitized output? Alternatively report issues to the NetworkManager-fortisslvpn site.

Clearly this is an issue with pppd and it looks like permissions for /etc/ppp/ip-up are incorrect. Which Linux distribution is this? On Ubuntu 18.04:

$ ls -dl /etc/ppp/ip-up*
-rwxr-xr-x 1 root root 1892 févr. 26  2018 /etc/ppp/ip-up
drwxr-xr-x 2 root root 4096 mai   16 13:11 /etc/ppp/ip-up.d
$

@Mihai-B
Copy link
Author

Mihai-B commented Aug 13, 2020 •
edited
Loading

Hi @DimitriPapadopoulos ,
I am on Manjaro and I using networkmanager-fortisslvpn 1.4rc1-2 and openfortivpn 1.14.1-1.
Running the command you specified returns this:

~ >>> ls -dl /etc/ppp/ip-up*                                                                                           
-rwxr-xr-x 1 root root  309 feb 20 23:37 /etc/ppp/ip-up
drwxr-xr-x 2 root root 4096 mai 11 09:49 /etc/ppp/ip-up.d
~ >>>

So it is identical, I did open a issue on NetworkManager-fortisslvpn and they sugested I should look into this issue and indeed that issue kind of looks like something I am having but don't really know what to try/do next

@DimitriPapadopoulos
Copy link
Collaborator

I'm not sure #503 is related, as far as I can tell the error messages are different:

aug 06 20:40:33 dellBox NetworkManager[5809]: <info>  [1596735633.5687] device (ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
aug 06 20:40:33 dellBox pppd[6976]: Can't execute /etc/ppp/ip-up: Permission denied
aug 06 20:40:33 dellBox NetworkManager[6976]: Can't execute /etc/ppp/ip-up: Permission denied
aug 06 20:40:33 dellBox NetworkManager[5809]: <info>  [1596735633.5719] device (ppp0): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'external')

Strange. If I recall correctly, both openfortivpn and pppd need to be run as root - otherwise they fail earlier on. Therefore pppd is probably run as root - but fails to execute /etc/ppp/ip-up or so it seems.

@DimitriPapadopoulos
Copy link
Collaborator

DimitriPapadopoulos commented Aug 13, 2020 •
edited
Loading

It's best to run openfortivpn from the command line, make sure it works. Then try a few variations of the options until we can reproduce the issue. If we cannot reproduce it, then it's really up to the NetworkManager or more probably Manjaro guys.

@DimitriPapadopoulos
Copy link
Collaborator

Also report the output of:

ls -al /etc/ppp/ip-up.d

@Mihai-B
Copy link
Author

Mihai-B commented Aug 13, 2020 

~ >>> ls -al /etc/ppp/ip-up.d                                                                                          
total 12
drwxr-xr-x 2 root root 4096 mai 11 09:49 .
drwxr-xr-x 7 root root 4096 iul 24 19:47 ..
-rwxr-xr-x 1 root root  344 feb 20 23:37 00-dns.sh
~ >>>

I will run openfortivpn on it's own and see if everything works correctly and report back

@Mihai-B
Copy link
Author

Mihai-B commented Aug 17, 2020 •
edited
Loading

So I used the openfortivpn as you sugested, and I can connect to the vpn but I cannot access any internal websites.
This is my terminal log that I get:

sudo openfortivpn -c /etc/openfortivpn/config                                                                    
[sudo] password for mike: 
INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
INFO:   Got addresses: [10.10.12.15], ns [192.168.1.8, 192.168.1.9], ns_suffix [abc.local xyz.com]
INFO:   Negotiation complete.
INFO:   Negotiation complete.
Cannot determine ethernet address for proxy ARP
local  IP address 10.10.12.15
remote IP address 192.0.2.1
INFO:   Interface ppp0 is UP.
INFO:   Setting new routes...
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
INFO:   Adding VPN nameservers...
INFO:   Tunnel is up and running.

In the config file I only specified the host, port, username, password and the trusted cert.

@mrbaseman
Copy link
Collaborator

The warning about the already existing gateway route makes me wonder what is going wrong, especially since it is issued twice. Does it look differently on a freshly booted system?

@Mihai-B
Copy link
Author

Mihai-B commented Aug 18, 2020 •
edited
Loading

The warning about the already existing gateway route makes me wonder what is going wrong, especially since it is issued twice. Does it look differently on a freshly booted system?

Today I booted my system and tried it again. the console output is exactly the same and I cannot access internal services. So I don't know why.

After testing the openfortivpn I tried the openfortiGUI and that one worked as expected.

@DimitriPapadopoulos
Copy link
Collaborator

OpenFortiGUI uses openfortivpn internally. The only reasons why openfortivpn would fail are:

  • OpenFortiGUI ships with a different (older) version of openfortivpn,
  • the default configuration is different.

The warnings are suspect indeed, something might be wrong with routing but it's hard to tell from the existing data. Perhaps you can show the output of route and ifconfig before and after starting openfortivpn (and OpenFortiGUI for comparison since it works).

Also just to make sure this is a routing problem and not a DNS problem, can you try to access internal services by IP address instead of DNS name?

@DimitriPapadopoulos
Copy link
Collaborator

As far as I can tell you're running openfortivpn 1.14.1. OpenFortiGUI sources have been updated to openfortivpn 1.14.1 between 0.9.0 and 0.9.1-dev. Which version of OpenFortiGUI are you running?

@Mihai-B
Copy link
Author

Mihai-B commented Aug 19, 2020

I use the latest version of openfortigui that is available in the AUR repository aka 0.9.0-2. So I think it uses openfortivpn 1.14.1

As for the output of route and ifconfig:

~ >>> ip route                                                                                                    [255]
default via 192.168.101.1 dev wlo1 proto dhcp metric 600 
192.168.101.0/24 dev wlo1 proto kernel scope link src 192.168.101.188 metric 600 
~ >>>  

~ >>> ip address                                                                                                       
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether e4:b9:7a:62:89:23 brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 18:56:80:89:e2:75 brd ff:ff:ff:ff:ff:ff
    altname wlp0s20f3
    inet 192.168.101.188/24 brd 192.168.101.255 scope global dynamic noprefixroute wlo1
       valid_lft 42265sec preferred_lft 42265sec
    inet6 2a02:2f0e:40a:6300::f5f/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fdc7:7509:4804::f5f/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fdc7:7509:4804:0:9948:1404:d89:539/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2a02:2f0e:40b:6400:96f5:3b80:95e1:99f1/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::d6f:181e:b75b:2828/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
~ >>>

@DimitriPapadopoulos
Copy link
Collaborator

I use the latest version of openfortigui that is available in the AUR repository aka 0.9.0-2. So I think it uses openfortivpn 1.14.1

As far as I can see OpenFortiGUI 0.9.0-2 uses openfortivpn 1.14.0. Anyway, there are few differences between the 0.14 versions so it's certainly not relevant.

@DimitriPapadopoulos
Copy link
Collaborator

As for the ip route and ip address they look good but they're not related to openfortivpn as far as I can see. You need to run them after openfortivpn has started too:

Perhaps you can show the output of route and ifconfig before and after starting openfortivpn (and OpenFortiGUI for comparison since it works).

Also have you tried this?

can you try to access internal services by IP address instead of DNS name?

@nehaljwani
Copy link
Contributor

@Mihai-B In one of your previous (edited) comments you had mentioned:

The only diference that I noticed is that in openfortiGUI I have the option half internet routes activated and insecure-ssl also activated.

Is it still the case? Could you try adding half-internet-routes=1 in your config file and try again?

@Mihai-B
Copy link
Author

Mihai-B commented Aug 25, 2020 •
edited
Loading

As for the ip route and ip address they look good but they're not related to openfortivpn as far as I can see. You need to run them after openfortivpn has started too:

OMG this was a fail moment from me. Sry about that. so here is the before and after of ip route command

~ >>> ip route                                                                                                    [255]
default via 192.168.101.1 dev wlo1 proto dhcp metric 600 
192.168.101.0/24 dev wlo1 proto kernel scope link src 192.168.101.188 metric 600 
~ >>>

and after:

~ >>> ip route                                                                                                                             
default via 192.168.102.1 dev wlo1 proto dhcp metric 600 
10.0.0.0/25 dev ppp0 scope link 
10.0.0.128/25 dev ppp0 scope link 
10.22.65.0/25 dev ppp0 scope link 
10.22.66.0/25 dev ppp0 scope link 
10.36.76.0/24 dev ppp0 scope link 
10.80.56.0/22 dev ppp0 scope link 
10.104.42.137 dev ppp0 scope link 
13.81.26.133 dev ppp0 scope link 
13.94.187.170 dev ppp0 scope link 
31.171.207.197 dev ppp0 scope link 
62.148.187.54 dev ppp0 scope link 
62.148.187.55 dev ppp0 scope link 
84.38.225.49 dev ppp0 scope link 
89.33.132.0/25 dev ppp0 scope link 
89.33.132.250 via 192.168.102.1 dev wlo1 
92.42.233.96 dev ppp0 scope link 
92.42.233.103 dev ppp0 scope link 
92.42.233.112 dev ppp0 scope link 
104.42.97.175 dev ppp0 scope link 
116.202.225.0/24 dev ppp0 scope link 
139.16.51.0/25 dev ppp0 scope link 
172.16.60.0/24 dev ppp0 scope link 
172.17.60.0/24 dev ppp0 scope link 
172.30.0.0/16 dev ppp0 scope link 
176.62.197.59 dev ppp0 scope link 
185.110.173.109 dev ppp0 scope link 
192.0.2.1 dev ppp0 proto kernel scope link src 10.10.12.19 
192.168.0.0/19 dev ppp0 scope link 
192.168.31.0/24 dev ppp0 scope link 
192.168.32.0/24 dev ppp0 scope link 
192.168.102.0/24 dev wlo1 proto kernel scope link src 192.168.102.107 metric 600 
192.168.115.0/24 dev ppp0 scope link 
199.107.65.41 dev ppp0 scope link 
199.107.65.51 dev ppp0 scope link 
213.187.241.94 dev ppp0 scope link 
213.187.247.18 dev ppp0 scope link 
213.187.247.138 dev ppp0 scope link

The ip adress commands retuns the same output as before

Perhaps you can show the output of route and ifconfig before and after starting openfortivpn (and OpenFortiGUI for comparison since it works).

I do not have ifconfig but isn't it the same what I am posting from ip package?

Also have you tried this?

can you try to access internal services by IP address instead of DNS name?

Yes I can access the services if I use directly the IP

@Mihai-B
Copy link
Author

Mihai-B commented Aug 25, 2020

@Mihai-B In one of your previous (edited) comments you had mentioned:

The only diference that I noticed is that in openfortiGUI I have the option half internet routes activated and insecure-ssl also activated.

Is it still the case? Could you try adding half-internet-routes=1 in your config file and try again?

I did add, that is why I edited my reply, because I added it and it was the same result

@DimitriPapadopoulos
Copy link
Collaborator

Yes I can access the services if I use directly the IP

Ah, then it's probably a DNS issue, not a routing issue. Can you show /etc/resolv.conf, before and after connection?

@DimitriPapadopoulos
Copy link
Collaborator

And also nmcli dev show before and after connection.

@aaronjg
Copy link
Contributor

aaronjg commented Aug 29, 2020

Could you also show the output of:

dig @192.168.1.8 <hostname>
dig -b <internal ip> @192.168.1.8 <hostname>
dig @192.168.1.8 <hostname>
dig -b <internal ip> @192.168.1.9 <hostname>

Where <hostname> is an internal host, and is the ip address given by the fortivpn tunnel (10.10.12.15 in the example above, but may not be the same every time).

The ip address command isn't showing the ppp0 device. Could you try: ip address ls ppp0

@Mihai-B
Copy link
Author

Mihai-B commented Aug 31, 2020

/etc/resolv.conf details before connection:

# Generated by NetworkManager
search lan
nameserver 192.168.102.1
nameserver fd0a:6637:5ec5::1

and nmcli dev show before connection

nmcli dev show                                                                                                              
GENERAL.DEVICE:                         wlo1
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         18:56:80:89:E2:75
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     NetPrinAer_F
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/1
IP4.ADDRESS[1]:                         192.168.102.107/24
IP4.GATEWAY:                            192.168.102.1
IP4.ROUTE[1]:                           dst = 0.0.0.0/0, nh = 192.168.102.1, mt = 600
IP4.ROUTE[2]:                           dst = 192.168.102.0/24, nh = 0.0.0.0, mt = 600
IP4.DNS[1]:                             192.168.102.1
IP4.DOMAIN[1]:                          lan
IP6.ADDRESS[1]:                         2a02:2f01:8100:5b00:f2a7:f98:4a34:e0e8/64
IP6.ADDRESS[2]:                         2a02:2f01:8502:6400:940b:2f2b:35d0:b0c4/64
IP6.ADDRESS[3]:                         fd0a:6637:5ec5:0:2839:fe47:8031:8593/64
IP6.ADDRESS[4]:                         2a02:2f01:8100:5b00::f5f/128
IP6.ADDRESS[5]:                         2a02:2f01:8502:6400::f5f/128
IP6.ADDRESS[6]:                         fd0a:6637:5ec5::f5f/128
IP6.ADDRESS[7]:                         fe80::b3ff:268b:3d23:f4e1/64
IP6.GATEWAY:                            fe80::1aa6:f7ff:fe74:2dfa
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 600
IP6.ROUTE[2]:                           dst = fd0a:6637:5ec5::/48, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[3]:                           dst = 2a02:2f01:8502:6400::/56, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[4]:                           dst = 2a02:2f01:8100:5b00::/56, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[5]:                           dst = fd0a:6637:5ec5::/64, nh = ::, mt = 600
IP6.ROUTE[6]:                           dst = 2a02:2f01:8502:6400::/64, nh = ::, mt = 600
IP6.ROUTE[7]:                           dst = 2a02:2f01:8100:5b00::/64, nh = ::, mt = 600
IP6.ROUTE[8]:                           dst = ::/0, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[9]:                           dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE[10]:                          dst = fd0a:6637:5ec5::f5f/128, nh = ::, mt = 600
IP6.ROUTE[11]:                          dst = 2a02:2f01:8502:6400::f5f/128, nh = ::, mt = 600
IP6.ROUTE[12]:                          dst = 2a02:2f01:8100:5b00::f5f/128, nh = ::, mt = 600
IP6.DNS[1]:                             fd0a:6637:5ec5::1

GENERAL.DEVICE:                         p2p-dev-wlo1
GENERAL.TYPE:                           wifi-p2p
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            0
GENERAL.STATE:                          30 (disconnected)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --

GENERAL.DEVICE:                         eno2
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         E4:B9:7A:62:89:23
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               off

GENERAL.DEVICE:                         lo
GENERAL.TYPE:                           loopback
GENERAL.HWADDR:                         00:00:00:00:00:00
GENERAL.MTU:                            65536
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         127.0.0.1/8
IP4.GATEWAY:                            --
IP6.ADDRESS[1]:                         ::1/128
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = ::1/128, nh = ::, mt = 256

After VPN connection:

/etc/resolv.conf details:

nameserver 192.168.1.8
nameserver 192.168.1.9
search abc.local abc.com
# Generated by NetworkManager
search lan
nameserver 192.168.102.1
nameserver fd0a:6637:5ec5::1

and

nmcli dev show                                                                                                              
GENERAL.DEVICE:                         wlo1
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         18:56:80:89:E2:75
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     NetPrinAer_F
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/1
IP4.ADDRESS[1]:                         192.168.102.107/24
IP4.GATEWAY:                            192.168.102.1
IP4.ROUTE[1]:                           dst = 0.0.0.0/0, nh = 192.168.102.1, mt = 600
IP4.ROUTE[2]:                           dst = 192.168.102.0/24, nh = 0.0.0.0, mt = 600
IP4.ROUTE[3]:                           dst = 89.33.132.250/32, nh = 192.168.102.1, mt = 0
IP4.DNS[1]:                             192.168.102.1
IP4.DOMAIN[1]:                          lan
IP6.ADDRESS[1]:                         2a02:2f01:8100:5b00:f2a7:f98:4a34:e0e8/64
IP6.ADDRESS[2]:                         2a02:2f01:8502:6400:940b:2f2b:35d0:b0c4/64
IP6.ADDRESS[3]:                         fd0a:6637:5ec5:0:2839:fe47:8031:8593/64
IP6.ADDRESS[4]:                         2a02:2f01:8100:5b00::f5f/128
IP6.ADDRESS[5]:                         2a02:2f01:8502:6400::f5f/128
IP6.ADDRESS[6]:                         fd0a:6637:5ec5::f5f/128
IP6.ADDRESS[7]:                         fe80::b3ff:268b:3d23:f4e1/64
IP6.GATEWAY:                            fe80::1aa6:f7ff:fe74:2dfa
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 600
IP6.ROUTE[2]:                           dst = fd0a:6637:5ec5::/48, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[3]:                           dst = 2a02:2f01:8502:6400::/56, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[4]:                           dst = 2a02:2f01:8100:5b00::/56, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[5]:                           dst = fd0a:6637:5ec5::/64, nh = ::, mt = 600
IP6.ROUTE[6]:                           dst = 2a02:2f01:8502:6400::/64, nh = ::, mt = 600
IP6.ROUTE[7]:                           dst = 2a02:2f01:8100:5b00::/64, nh = ::, mt = 600
IP6.ROUTE[8]:                           dst = ::/0, nh = fe80::1aa6:f7ff:fe74:2dfa, mt = 600
IP6.ROUTE[9]:                           dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE[10]:                          dst = fd0a:6637:5ec5::f5f/128, nh = ::, mt = 600
IP6.ROUTE[11]:                          dst = 2a02:2f01:8502:6400::f5f/128, nh = ::, mt = 600
IP6.ROUTE[12]:                          dst = 2a02:2f01:8100:5b00::f5f/128, nh = ::, mt = 600
IP6.DNS[1]:                             fd0a:6637:5ec5::1

GENERAL.DEVICE:                         ppp0
GENERAL.TYPE:                           ppp
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            1354
GENERAL.STATE:                          30 (disconnected)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --

GENERAL.DEVICE:                         p2p-dev-wlo1
GENERAL.TYPE:                           wifi-p2p
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            0
GENERAL.STATE:                          30 (disconnected)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --

GENERAL.DEVICE:                         eno2
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         E4:B9:7A:62:89:23
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               off

GENERAL.DEVICE:                         lo
GENERAL.TYPE:                           loopback
GENERAL.HWADDR:                         00:00:00:00:00:00
GENERAL.MTU:                            65536
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         127.0.0.1/8
IP4.GATEWAY:                            --
IP6.ADDRESS[1]:                         ::1/128
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = ::1/128, nh = ::, mt = 256

ip address ls ppp0                                                                                                          
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1354 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 10.10.12.36 peer 192.0.2.1/32 scope global ppp0
       valid_lft forever preferred_lft forever

@skoehler
Copy link

I also have the Can't execute /etc/ppp/ip-up: Permission denied issue on Arch Linux. I have to specify DNS servers and DNS Domain suffix manually, it's not configured automatically - maybe due to the permission denied error. I will raise an issue with the Arch Linux maintainers.

@skoehler
Copy link

Do we actually want /etc/ppp/ip-up to be executed? On Arch, the file /etc/ppp/ip-up.d/00-dns.sh may actually overwrite /etc/resolv.conf.

@DimitriPapadopoulos
Copy link
Collaborator

Well, openfortivpn does not mess with /etc/ppp/ip-up, pppd does. Not an openfortivpn issue I guess?

@skoehler
Copy link

skoehler commented Feb 24, 2021 •
edited
Loading

I will raise an issue with the Arch devs about the whole pppd/ip-up thing.

When running openfortivpn from the command line, the DNS servers and the DNS Domain suffix are successfully received. The permission denied error does not occur and /etc/resolv.conf is updated successfully. That, of course, is a problem. I am using NetworkManager and systemd-resolved. The file /etc/resolv.conf should not be touched. Instead, systemd-resolved should be informed about the new DNS server and the new DNS suffix. That doesn't happen, so something is wrong.

I have not understood how NetworkManager obtains the DNS information from pppd-based VPN services. Might that be an NetworkManager-fortisslvpn issue?

The Problem by the OP may also be DNS related, as he cannot access internal websites. That may be an indication of the DNS problem that I am seeing. A workaround would be to specify the DNS server and suffix manually when configuring the VPN connection in NetworkManager.

@DimitriPapadopoulos
Copy link
Collaborator

Actually openfortivpn is still using the legacy method of modifying /etc/resolv.conf. We haven't found the time to adapt it to NetworkManager and systemd-resolved. It used to work until the latest Linux distributions such as Fedora 33. There's an open ticket about this issue, see #600. Please focus on the specific issue at hand in this ticket.

@TimisRobert
Copy link

Same issue when using networkmanager-fortisslvpn plugin, had to set manually DNS IPs to make it work. No problems when using openfortivpn from command line.

@DimitriPapadopoulos
Copy link
Collaborator

Same issue when using networkmanager-fortisslvpn plugin, had to set manually DNS IPs to make it work. No problems when using openfortivpn from command line.

This ticket has grown too long, I don't even recall what this "same issue" might refer too. Also I seem to recall this was about an OpenFortiGui issue. Hence I have to close this ticket, it has become intractable.

If you think you have an OpenFortiGui issue, please open a new ticket here:
https://github.com/theinvisible/openfortigui/issues

@codiflow
Copy link

Just as a note for people who might find this issue by looking up the error message (like I did).

I can confirm this issue on recent Manjaro and the cause has already been found (but not fixed). Here's the corresponding post: https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/issues/30#note_1420586

So for now it seems like running openfortivpn as priviledged user just works fine (and this is the workaround) and the implementation with NetworkManager in Manjaro is currently broken.

@jmperro
Copy link

jmperro commented Mar 25, 2024

Hi!
this solution works perfectly
NixOS/nixpkgs#231038 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@skoehler @aaronjg @Mihai-B @nehaljwani @DimitriPapadopoulos @jmperro @mrbaseman @codiflow @TimisRobert