VPN connection should alter /etc/resolv.conf

[Crispin Flowerday]

I am using the 0.6.1-0ubuntu4 package, and have compiled up the openvpn vpn service so that I can connect to my company network. Connecting to the VPN works fine, however /etc/resolv.conf isn't altered as I would expect.

When connected to the VPN it should /etc/resolv.conf should be altered to use the settings provided by the VPN rather than by the DHCP server. This allows browsing the company intranet to 'just work' rather than having to manually add lots of entries into the /etc/hosts file.

[Thomas Hood (jdthood)]

One way to add this functionality cleanly would be to make openvpn provide the nameserver info to resolvconf and to use the resolvconf package.

[Scott James Remnant (Canonical) (canonical-scott)]

I've never EVER seen resolvconf working; it's going in main over my dead body <g>

[Soren Hansen (soren)]

Personally, I think the energy would be better spent and the effort better divided if we focus on fixing the resolv.conf generating code in network-manager.

If this issue was fixed, we might even be able to include the three vpn plugins from the networkmanager CVS. I've already packaged them for myself but they depend on a patched version of networkmanager to work properly, so there really hasn't been any point in uploading them to the universe.

[Luka Renko (lure)]

As VPN is not in Dapper yet, this can be only Wishlist.

Soren, what kind of patch is needed in n-m to make it work?
I know that Tonio has put openvpn and vpnc packages to http://kubuntu.no-ip.org test repository and that at least openvpn is working fine for him (with knetworkmanager) with stock n-m/knm from Dapper.

[Soren Hansen (soren)]

I know VPN wasn't a goal for Dapper. Nevertheless, the effort to get it in seems so small to me that I feel it'd be silly not to enable it.

The patch needed to make it work is REALLY simple. In the latest versions of network-manager, the backend code defines a function called nm_system_should_modify_resolv_conf which in the Ubuntu version simply returns FALSE. I've changed it to return TRUE. :-)

Of course VPN connectivity will work without this patch if you can use your VPN connection without altering the DNS settings.. I just can't.

[Richard Ferguson (ufergus)]

What are the main reasons behind not enabling the 'modify_resolv' flag? If someone doesn't install the extra vpn packages, would they ever execute this section of code? If not, what is downside of enabling this flag for those who use the vpn packages?

[Soren Hansen (soren)]

The code is executed for all new connections, ie. also regular wired or wireless connections, so it doesn't just affect VPN connections. Apparantly, the code has exhibited some weird behaviour in the past so people find it safer to leave it disabled rather than fixing it.

[Scott James Remnant (Canonical) (canonical-scott)]

Because dhclient modifies resolv.conf itself, so there's no reason to have NM do it as well (which causes huge numbers of problems, anyway).

[Soren Hansen (soren)]

scott: Well, not except for VPN support which is b0rken when NM doesn't handle it. :-)

[Scott James Remnant (Canonical) (canonical-scott)]

VPN support was not a goal for dapper, indeed we expliclty decided that we wouldn't support it yet.

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

It does seem that the network-manager currently in edgy (0.6.3-2ubuntu3) does alter the resolv.conf itself, and so vpn conections get it correctly altered. Although I don't know if this is an accident or by design ...

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

0.6.3-2ubuntu4 is back to not altering resolv.conf so its back to patching the package to get VPN support working nicely.

Out of interest what are the "huge problems" that happen if NM is used to modify resolv.conf rather than dhclient? The only problem I have come across is that if the dhcp lease is renewed while connected to the VPN resolv.conf gets re-written away from the VPN settings - that could be solved by stopping dhclient from updating resolv.conf though.

[Gabriel Bauman (gabrielbauman)]

The resolvconf package has always worked as expected for me in Ubuntu.

Scott, surely one interface to modify resolv.conf is better than lots of packages separately parsing it and modifying it? Plus you get scriptable events generated on changes, and some other freebies.

The package has been around for a while and works well. I'd like to see it used by NetworkManager's VPN support. Are there any technical reasons *not* to use the package, beyond your bad experiences with it?

