Possibility to set a custom dns server via command flag

[tuxBurner]

Sometimes you want to set a custom dns sever, because the ones provided from the fortigate are not sufficiant.

The flag could be like this: --use-dnsServer=10.0.0.3 This will lead to, that the dns server is set at the top of the resolv.conf before the other dns server provided by the fortigate server.

[DimitriPapadopoulos]

Should we really make it easy to bypass the company policy? My feeling is that this is very specific and best left to a an ip-up script. But that's only me.

What is the use case? Why would the DNS server pushed by the FortiGate device not be sufficient?

[mrbaseman]

I feel the same. There are a couple of ways to influence how /etc/resolv.conf is updated. We support resolvconf now, there is the possibility to use a pppd ip-up script, when using networkmanager it can be configured there I think (unless you have several different vpn clients that use the same interface name), or just call openfortivpn with --no-dns and call it from a wrapper script that also takes care of the resolv.conf file.

[tuxBurner]

Well sometimes you have a vpn where you don't get a dns server from the other side provided. Mostly i see people polluting there /etc/hosts with entries to get a "name resolving".

This is not a good way IMHO because often you have virtual hosts which than have to be added individually.

So i created a dnsmasq server which the people can use but this ends at the moment in the workflow:

open vpn edit /etc/resolv.conf

[lfuelling]

