Vpn connection via systemd unable to create routes

Ask Fedora Ask in English
, , ,
1

I have just started using openfortivpn to connect to a fortigate vpn. It is a standard rpm package I installed via dnf. It comes with a systems service file.

Here’s what happens:

  • I run fedora 32 up to date with selinux enabled
  • If I run the openfortivpn client manually (with sudo), it succeeds without problems
  • If I run it as a service via systemd, it comes up, but is unable to create routes:
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: DEBUG:  ip route add to 10.0.0.0/255.255.255.0 dev ppp0
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: WARN:   Could not set route to tunnel gateway (Operation not permitted).
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: DEBUG:  ip route add to 10.1.0.0/255.255.255.0 dev ppp0
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: WARN:   Could not set route to tunnel gateway (Operation not permitted).
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: DEBUG:  ip route add to 10.5.0.0/255.255.255.0 dev ppp0
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: WARN:   Could not set route to tunnel gateway (Operation not permitted).

  • The service runs as root, as I saw with ps

  • There are no entries in the selinux audit log

  • If I set selinux to permissive, the service starts and all the routes are successfully created.

  • again, no entries in the audit log

Now, I never run in permissive, and I don’t like the idea of starting the vpn manually.
What could be the problem? Clearly there is a permission problem, but where? Usually, I get information from the audit log, and fix it. Might there be policy via polkit required? This is a business requirement. Does anyone have an idea?

1 Like
2

Hi,

Does adding:

User=root

to the [Service] section.

Help?

Thanks Tom.

3

This looks like a bug.
See: Fedora Docs > How to file a bug

4

No, adding User=root changes nothing, I’m afraid.

What gets me is the silence from selinux, since that has always in the past been reliable to at least tell me something. Yet,

setenforce 0
systemctl start openfortivpn@xxx 
setenforce 1

works really well. (no, I don’t have a script for that… ) I hope it’s not a bug, just some missing polkit rule, maybe.

Thanks,
Mike

1 Like
5

Hi,

That was my next thought. From a quick google search; it doesn’t appear to be the first time its had an issue with selinux; although that was issue with updating /etc/resolv.conf

I would do as vgaetera suggests and file a bug report.

Thanks Tom.

1 Like
6

Did you already try:
restorecon -v /etc/resolv.conf

ref: https://bugzilla.redhat.com/show_bug.cgi?id=1787944

1 Like
7

You can also try to restore file context recursively:

sudo restorecon -R -v /etc
8

Tried both restorecon -v /etc/resolv.conf and restorecon -R -v /etc, no luck. Same thing happens. At least, for the restorecon bug, there was an AVC. I also checked the boolean openfortivpn_can_network_connect mentioned in the bug report, but it is there and set to on.

So I am coming to the same conclusion, a bug report is warranted. Thanks for your efforts on my behalf.

Mike

2 Likes
9

I’ve submitted this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1858358

1 Like
10

Probably you should change the component to selinux-policy as just a few packages provide custom policies and most rely on the default policies.

11

I don’t necessarily disagree, it’s just not clear to me who’s at fault here:

  • is it openfortivpn for not getting some selinux setting right,
  • is it a selinux policy (but then running it manually should have the same result)
  • is it systemd somehow initializing the process incorrectly
  • but what no AVC? I think the primary bug is that combination of denial and there’s no AVC

I’m not at all clear on the difference between systemd starting it as root and my starting it manually via sudo. I always thought that
this would be much the same, given the trivially simple unit file. This intrigues me alot, and I think I will have to learn more about that.

Thanks for your ideas,

Mike

12

What did you do to check for AVC:s? I’m asking since I have myself been similarly confused. I used ausearch -m avc … and did not got anything. Later on, I realised there were “user AVC:s”, but they didn’t show up when I ran the above command. When I finally found out I could also run ausearch -m user_avc …, or without any -m flag at all, I got the explanation. Maybe you are hitting something similar?

13

Actually, I usually use audit2why or check the AVCs in cockpit. I also scan the /var/log/audit/audit.log manually. I rarely use ausearch unless I already know what I’m looking for.