[Scott Robinson (scott-ubuntu)]

Is this bug basically asking for VPN connection support? (One that is properly integrated and tested)

If so, shouldn't it be marked as a duplicate of bug 37110?

[Eddie Hung (eddieh)]

I'm using the latest Feisty version with NetworkManager and the PPTP VPN plugin. When USEPEERDNS is selected, NM edits /etc/resolv.conf with DNS server of the server I'm connecting into, which if I'm not mistaken is desired behaviour. However, when USEPEERDNS is not selected, NM does not fill /etc/resolv.conf with anything, as a result I am left with no DNS, and I need to manually echo my gateway into resolv.conf to get it back. I'm not sure I fully understand the issue here, but I hope this helps, and hopefully someone else can shed some light onto mine! I understand that the /etc/ppp/ip-up.d/0000usepeerdns script is only executed when USEPEERDNS is selected, and when this happens some resolv.conf backups appear in /etc generated by pppd, but when it is not, no such files appear. From this, I gather that ppp is not updating resolv.conf, and if this is intended, then NM should be instead. And by now, not even I have any idea whether or not I'm making sense anymore! =)

[Soren Hansen (soren)]

Network-manager does this now. Yay!

[Eddie Hung (eddieh)]

Ok, let me try again!

If I do not select USEPEERDNS and open a VPN, then /etc/resolv.conf will be empty (except for the "# generated by NetworkManager, do not edit!" header). I believe this is not correct: the existing DNS server should be kept. However, it behaves as expected when USEPEERDNS is selected. Is this the issue you're seeing here?

If the answer is yes, then I am still seeing the issue on the latest Feisty NM.

[sebek (sebeeek)]

I have the same problem than Eddie with stable feisty release and network-manager-pptp

When I am NOT connected to the VPN, my /etc/resolv.conf is :
# generated by NetworkManager, do not edit!
search ndomain.XXXXX.XXX
nameserver XX.XXX.XXX.XX
nameserver XX.XXX.XXX.XX

When I am connected to the VPN with option "peer DNS through tunnel" /etc/resolv.conf looks like this :
# generated by NetworkManager, do not edit!

I think normal behaviour should be :
when I am connected to the VPN with option "peer DNS through tunnel" /etc/resolv.conf should look like this :
# generated by NetworkManager, do not edit!
search ndomain.XXXXX.XXX
nameserver XX.XXX.XXX.XX
nameserver XX.XXX.XXX.XX

[Eddie Hung (eddieh)]

Hi sebek: are we contradicting each other? I seem to rememeber that when USEPEERDNS is selected, my DNS server is that of the remote network (which I believe is correct behaviour?), but when it is not selected, resolv.conf is empty bar the header: which is not correct - it should be the DNS server of your current network (i.e. as it was before you started the VPN). I haven't got Ubuntu at hand at the moment, so cannot double check, but I'm fairly sure this is the case for me?

[sebek (sebeeek)]

Hi Eddie,

I may have been unclear, but we have same problem

My VPN server doesn't have any DNS server set.

When I am connected to the VPN with USEPEERDNS :
# generated by NetworkManager, do not edit!
(which is normal)

When I am connected to the VPN without USEPEERDNS :
# generated by NetworkManager, do not edit!
(which is not normal, it should be my normal connection DNS)

So I believe we agree, and it looks like a bug.

[Eddie Hung (eddieh)]

Ahh, ok then. I got a little confused because you said "When I am connected to the VPN with option "peer DNS through tunnel" /etc/resolv.conf looks like this : ..." - stating that it was not behaving as expected when USEPEERDNS was selected! I don't understand what the procedure is for this, but can/should I change the status to "Confirmed", or anything but "Fix released"? Could all other subscribers confirm whether this is the issue they've been seeing, and whether indeed it has been fixed for you?

[Mark Stosberg (markstos)]

