© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
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.