DNS servers not added to resolv.conf about openfortivpn

[adrienverge]

If the new nameservers are already present in /etc/resolv.conf, openfortivpn doesn't add them, and doesn't remove them on shutdown neither. Is that what's happening? What do the -vvv logs say?

[paride]

Hi @adrienverge,

I have to partially correct my original report. Before running the VPN client my resolv.conf is:

# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 8.8.4.4

The proprietary client modifies it in this way:

nameserver      10.10.0.4
nameserver      10.10.0.1
# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 8.8.4.4

while here is what openfortivpn does:

nameserver 10.10.0.4
nameserver 10.10.0.1
# Generated by NetworkManager

I think that what the proprietary client does is better, because if the VPN nameservers fail to resolve an address the resolver falls back to the original ones. The debugging output is just what you may expect:

INFO:   Adding VPN nameservers...
DEBUG:  Nameservers already present in /etc/resolv.conf.
INFO:   Tunnel is up and running.

Thank you!

[adrienverge]

I'm not sure I understand: from the /etc/resolv.conf contents you pasted it looks like openfortivpn deletes nameservers that were already there (8.8.8.8...). Is this really happening?

The intended (and expected) behavior is as follow:

• check if VPN nameservers already present
• if not, add them on startup and remove them on shutdown
• never, ever remove other nameservers (such as 8.8.8.8)

By the way, if you are using Network-Manager, you should try NetworkManager-fortisslvpn. It uses openfortivpn as backend but handles routes and nameservers more cleanly.

[paride]

@adrienverge yes, openfortivpn deletes the existing nameservers. When I kill openfortivpn I find them back in place. Thanks for pointing me to NetworkManager-fortisslvpn.

[adrienverge]

Hi @legovini,

The debugging output is just what you may expect:
DEBUG: Nameservers already present in /etc/resolv.conf.

and

When I kill openfortivpn I find them back in place.

really seem contradictory. If the DEBUG line is printed, this means tunnel->ipv4.ns_are_new is set to 0 (see code here). And if tunnel->ipv4.ns_are_new == 0, function ipv4_del_nameservers_from_resolv_conf() returns immediately (see code here) so it shouldn't even put them back when exiting.

So, I'm wondering if it's really openfortivpn that edits your /etc/hosts (could it be pppd?). Can you add some log_info() in functions ipv4_add_nameservers_to_resolv_conf() and ipv4_del_nameservers_from_resolv_conf() just to see what logic path is walked?

[paride]

Hi @adrienverge,

I will try to get some more debugging output to figure out what's happening. What I can tell you now is that with 7dca981 this does not happen: /etc/resolv.conf is left untouched if something is already in there. With the latest code in the master branch the behavior is the one I described.

I think that the right thing to do here is to emulate what the proprietary client does: adding the VPN dns servers on top of resolv.conf, and cleaning it on exit, even if some nameservers are already configured.

[adrienverge]

@legovini I'm not convinced emulating the proprietary client is the right thing to do. What if you start openfortivpn (it adds two lines at the top of /etc/resolv.conf), then run any program that also edits resolv.conf (NetworkManager does this regularly, for instance), and quit openfortivpn? There's a chance it does not remove the correct lines.

I'd rather keep the openfortivpn's original behavior (that was broken somewhere between 7dca981 and 5e5c25d).

[paride]

@adrienverge I played a bit with the proprietary client and it seems that it restores the initial version of resolv.conf, instead of deleting some specific lines. In this way resolv.conf is not messed with, but changes made while the VPN is running are lost when the client quits.

Another idea is to remove the lines containing the specific IP addresses added by openfortivpn, regardless of their position (and if they're still there). This seems a more robust solution.

[adrienverge]

Another idea is to remove the lines containing the specific IP addresses added by openfortivpn, regardless of their position (and if they're still there). This seems a more robust solution.

Yeah, that's what openfortivpn does (or at least, is supposed to do).

[paride]

@adrienverge OK, I understood quite a few things. It is pppd that adds the nameservers to my /etc/resolv.conf, as it is called with the usepeerdns option (set in tunnel.c). This is documented in pppd(8). It does this before openfortivpn calls ipv4_add_nameservers_to_resolv_conf(), so this function never actually modifies the resolv.conf. Unfortunately pppd does not preserve the previous nameservers, so this is not optimal.

I tried to remove the usepeerdns option, hoping that pppd wouldn't touch the resolv.conf, letting openfortivpn do it. The problem is that without that option tunnel->ipv4.ns1_addr is not set (if I print it I get 0.0.0.0), so this is not a solution.

[adrienverge]

@legovini Nice catch!

On my machine, pppd does not touch /etc/resolv.conf. From what I read in the man page, you might have a bad /etc/ppp/ip-up script: have you tried modifying/removing it? When pppd is running, is the content of /var/run/ppp/resolv.conf valid?

[paride]

@adrienverge I found the script that does the actual change: it is /etc/ppp/ip-up.d/0000usepeerdns. This may be specific to Debian and derivatives.

[adrienverge]

Great! I'm glad to hear it! Is this script also responsible for bad routes?

[paride]

@adrienverge I don't think so, there's nothing about adding/removing routes in /etc/ppp/. I see that openfortivpn calls pppd with the nodefaultroute option, so I don't think pppd is involved in #25.

A note about the issues I opened (this and #25): I will be away from civilization until early February 2016 (working here: https://en.wikipedia.org/wiki/Concordia_Station), so if I don't reply it's not because I've lost interest.

[adrienverge]

@legovini Alright! Say hi to penguins ;)

[mrbaseman]

I'm just going through the older tickets. There were quite some changes to the routing code in the last months, and #25 has been solved.
We also had a discussion about ip-up scripts recently. On Ubuntu they come with the openresolv package. If you want resolvconf not to do any changes, you can set an option 'resolvconf=NO' in /etc/resolvconf.conf (not sure if this is actually what you want, but I have the impression this might be at least a direction to look at).

[paride]

Hello @mrbaseman, at the moment I don't have access to a Fortinet VPN anymore, so I can't test the updated client and give you a meaningful feedback. A lot of things changed since I opened this issue, so it could be fixed already, or not relevant anymore. I'll close it for now.