For me, this was a regression in Feisty: before, the VPN connection works fine, and now it quits working while connecting to the VPN because /etc/resolv.conf is getting cleared out. I like the proposed solution of leaving /etc/resolv.conf alone when "use peer DNS" is not selected.

[Brian Pitts (bpitts)]

I can confrm this bug on Feisty with the OpenVPN plugin. The nameservers should not be altered if "use peer DNS" is not selected, but they are deleted.

[Diego Cortassa (diego-cortassa)]

Same here on feisty using PPTP if "User peer DNS" is unselected my resolve.conf is emptied... was working on dapper.

[Przemyslaw Kwiatkowski (micha-micha)]

Same problem here with network-manager (0.6.4-6ubuntu7) and network-manager-openvpn (0.3.2svn2342-0ubuntu3).
Do you remember what is the last version, witch worked fine?

Is it possible to force Network Manager not to update resolf.conf at all? If so, I could simply install local dns cache...

[Krešimir Tonković (kresimir-tonkovic)]

I'm using NM 0.6.4-6ubuntu7 and network-manager-openvpn 0.3.2svn2342-ubuntu3, and have the same problem that sebek has. However, The openvpn configuration editor doesn't have a "use peer dns" setting. I think that, if the "Only use this VPN connection for these addresses" is selected, the peer DNS should be just added to the list in resolv.conf. If the VPN is used for all networking, it's DNS should be the only one in resolv.conf.

[Rodrigo Virote Kassick (kassick)]

I was looking into the code of network-manager-openvpn and the vpn-manager in nm;

It seems that the openvpn plugin receives the dns server list (in my case, there are none) and adds them to the config struct. vpn-manager later discards the old ip4_config and uses the new one, which has no dns, and then resolv.conf is generated empty.

What would be a good policy for servers in the resolv.conf generated when a vpn is active? I thought of

1 - servers in "prepend-domain-name-servers" in dhclient.conf
2 - if the vpn is not the default route, the servers received by the active interface's dhclient
3 - servers received by the vpn plugin

[ibbrowne3 (browne-allen)]

I am also having the stated issue. Using Feisty Fawn and the Network Manager pptp vpn plugin.
Unchecking usepeerdns does nothing.

[Nic Hanno (nichanno)]

Yes, i'm having this trouble too...

When USEPEERDNS is ticked, /etc/resolv.conf is populated with DNS servers provided by DHCP server on network that i'm connecting via VPN to.

When USEPEERDNS is NOT ticked, /etc/resolv.conf gets wiped out rather than just leaving them intact.

[praz (prasanna-intertalk)]

I have just switched from another distro. I've just installed 7.04 could be Feisty, can't tell. Has this bug will be fixed? If so where can I get the patch? Because at the moment I have to copy the old resolv back once I've started vpn.

[wedge (nobodyhome)]

Same problem here. Any chance this will get off of the wishlist and get a higher priority?

[Alexander Sack (asac)]

is this still an issue in gutsy network-manager?

[Eddie Hung (eddieh)]

NM VPN is currently broke on Gutsy: https://bugs.launchpad.net/bugs/122293

[Fabián Rodríguez (magicfab)]

Changing to medium, as this affects an important functionality of Network Manager.

[Fabián Rodríguez (magicfab)]

NM in Gutsy has been fixed. Can anyone reproduce this in Gutsy ?

[Craig Robson (craig-zhatt)]

I see this in Gutsy with network-manager 0.6.5-0ubuntu11 and network-manager-pptp 0.6.5+svnhead2574-0ubuntu1.

USEPEERDNS is unselected and resolv.conf ends up with no settings.

[Pirx (tkruemmer)]

This issue exists in Gutsy. Any idea how to fix it?

[Pirx (tkruemmer)]

To be precise: network-manager does write the VPN DNS to the resolv.conf file, however, the networked programs stil try to use the original DHCP assigned DNS, not the one in resolv.conf.

Any input/idea would be much appreciated.

[Jeff Sharpe (jeffsharpe)]