IMO this is a quality of life improvement to allow people that are less used to configuring Linux networking by themselves. Like with everything you should of course ask your system administrator if this violates a company policy (I have yet to find the policy you refer to, doesn't every company has their own?)

Regarding the use-case, it actually is a company policy that there is no DNS provided in the VPN and usually we use the hosts file to manage name resolving in the VPN. The addition of the DNS came out of necessity due to new/changed IPs which caused a lot of overhead due to everyone having to keep their hosts file up to date.

More specifically, if you aren't allowed to reconfigure networking by yourself, you can't add the ip-up script so the DNS option (imo) is the most efficient choice because the DNS can be managed by the ones knowing the current adresses and any change can quickly (instantly) be provided to all clients using this setting.

[DimitriPapadopoulos]

@lfuelling Yes, I meant to say "the policy of the company that runs the FortiGate appliance". My guess is that the company IT security guys expect the network setup they push to end-users to be enforced by the VPN client. If the end-user wants to change the default setup, so be it. But then should openfortivpn help them?

Now back to the use-case, can you help understand it better? I understand the computers you use have a default setup. Does the default setup use a DNS server in /etc/resolv.conf? Then how is that default setup not suitable for use when the VPN is up? Do you try to access machines behind the VPN that are not referenced in the default name resolution setup (be it a DNS server or a hosts file)?

Finally I'm working on openfortivpn in my free time. Insensitive mocking about a/the errors (?) won't get me more interested in the use-case - on the contrary I'd say.

[DimitriPapadopoulos]

@tuxBurner Not certain whether @lfuelling works for the same company as you (my guess is that he is and that he shares the same use case hence the emotional intrusion). If not can you please explain your own use case? Is there a DNS server in the default (pre-VPN) setup of your computer or just a hosts file? How is that default setup not suitable for use when the VPN is up? Is that because you try to access new machines behind the VPN appliance that are missing from the default setup?

[lfuelling]

In some cases the IT guys that run the appliance don't manage the network the VPN is connecting to, so there are actually two policies active that have to be made compatible. The VPN connects to a network that (per policy) has no DNS because there are other systems. We only know/manage the IP addresses of the machines we (need to) know. Also, there might be multiple networks the appliance can connect to, so letting the IT guys push a single DNS would allow people from other teams see stuff they don't need to see which imo is a potential enumeration vector for conceptual intruders. Regarding the DNS advertised by DHCP, this manages only internal domains, managing the foreign domains with this would bring up the same issue as the "unified" DNS..

I'm sorry if the bold formatting seemed insulting I actually just wanted to get the wording straight to be sure that you didn't mean that there is a policy enforced by Fortinet (the company) that I just didn't know about. (Maybe italic would have seemed less "emotionally intrusive" in that case?)

We actually have multiple simultaneous setups running, some directly on the host os, some in Docker, some on embedded systems, the hosts file is just used in a few of them.

[DimitriPapadopoulos]

Please bear with me while I'm rephrasing to make sure I get it.

So there's a LAN or multiple LANs behind the FortiGate appliance with servers for different “customers”. The IT team who manage the FortiGate appliance have decided not to provide DNS resolution for these servers, be it for security reasons or because they have no knowledge of the LAN behind the appliance or maybe in a different use case because their “customers” need to manage hostnames themselves . Hence the FortiGate appliance does not push a specific DNS server to VPN clients. So far so good. Adding a DNS server somewhere else would indeed not violate any policy, the policy being that “DNS is not provided”, not that “it is forbidden to resolve the servers using an alternate DNS”.

Now what about the remote computers? I understand they are managed by a different IT team who do provide a DNS, but limited to name resolution for local domains. Just out of curiosity, why tasking this local DNS with resolving the servers behind the FortiGate appliance “would bring up the same issue as the "unified" DNS”? Here “customers” share the same DHCP, are there actual issues sharing the same DNS? I do appreciate the setup is complex and that it might not be possible to explain everything. Just wondering.

In any case it's clear there is no “company policy” problem here. Let's forget that.

It's just that I feel openfortivpn mostly mimicks FortiClient and provides basic services such as applying the network setup pushed by the FortiGate appliance. I'd rather avoid feature bloat and leave it to up/down scripts to handle more complex use cases.

If “customers” have been able to handle name resolution with /etc/hosts so far, couldn't they deploy up/down scripts that would switch DNS servers during VPN operation? Would it help if we could provide example script in the openfortivpn wiki? Or distribute sample scripts with openfortivpn?

[DimitriPapadopoulos]

Also there is a company policy issue here, although not in your use case. Indeed a side effect of this option would be that end-users could very easily switch to Google or 1.1.1.1 DNS, thus bypassing company policy. I feel a little bit uneasy with that.

[lfuelling]

So there's a LAN or multiple LANs behind the FortiGate appliance with servers for different “customers”. The IT team who manage the FortiGate appliance have decided not to provide DNS resolution for these servers, be it for security reasons or because they have no knowledge of the LAN behind the appliance or maybe in a different use case because their “customers” need to manage hostnames themselves . Hence the FortiGate appliance does not push a specific DNS server to VPN clients. So far so good. Adding a DNS server somewhere else would indeed not violate any policy, the policy being that “DNS is not provided”, not that “it is forbidden to resolve the servers using an alternate DNS”.

That's about right. The reason no DNS is in the network we connect to is probably that the DNS would also show more machines than we need to know about since there are multiple service providers connecting to that network.

Just out of curiosity, why tasking this local DNS with resolving the servers behind the FortiGate appliance “would bring up the same issue as the "unified" DNS”?

This would be because members from other teams could see the machines that all other teams could see. While they would be unable to connect due to the different networks they're connecting to, some domains might give away information that the other teams don't need to see.

I'd rather avoid feature bloat and leave it to up/down scripts to handle more complex use cases.

That's understandable, imo that feature is more useful than bloaty but as maintainer the final decision is up to you.

If “customers” have been able to handle name resolution with /etc/hosts so far, couldn't they deploy up/down scripts that would switch DNS servers during VPN operation?

Of course they could but that would mean creating the scripts on every system that uses VPN while the command line argument approach only would need a change in the script we use to run openfortivpn on nearly all setups.

Indeed a side effect of this option would be that end-users could very easily switch to Google or 1.1.1.1 DNS, thus bypassing company policy.

Yes, that is of course possible, but (again imo) this applies to the "no warranty" clauses of the license.

[DimitriPapadopoulos]

Just out of curiosity, why tasking this local DNS with resolving the servers behind the FortiGate appliance “would bring up the same issue as the "unified" DNS”?

This would be because members from other teams could see the machines that all other teams could see. While they would be unable to connect due to the different networks they're connecting to, some domains might give away information that the other teams don't need to see.

I see. I work myself in an environment very much focused on security, but compartmentalizing DNS within networks that share the same DHCP I had never seen. But then why not?

If “customers” have been able to handle name resolution with /etc/hosts so far, couldn't they deploy up/down scripts that would switch DNS servers during VPN operation?

Of course they could but that would mean creating the scripts on every system that uses VPN while the command line argument approach only would need a change in the script we use to run openfortivpn on nearly all setups.

True, it's probably much easier to share a single script than install multiple scripts in multiple locations on each computer, with the up/down scripts installed in system-wide locations.

That said, is it not possible to have the script that starts openfortivpn modify /etc/resolv.conf or run resolvconf itself? Perhaps /etc/resolv.conf can be modified prior to starting openfortivpn and you could use trap to clean up.

Indeed a side effect of this option would be that end-users could very easily switch to Google or 1.1.1.1 DNS, thus bypassing company policy.

Yes, that is of course possible, but (again imo) this applies to the "no warranty" clauses of the license.

True, on the other hand the "no warranty" clauses don't mean we don't take that into account.

[mrbaseman]

@lfuelling Our DNS at work serves different networks, depending from where you query it. Our case is quite simple: Public IPs are served unconditionally, whereas private networks are served only if the query comes from one of the internal (public or private networks). I'm quite sure this approach can be extended to a more general use case with different policies for several subnets associated per customer. That would open up the possibility to push that DNS through the VPN and let it answer differently for each customer. This approach of course implies, that there is a separate IP range for the VPN clients of each customer. They can be assigned either manually, per user, or by matching the group which the user is associated to e.g. in an LDAP directory, and the IP range as well as the firewall rules are tied to this group. Sure, this is a complex mechanism, but that's what I would consider appropriate for the complex landscape behind the VPN. Moreover, if you match users to specific groups in the VPN configuration, you could also push different DNS servers for each group and also allow them to connect only to the networks that they need. It's all a lot of effort to set up and to maintain the network infrastructure in such a complex environment, but honestly, imo, providing a DNS that serves all the networks would be better than just providing no DNS at all and letting the users alone with the problem of proper name resolution. That results in the situation which you describe: Everyone is maintaining his own hosts file, each of them different, none of them complete and for sure not up to date. Anyhow, I agree with @DimitriPapadopoulos that it would make not a big difference for the script that calls openfortivpn also to take care about resolv.conf or to pass the option to openfortivpn. Sure, it has to do something with elevated privileges before calling openfortivpn, but at least when it comes to the point to start the VPN tunnel, those privileges are needed anyway.