I haven't looked at the source (yet) but off the top of my head; option within the vpn gui to append or overwrite DNS, or just append the vpn DNS info (removing on disconnecting of vpn). It is currently overwriting now.

[Pirx (tkruemmer)]

Thanks for your quick reply.

You get me wrong: network-manager OpenVPN plugin does exactly what it is supposed to do and enters/overwrites the VPN's DNS server into resolv.conf. That is 100% of what it should do (for me).

But, with network-manager having done that, fire up Firefox and get a server not found error. That is certainly, because Firefox does not access the correct DNS server in resolv.conf

The exact same is the issue with Evolution, server not found.

Somewhere something needs to refresh after network-manager has written the correct DNS to resolv.conf, so that the network apps like Firefox try to resolve DNS with the DNS server in resolv.conf

Kindly advise what your thoughts are. Thanks!

[Gavin McCullagh (gmccullagh)]

Hi,

On 04/10/2007, Jeff Sharpe <email address hidden> wrote:
>
> I haven't looked at the source (yet) but off the top of my head; option
> within the vpn gui to append or overwrite DNS, or just append the vpn
> DNS info (removing on disconnecting of vpn). It is currently
> overwriting now.

I don't think an append option is all that useful to be honest. If you have
two different dns servers (eg one for the real world and one for an internal
network) and ask whichever is first server it'll either give you an answer
or tell you the domain doesn't exist at which point it'll give up. You'd
need to run a proper dns server to have domain-specific lookup rules.

What I think is needed is to have an option to either modify DNS to follow
the VPN or not. Ideally, if the VPN doesn't give any DNS servers, the old
ones should be automatically preserved.

Gavin

[Rodrigo Virote Kassick (kassick)]

On 10/4/07, Pirx <email address hidden> wrote:
>
> Thanks for your quick reply.
>
> You get me wrong: network-manager OpenVPN plugin does exactly what it is
> supposed to do and enters/overwrites the VPN's DNS server into
> resolv.conf. That is 100% of what it should do (for me).

OpenVPN can be configured to enable users to connect to some other network
without overriding the users default route, domain settings, etc.

I have a setup in wich we enable access to some servers only via openvpn,
but we don't wanna route all users traffic thought this network -- why on
earth I would route the user's gmail through the servers network?

But, with network-manager having done that, fire up Firefox and get a
> server not found error. That is certainly, because Firefox does not
> access the correct DNS server in resolv.conf
>
> The exact same is the issue with Evolution, server not found.
>
> Somewhere something needs to refresh after network-manager has written
> the correct DNS to resolv.conf, so that the network apps like Firefox
> try to resolve DNS with the DNS server in resolv.conf
>
> Kindly advise what your thoughts are. Thanks!
>
> --
> VPN connection should alter /etc/resolv.conf
> https://bugs.launchpad.net/bugs/37239
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Rodrigo Virote Kassick
(kàzic/paiacan)
------------------------------------------------------------

[Pirx (tkruemmer)]

Sorry, I am so bad at explaining. I know there is the option of going to some IPs through the VPN, others open, or vice versea.

I am sitting behind the Great Firewall of China, which is run by what may well be the worlds most paranoid censors outside North Korea (which banned the Internet and moble phones altogether), who sometimes even block weather.com, who log all in- and out emails and chats, blogs, whatever, block news by keywords and sometimes even block their own sites from being accessed by the rest of the world. I hope you get the picture.

So I want all, absolutely every single packet to go exclusively and only through the VPN. No options wanted, particularly not local domain servers.

Under Feisty network-manager OpenVPN did just that. All packets went through the VPN, the DNS in resolv.conf was replaced by the VPNs and everything was wonderful.

Now, under Gutsy, OpenVPN still does its job as before, but the domains do not resolve anymore. That is the issue.

[Jeff Sharpe (jeffsharpe)]

Hey Pirx.

As far as I can tell, and what you are describing, the routing works correctly for me (using pptp) - it adds a route for those ips through the new vpn interface (but not all packages). This is how I need it - I don't need all connections routed through my host.

DNS is what appears to be the bug.

[Lox (gecka)]

I have the problem with an up2date gutsy. /etc/resolv.conf get wiped out.

[Markus Vuori (lite-deactivatedaccount)]

I'm runnign up2date gutsy. VPN connections work well with networkmanager-openvpn and resolv.conf gets modified...

BUT

after a while dhclient(?) comes and overrides the modifications made by network-manager-openvpn. I mean, my openvpn server sends the dns information and networkmanager-openvpn gets it and makes modifications correctly. However the modifications are not permanent and get overwritten by dhclient(?) who supposedly gets dns information from other sources.

[Kyle Gordon (kylegordon)]

Hi,

I am experiencing similar issues with /etc/resolv.conf

When connected normally to wireless, I have the correct search domain and nameserver parameters in /etc/resolv.conf.

However, when the system connects to my OpenVPN server, there is nothing present in /etc/resolv.conf bar the regular "# generated by NetworkManager, do not edit!" comment. After this point, I am unable to complete any DNS requests.

Disconnecting from the VPN, but staying connected to wireless results in /etc/resolv.conf being repopulated with the correct data.

My OpenVPN server specifically does not push out any DNS data, as all relevant hosts are in /etc/hosts. If it did, I would expect NetworkManager to put in additional DNS entries instead of removing them altogether. Maybe different DNS priorities should be available for individual circumstances.

Regards

Kyle

[Pirx (tkruemmer)]

Alright, I can connect through a PPTP connection on Gutsy. So far so good. But, domains do not resolve.

[Viktors Petrovs (viks77)]

On Gutsy when i connect through a PPTP to remote network and USEPEERDNS is unselected, /etc/resolv.conf gets wiped out.
This issue exists in Feisty and in Gutsy too.
I have made patch to correct this by simply not to update resolv.conf (leave intact) when there is no name servers returned by DHCP.
Now PPTP is working for me correctly (as i expect).

[Viktors Petrovs (viks77)]

Same patch using a Unified diff format (ie, diff -u).
Sorry if i'm doing something wrong...
This is first time when i'm posting patches...

[Alexander Sack (asac)]

this is currenctly discussed upstream at:

http://mail.gnome.org/archives/networkmanager-list/2007-October/msg00166.html

i will revisit this bug when upstream has come up with conclusions.

[Stephen Gornick (sgornick)]

Because the current issue (no name services at all when Use-Peer-DNS is unchecked) is different from the original issue, shouldn't further discussion about this peer-dns issue occur on a separate bug report?

Bug #109108, titled "Network Manager VPN Connection blanks /etc/resolv.conf" specifically addresses the current peer-dns issue however it has been marked as a duplicate of this bug.

Shouldn't Bug #109108 be removed as a duplicate of this bug and then this bug be marked as Fix Released (as the original issue appears to have been resolved)?

[Justin Bowes (daft-angus)]

I know this idea has been shot down already (long ago), but if I install resolvconf, this "just works."

[Piotr R. Sidorowicz (prsidoro)]

I have the same problem as Marcus in Gutsy:
... networkmanager-openvpn and resolv.conf gets modified...
BUT
after a while dhclient(?) comes and overrides the modifications made by network-manager-openvpn...

It is quite obvious as the NetworkManager changes to the resolv.conf file have a distinct comment.
I was under the impression that dhclient can be run with an option such that is doesn't modify the resolv.conf file.
Perhaps re-starting dhclient with that option after vpn is established would do the trick; do the same w/o the option avter vpn is terminated.

I have another related issue with NetworkManager and VPN (perhaps the nm-applet as well).
If one chooses to use manual settings, the vpn menus disappear. This doesn't make sense. One should be able to use static settings and vpn together. This would also render the above-mentioned dhclient issue moot, as dhclient should not be running and interfering with /etc/resolv.conf

[Tom Verdaat (tom-verdaat)]

I've read the thread and concluded that I think we might be talking about several different bugs which appear alike but might have to be split (disclaimer: i am not a programmer so I'm not sure!). The things I've read about:

1) Which DNS servers (resolv.conf) and routes NM should set for:

1A) A VPN connection through which ALL traffic should be tunneled. (= nameservers in resolv.conf should be replaced by those obtained from the VPN server and the default route should refer traffic to the tun/tap interface)

1B) A VPN connection through which traffic only for specific IP ranges, like for example 192.168.1.x/24, should be tunneled. (= no nameserver changes, only update routes to refer all traffic for those IP ranges to the tun/tap interface)

2) If NM rightfully sets resolv.conf (for example due to new DNS servers from the VPN connection) the dhcp client should be prevented from overwriting resolv.conf when updating the lease. (e.g. all resolv.conf setting should be managed by NM when used).

------

I can confirm one bug, being the OpenVPN bug on the latest Gutsy:

Trying to do the 1B thing and as soon as i connect, resolv.conf gets updated to only containing the line "# generated by NetworkManager, do not edit!". As soon as I disconnect VPN, resolv.conf contains the proper nameservers provided by the fixed network's dhcp server again.

I've also got a Windows VPN (PPTP) connection which is also only supposed to reroute traffic for a specific IP range and that works fine. To me this means that this is an OpenVPN-plugin specific bug.

[Kyle Gordon (kylegordon)]

Hi Tom,

I can confirm this is the bug I was attempting to report on. The fault is also present in Hardy, with network-manager-openvpn 0.3.2svn2342-1ubuntu4 and openvpn 2.1~rc4-2

Regards

Kyle

[Eddie Hung (eddieh)]

Good clarification Tom.

I've a few things to add:

- It could be argued that (2) is part of (1) - because it is NM that spawns the DHCP daemon, and so it could be said that it's NM's responsibility to make sure that DHCP doesn't upset the VPN plugin functionality, which incidentally, is also part of NM.

- I would like to just point out an oversight in (1B) - what if you were connecting to a LAN with private hostnames resolved by a private DNS server? What you would want there is for the DNS servers to be appended to those that already exist.

I currently suffer from scenario (1A) - and as someone has already stated before me, the workaround I am using is to add a "append domain-name-servers 123.456.789.ABC;" line into /etc/dhcp/dhclient.conf - so that whenever the DNS lease is renewed, the IP address 123.456.789.ABC is appended onto the end of whatever it was going to write into /etc/resolv.conf - and so my connection won't break.

Ideally, the solution would be for NM to be the sole manager of /etc/resolv.conf - and so it can arbitrate between VPN/PPP and DHCP.

I read somewhere that NM 0.7 does away with using the current DHCP daemon.. which may or may not alleviate the problem. Anyone know?

Eddie

[x2q (x2q)]

Hello,

I experienced what Tom described as scenario 1B with a plain Ubuntu 7.10.

It really bothers my if Kyle is right ;(

[Pirx (tkruemmer)]

Well, since recent auto-updates and some playing with Firestarter, wireless vpn connections work fine through NM. Disabling the firewall seems essential for the VPN connection to work..... For wired vpn connection I use the OpenVPN config GUI, which also works fine. I could imagine that cleaning out resolv.conf contents is a measure to avoid accidential DNS calls outside the tunneled connection, with resulting breach of security. NB: I am no programmer either, just a VEP.

Best wishes for a happy new year,
pirx

[x2q (x2q)]

I found a workaround - ugly, but it works.

I installed dnsmaq, which is a dnscache and then I configured dnsmasq with my dns servers (in fact I use OpenDNS) like this

# Add other name servers here, with domain specs if they are for
# non-public domains.
#server=/localnet/192.168.0.1
server=208.67.222.222
server=208.67.220.220

Then I'm able to do DNS lookups even though NetworkManager empties my /etc/resolv.conf.

[Indiver (indiver)]

Using ubuntu gutsy, with all the updates and the bug it still there. I had the same problem with pptp. Even when I unchecked "Use Peer DNS" option, there were no nameserver entries in file /etc/resolv.conf when the NM made the VPN connection.

Installing the package resolvconf did solve the problem for me. It's the easiest fix so far.

[fgr (f-gritsch)]

can anybody say me, why nobody fix this problem, altough this bug is now 2 years old?

still the same problem on hardy: if you use openvpn plugin in the networkmanager you can not connect to any servers anymore.

[Pirx (tkruemmer)]

Well, probably because it is not really a problem to most people, because they need not use a VPN to access their e-mail and read uncensored news content. As for me, VPN through NetworkManager/OpenVPN works fine and does exactly what it is supposed to do, regardless of what is written in resolv.conf.

[Kyle Gordon (kylegordon)]

I'd consider the lack of DNS resolution to be a problem for most people...

[dan_linder (dan-linder)]

I agree. For my use, I need to VPN into work/clients to allow me to bring
up XWindows displays, but I also need to surf the web to research answers.
I've got into the habit of manually adding my ISP's DNS servers into the
/etc/resolv.conf file but it's a royal pain.

[Pirx (tkruemmer)]

I use VPN and no problem at all with resolving DNS using the default install of Ubuntu 7.10, NetworkManager, NM OpenVPN plugin, OpenVPN. Installed 4 days ago. Go figure.

Kyle, if you would kindly read what I wrote: "...probably because it is not really a problem to most people, because they need not use a VPN...".

[Pirx (tkruemmer)]

to dan_linder: using the ISP's DNS defeats the purpose of using VPN.

[Kyle Gordon (kylegordon)]

Of course it's not a problem to the majority of people that use NetworkManager and don't use a VPN. However, for those that do use DNS services over a VPN, it is. As it stands, network-manager claims to provide that functionality and doesn't, so the bug is still a major showstopper for a certain subsection of users.

dan_linder still has a valid issue, as he may rely only on IP addresses to reach work servers. The VPN will still work for him, but since /etc/resolv.conf is scrubbed every time then it removes his ability to use anything _but_ IP addresses to access any servers on any network.

Regards

Kyle

[Gavin McCullagh (gmccullagh)]

> to dan_linder: using the ISP's DNS defeats the purpose of using VPN.

I think that's debatable. A VPN gives you an extra network interface which might or might not be your default gateway. If it's not, ie you only use it to go to a particular network (say for remote admin), then it's certainly not defeating the purpose of VPN to use your ISPs DNS for web surfing while doing sysadmin on a remote location (which may not allow you internet access through it).

That said, you're going to have to choose one DNS server or the other, you can't have both. I tend to have entries in the hosts file for the VPN (but NM then overwrites my DNS settings with those of the VPN-- which is no dns servers). A more complete solution might be to run a local DNS server on your desktop which can be configured to forward each query to the correct DNS. That's not great though.

[TM (junkmail-media)]

I'm running 8.04 and also experiencing this problem. Even though the number of users experiencing this is small, they are an important demographic cultivate because most of them are using a VPN for work purposes. If they're seeing this problem, it means that they are trying to do their job while using Ubuntu. The more we see Ubuntu in the workplace, the more accepted it will become everywhere and the easier it will be to justify using for everyone.

[Tero Tilus (tero-tilus)]

Confirming on Feisty: DHCP lease renewal overwrites /etc/resolv.conf and wipes out DNS servers set by nm-openvpn effectively killing VPN connection unless your /etc/hosts or DNS from DHCP provides name resolution for (non-default-route and non-internet) VPN network.

IMO Tom Verdaat had a good analysis on the situation:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/37239/comments/55

[Alexander Sack (asac)]

bug 256480 takes care that resolvconf works. this on top of the general improved capability of NM 0.7 should fix this. Marking this bug as fixed for next upload.

[Alexander Sack (asac)]

resolvconf has landed in the meantime in intrepid. Thanks all!

[Cerin (chrisspen)]

This issue has not been fixed. I've encountered it on 10.04. I have to manually add the domain, search and nameserver entries to the top of my /etc/resolv.conf file in order to use openvpn.