ubuntu resolv.conf

来源:互联网 发布:cn域名 编辑:程序博客网 时间:2024/06/11 01:29
  1. sudo chattr +i /etc/resolv.conf ok20120828


    1:关闭自动生成(这种方法不一定起作用 20120824 1110)

    sudo vi /etc/init/network-manager.conf
    注释掉start on 的部分
    sudo reboot  

    2:只读 ()

    http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

    Anyone who’s been using 12.04 over the past month or so may have noticed some pretty significant changes in the way we do DNS resolving in Ubuntu.

    This is the result of the implementation of: foundations-p-dns-resolving

    Here is a description of the two big changes that happened:

    Switch to resolvconf for /etc/resolv.conf management

    resolvconf is a set of script and hooks managing DNS resolution. The most notable difference for the user is that any change manually done to /etc/resolv.conf will be lost as it gets overwritten next time something triggers resolvconf. Instead, resolvconf uses DHCP client hooks, a Network Manager plugin and /etc/network/interfaces to generate a list of nameservers and domain to put in /etc/resolv.conf.

    For more details, I’d highly encourage you to read resolvconf’s manpage but here are a few answers to common questions:

    • I use static IP configuration, where should I put my DNS configuration?
      The DNS configuration for a static interface should go as “dns-nameservers”, “dns-search” and “dns-domain” entries added to the interface in /etc/network/interfaces
    • How can I override resolvconf’s configuration or append some entries to it?
      Resolvconf has a /etc/resolvconf/resolv.conf.d/ directory that can contain “base”, “head”, “original” and “tail” files. All in resolv.conf format.
      • base: Used when no other data can be found
      • head: Used for the header of resolv.conf, can be used to ensure a DNS server is always the first one in the list
      • original: Just a backup of your resolv.conf at the time of resolvconf installation
      • tail: Any entry in tail is appended at the end of the resulting resolv.conf. In some cases, upgrading from a previous Ubuntu release, will make tail a symlink to original (when we think you manually modified resolv.conf in the past)
    • I really don’t want resolvconf, how can I disable it?
      I certainly wouldn’t recommend disabling resolvconf but you can do it by making /etc/resolv.conf a regular file instead of a symlink.
      Though please note that you may then be getting inconsistent /etc/resolv.conf when multiple software are fighting to change it.

    This change affects all Ubuntu installs except for Ubuntu core.

    Using dnsmasq as local resolver by default on desktop installations

    That’s the second big change of this release. On a desktop install, your DNS server is going to be “127.0.0.1″ which points to a NetworkManager-managed dnsmasq server.

    This was done to better support split DNS for VPN users and to better handle DNS failures and fallbacks. This dnsmasq server isn’t a caching server for security reason to avoid risks related to local cache poisoning and users eavesdropping on other’s DNS queries on a multi-user system.

    The big advantage is that if you connect to a VPN, instead of having all your DNS traffic be routed through the VPN like in the past, you’ll instead only send DNS queries related to the subnet and domains announced by that VPN. This is especially interesting for high latency VPN links where everything would be slowed down in the past.

    As for dealing with DNS failures, dnsmasq often sends the DNS queries to more than one DNS servers (if you received multiple when establishing your connection) and will detect bogus/dead ones and simply ignore them until they start returning sensible information again. This is to compare against the libc’s way of doing DNS resolving where the state of the DNS servers can’t be saved (as it’s just a library) and so every single application has to go through the same, trying the first DNS, waiting for it to timeout, using the next one.

    Now for the most common questions:

    • How to know what DNS servers I’m using (since I can’t just “cat /etc/resolv.conf”)?
      “nm-tool” can be used to get information about your existing connections in Network Manager. It’s roughly the same data you’d get in the GUI “connection information”.
      Alternatively, you can also read dnsmasq’s configuration from /run/nm-dns-dnsmasq.conf
    • I really don’t want a local resolver, how can I turn it off?
      To turn off dnsmasq in Network Manager, you need to edit /etc/NetworkManager/NetworkManager.conf and comment the “dns=dnsmasq” line (put a # in front of it) then do a “sudo restart network-manager”.

    Bugs and feedback

    Although we’ve been doing these changes more than a month ago and we’ve been looking pretty closely at bug reports, there may be some we haven’t found yet.

    Issues related to resolvconf should be reported with:
    ubuntu-bug resolvconf

    Issues related to the dnsmasq configuration should be reported with:
    ubuntu-bug network-manager

    And finally, actual dnsmasq bugs and crashed should be reported with:
    ubuntu-bug dnsmasq

    In all cases, please try to include the following information:

    • How was your system installed (desktop, alternate, netinstall, …)?
    • Whether it’s a clean install or an upgrade?
    • Tarball of /etc/resolvconf and /run/resolvconf
    • Content of /run/nm-dns-dnsmasq.conf
    • Your /var/log/syslog
    • Your /etc/network/interfaces
    • And obviously a detailed description of your problem
    This entry was posted in Canonical voices, Planet Ubuntu. Bookmark the permalink.

    131 Responses to DNS in Ubuntu 12.04

    1. Rusty says:

      Does this in any way change the existing limitation of 256 characters and six domains in the Search keyword for resolv.conf?

      The ‘limitation’ of 6 domains is not really there, but the 256 characters seems to be pretty much hard coded into the resolver process for Ubuntu. It’s not a problem in Windows. It doesn’t seem to be a problem in RedHat, but I keep running into this as a limitation that causes me problems in Ubuntu. The company I work for has merged several times in the past couple of decades, but has not merged to a single domain. Additionally within several domains there are sub domains and having the sub domain listed in resolv.conf does not insure that a device in the domain will be resolved.

      I suspect that this will be a corner case for some time to come.

      Reply
      • Stéphane Graber says:

        resolvconf enforces the restriction of 3 dns servers when generating /etc/resolv.conf as that’s the maximum number of entries allowed by the libc resolver.
        A quick look at the same function for search domains doesn’t show an hardcoded limitation so I believe resolvconf will add as many search domains as it receives (though it makes sure the list doesn’t contain duplicates) and lets the libc deal with it. If it turns out to be a big problem, we could probably change the logic there to write something that’s more libc-compatible.

        Reply
    2. Mackenzie says:

      Finally! I made this change on my systems years ago, to make DNS & VPNs play more nicely together.

      Reply
    3. Marius Gedminas says:

      When (in a few months) I upgrade an Ubuntu server from 10.04 to 12.04 using sudo do-release-upgrade, will I need to move my DNS configuration from /etc/resolv.conf to /etc/network/interfaces by hand (assuming I remember to do that), or will the upgrade script do that for me?

      Reply
      • Stéphane Graber says:

        There’s logic in place in resolvconf’s postinst to detect cases where the user manually modified /etc/resolv.conf and automatically make the “tail” file link to the “original” file which should give you working DNS resolution.

        It’s obviously not as good as having the right entries magically appear in /etc/network/interfaces but the result should be the same without the need for configuration file handling magic.

        Reply
    4. Simon Davy says:

      Hey

      Will there be a way to enable caching in the default dnsmasq for those that want to?

      Reply
    5. Mika Suomalainen says:

      I don’t understand one thing about dnsmasq coming by default.

      Does the dnsmasq use same default config by default in Ubuntu 12.04, which you get by installing dnsmasq manually? I mean that by default dnsmasq allows everyone to use your dnsmasq instance DNS server. Or is ufw finally configured to block all incoming connections by default?

      Reply
    6. Mathieu Trudel says:

      Simon; right now there isn’t really a way to enable the caching in dnsmasq as spawned by NetworkManager, since that appears to be using some hard-coded parameters in NetworkManager when starting dnsmasq. We might look into this; but there’s at least one bug open in Launchpad about it.

      Mika; no, it’s configuration that is generated by NetworkManager and really only meant to be used as a local resolver. As such, it also only listens on 127.0.0.1, which should make it impossible to access from external systems.

      Reply
    7. Pingback: Mudanças na resolução DNS no Ubuntu 12.04 | Ubuntero

    8. BigWhale says:

      A question! :) How is /etc/hosts affected by this?

      My /etc/hosts is changed quite often because of all the development work I do. Today I noticed that a certain domain was resolving to 127.0.0.1 because of /etc/hosts entry. After I changed my hosts entry it was still resolving to localhost, I was testing this with dig and different browsers. The relevant line in nsswitch.conf is as it should be, files is the first parameter for resolving hosts.

      After I disconnected from my wireless network and reconnected the domain in question was resolved correctly.

      Any hints and ideas are welcome. :)

      Reply
      • Stéphane Graber says:

        dnsmasq is trying to be clever and actually uses /etc/hosts as a source for the resolver…

        I think we should be using:
        -h, –no-hosts Do NOT load /etc/hosts file.

        To avoid that specific problem and let the standard nss stack do it’s job.

        Reply
        • Mathieu Trudel says:

          Agree, that’s probably best, especially since normally host files should be read before the libc resolver tries to speak to dnsmasq.

          Reply
    9. Pingback: S05E01 – An Exhortation to Peace and Unity – Ogg | Ubuntu Podcast

    10. Pingback: S05E01 – An Exhortation to Peace and Unity – MP3 | Ubuntu Podcast

    11. Pingback: S05E01 – An Exhortation to Peace and Unity | Ubuntu Podcast

    12. mathew says:

      If you haven’t already considered it, I’d strongly suggest looking atunbound as an alternative to dnsmasq. I would have problems with dnsmasq caching negative records and failing to notice VPN connections going up and down; unbound has worked much better for me under those circumstances, and requires far less configuration.

      Reply
      • Stéphane Graber says:

        I’m actually a huge unbound fan myself, using it for years on all my servers as a local resolver and cache.

        The decision to use dnsmasq instead of Ubuntu was the lack of unbound support in Network Manager and the fact that Ubuntu desktop was already shipping dnsmasq as dhcp server/dns server for internet connection sharing.
        As for the issues you mentioned, these won’t be a problem in our case as dnsmasq isn’t configured to do caching and Network Manager re-generates dnsmasq’s config and respawns it every time one of the connections changes.

        Reply
        • Phil Howard says:

          I’ve been using UNBOUND as my resolver for several months on by 11.04 based server. I’ve found ONE domain name that won’t resolve through it (BIND9 works). Looking more closely, queries are sent to that domain’s authoritative servers, but no answer is received. I have not tested dnsmasq, but I will have it there ready to test when I stabilize my 12.04 testing.

          The domain is ftc.gov, querying http://www.ftc.gov.

          Reply
          • Stéphane Graber says:

            http://www.ftc.gov works fine here on a 12.04 system with the local dnsmasq server talking to another 12.04 system running unbound.

            I’m using the following config on the unbound side:
            remote-control:
            control-enable: yes

            server:
            verbosity: 0
            num-threads: 3
            interface: 0.0.0.0
            interface: ::
            port: 53
            do-ip4: yes
            do-ip6: yes
            do-udp: yes
            do-tcp: yes
            do-daemonize: yes

            access-control: 0.0.0.0/0 allow
            access-control: ::/0 allow

            # Enable statistics for the munin plugin
            extended-statistics: yes
            statistics-interval: 0
            statistics-cumulative: no

            # DNSSEC
            auto-trust-anchor-file: "/etc/unbound/dnssec/root.key"
            dlv-anchor: "dlv.isc.org. DS 19297 5 1 7D480DBEF530374D8A4333FCB22106EB10013B46"

            and to keep the dnssec anchors up to date:
            #!/bin/sh
            mkdir -p /etc/unbound/dnssec
            chown unbound.unbound /etc/unbound/dnssec
            sudo -u unbound unbound-anchor -a /etc/unbound/dnssec/root.key

            Hope this helps!

            Reply
    13. Alkis Georgopoulos says:

      If I’m already using dnsmasq as a caching DNS and as DHCP/TFTP server, what should I do to ‘merge’ the two configurations, the new one and mine?
      Wouldn’t that be easier if network-manager was using an /etc/dnsmasq.d/configuration.file instead of a hardcoded command line?

      If the only way to have dnsmasq running as a caching DNS+DHCP+TFTP server is to disable the new configuration, is there any way for a package.postinst to do that? Commenting out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf will cause prompts on conffile upgrades…

      Reply
      • Stéphane Graber says:

        Network Manager only binds 127.0.0.1, so you should be able to have yours bind either only an external IP or another 127.0.0.0/8 IP.
        There isn’t a programmatic way of disabling dnsmasq that I know of but Mathieu might know one, thankfully /etc/NetworkManager/NetworkManager.conf pretty much never changes so the risk of prompt on upgrades should be pretty low, at least during the lifetime of 12.04, upgrading to 12.10 might cause a prompt.

        I believe the reason we don’t use /etc/dnsmasq.d is that it’s part of the full dnsmasq server package that ships the init script. We just want dnsmasq running if Network Manager needs it, we definitely don’t want to end up shipping a full DNS server on all machines started even without network.
        However there’s definitely room for improvement there as we now have Network Manager, libvirt, LXC and probably others each running their own dnsmasq on their own network, causing me to have 10 of them running at the moment for example ;)

        Reply
    14. marc says:

      I’m actually trying to be as wise as I can, but I am NOT able to find way to configure dnsmasq in Ubuntu 12.04. Where can I put dnsmasq settings, like “address=/somsedomain.com/127.0.0.2″ ?

      I understand you want to make things SIMPLE, but it actually gets pretty tough now.

      Reply
      • Stéphane Graber says:

        Unless this domain comes from a VPN, I don’t think Network Manager can be told to add that line. I might be wrong though, Mathieu could confirm.
        In your case you could set 127.0.0.2 as DNS server in Network Manager or turn off dnsmasq in Network Manager and use your own manually configured dnsmasq server.

        Reply
        • marc says:

          Thank you for your response,

          I am actually using dnsmasq in a non-standard, “hackish” way to block some local domains/attackers – I simply tell dnsmasq to redirect every “bad” domain query to “localhost”. May I say I pretty much rely on this option and I would be quite dissapointed to lose it in upcoming 12.04 [which - BTW - I find very good].
          I suspect that additional dnsmasq options are beyond the scope of your work, but it would be nice if you could just pass dnsmasq options in a clear and simple way [hardcoding it makes my life much tougher as I've already said].

          I truly believe in your good intentions and I hope you’ll eventually come up with some simple, yet effective way of handling this problem

          Best regards!

          Reply
          • Stéphane Graber says:

            You could have these entry in /etc/hosts instead of in a local dnsmasq server, these would be used by nss when resolving the domain and so should work just fine for you use case.

            Reply
            • marc says:

              Well, that’s where my rant comes from, and that’s why I came up with this dnsmasq method eventually. You see. /etc/hosts doesn’t block the whole domains with subdomains AT ALL. It actually blocks only top domain, say – stgraber.org, but none of the subdomains, like – say – cdn.stgraber.org, anythingelse.stgraber.org. So you would actually end up filling /etc/hosts with literally ENDLESS list of always changing host list … while dnsmasq can make it work with JUST ONE line.
              So – /etc/hosts? been there, done that. This has definitely not prove itself good blocking mechanism. In fact, it is constantly showing it flows on the MAC/WIN/LIN lands.

              I am still hoping for you to understand and acknowledge the issue.

              Please feel free to contant me if you have any questions regarding this problem. I will happily explain this in details if that would be your wish.
              I really do care and hope for this to be solved on the arrival of 12.04 and I just don’t want to break the whole system and add some dirty little hacks to make it work as it should work.
              And I’ll be completely honest with you: while I understand why you came up with this shared DNS mechanism method in the first place, I also see how this would break other things eventually … And I do hope you too can realize this.

              Regards

    15. Neal Gamradt says:

      I have noticed over the weekend that any entry I put into /etc/hosts is immediately wiped out when I reboot. It sounds like this is probably related to the dnsmasq issue discussed in this article, is that correct? Someone pointed me to this article based on a question that I asked on LaunchPad:

      https://answers.launchpad.net/ubuntu/+source/network-manager/+question/191063

      If this is the same issue, is there any good work-around at the moment? I am happy with 12.04 overall, but this could end up being a big problem if there ends up being no good way to add these entries. I am currently not familiar with the dnsmasq tool. I thank you in advance for any advice or feedback.

      Reply
    16. Tim says:

      @marc
      Just disable the dnsmasq instance started by NetworkManager (see ‘I really don’t want a local resolver, how can I turn it off?’ on this page) and continue using your custom dnsmasq config same as before.

      Reply
    17. Phil Howard says:

      Some of our servers need to have X Windows running (blindly … no one is looking … a critical app just needs for it to be there for a window it wants to leave open, and other ways to use X (networked, VNC) cause the app to run slower). We also run our server network statically, but there is a DHCP server on that network for transient laptop usage. I need to prevent the servers from trying to get a DHCP address (because it can succeed and tends to mess up the existing network config of many IP addresses). The solution I use is to uninstall network-manager.

      Do you know how the absence of network-manager would affect this new dnsmasq setup? I’d rather avoid taking it out if it will work OK. The LAN has DNS servers, but without DHCP happening, I have to hard code those and have done so in /etc/resolv.conf. Should I add them somewhere else? It would be best to have dnsmasq forward to the main DNS cache servers.

      Reply
      • Stéphane Graber says:

        If the network card is configured in /etc/network/interfaces Network Manager won’t try to manage it. If it still does, then it’s a pretty serious bug we need to fix ASAP.

        Alternatively you can setup your static configuration directly in Network Manager, but it’s a bit less convenient to update from the command line.

        You probably could also run that specific software using xvfb and its “xvfb-run” wrapper, allowing the software to see and interact with an X server without actually starting X (and all its dependencies).

        The local dnsmasq is spawned by Network Manager, so if you uninstall it or disable it (by defining the interface in /etc/network/interfaces), the local dnsmasq server won’t start and your /etc/resolv.conf will point directly to your upstream DNS servers.

        Reply
        • Phil Howard says:

          It’s been a while since I set those servers up. I believe it was related to the fact that I was using alias interfaces for IPv4 (e.g. “eth0:1″ and such), but referenced them outside of /etc/network/interfaces (e.g. I wrote my own script to add additional IP addresses). This was because if you configured multiple IP addresses as alias interfaces in /etc/network/interfaces all network daemons would be rapidly started, shutdown, and restarted, over and over and over, for each IP address. Many wouldn’t get back up after that (SSH was one that had trouble with it). For that reason, and for the reason if it being a pain to manage hard coded alias interface names, I wrote my own script to add all the IP addresses with dynamically numbered aliases.

          I suspect the creation of the interface may have tempted network manager to manage it. That’s confirmed by what you say, since these interface names were not literally in /etc/network/interfaces.

          Fortunately IPv6 doesn’t need that alias interface insanity. You can just do “ifconfig eth0 add fc00::1234/64″ or whatever, and you’re done.

          I suspect xvfb-run might not work because we actually run about 12 instances of the app per machine, each with a window on X (we’re doing it now via one instance of tightvncserver).

          Reply
    18. Ryan Brady says:

      Thanks for this post, it helps me understand why DNS name resolution is broken in 12.04 after connecting to a VPN (using 12.04 install, using gnome-shell 3.4 and VPNC or OpenConnect).

      What appears to be happening is after I successfully connect to my works VPN, what happens is the DNS servers and search domains are *appended* to the existing resolv.conf instead of *replacing* my local DNS and search domain information.

      Let me explain further:

      Here’s from my “normal” resolv.conf (I disabled dnsmasq) showing my local info:

      nameserver 192.168.1.10
      nameserver 75.75.75.75
      search bradynet.local

      Here it is after connecting to VPN:

      nameserver 192.168.1.10
      nameserver 75.75.75.75
      nameserver 10.150.8.1
      search bradynet.local, c-compsci.local, yosemite.cc.ca.us

      not only is it appending the information, but it’s limited to 3 nameservers, so it never adds the 2nd VPN nameserver.

      When I connect to VPN I want newly generated resolv.conf to *replace* the nameserver and search domains with the ones from the VPN. with it appending as it is currently, DNS name resolution is 100% broken. I can ping ip addresses just fine.

      Not sure if this is a bug or a setting that I am overlooking. Of course it worked beautifully in ubuntu 11.10.

      -Ryan
      bradyrtech@gmail.com

      Reply
      • Stéphane Graber says:

        In your case, I’d strongly recommend using Network Manager with the built-in dnsmasq. It’ll take care of configuring dnsmasq so that all queries to the domains/subnets provided by your VPN are sent to DNS servers from the VPN.

        When connecting without Network Manager, it’s vpnc/openconnect’s job to tell resolvconf to prepend the information instead of appending, if they fail to do so, then you get the result above. I’d suggest filing bug reports against these.

        As for the limit of 3 nameserver in /etc/resolv.conf, that’s the libc limit that has always been around. Any extra nameserver is simply ignored and always was.

        Reply
        • Ryan Brady says:

          Actually I was using network-manager, though without dnsmasq, for vpnc and openconnect and it was appending the DNS servers and search domains to resolv.conf instead of replacing it. this caused dns name lookup failure while connected to my vpn.

          i did just revert back and re-enabled dnsmasq so that all dns lookups would go through 127.0.0.1, connected to vpn (using network-manager) and it still fails hostname resolution. if i provide the fqdn (i.e. bradyr.yosemite.cc.ca.us instead of “bradyr”) it will resolve and will continue resolving the non fqdn host names (bradyr) for a few moments, then it will fail to do look-ups again.

          Honestly, for my scenario, I’ll probably have to scrap dnsmasq (I prefer to point to my ubuntu server running bind9 as a caching server, etc, anyways) and scrap resolvconf (remove the symlink) and see if I can basically make it work like it did in 11.10, where VPNC (managed by network manager) will actually replace the resolv.conf file instead of append to it and then subsequently cause DNS lookups to fail.

          oh well. I consider it a learning experience though.

          -ryan

          Reply
          • Ryan Brady says:

            Just one last comment. Is it correct behaviour that when connecting to a vpn using vpnc or openconnect (this is all while running “stock” 12.04, letting network-manager handle the connect/disconnect of vpnc/openconnect) that the DNS servers and search domains are appended to the resolv.conf instead of replacing the “local” dns/search domains?

            in every prior version of ubuntu that i’ve used (since 9.04) and connected to the same vpn in every release, I’ve always had my local dns servers/search domains replaced with the VPN’s dns servers/domains so that I can do proper name lookup and resolution of machines on the other side of the VPN tunnel. this is at the cost of being able to resolve local resources on my home network (not doing split-tunneling).

            just an observation. Maybe it’s just me, maybe it’s a bug. either way this is a big change in 12.04 and I simply cannot be the only person experiencing this issue.

            Reply
    19. Thomas Hood says:

      @Ryan: Hi.

      Combining search paths is the default behavior of resolvconf. A common scenario is that the user is at site “foo” and makes a VPN connection with openvpn over the Internet to a remote site “bar”. It then makes sense to search for short host names in both the “foo” and the “bar” domains.

      Also in this typical case, and in the absence of dnsmasq running locally, the nameserver available via the VPN interface should be listed first in /etc/resolv.conf and should be able to resolve both names on the VPN and on the Internet.

      This is how resolvconf and openvpn work now. (Just checked.)

      I don’t have any experience with openconnect and vpnc. Should things work differently when they are used instead of openvpn? Please explain.

      When NM-driven dnsmasq is run locally the question about the order of nameserver addresses in resolv.conf is moot since there is only one, 127.0.0.1.

      Thomas

      Reply
      • Ryan Brady says:

        Thomas, thank you for replying, I almost forgot about this thread.

        Anyways, long story short, the behaviour that I was experiencing after turning off local dnsmasq (and when it was enabled, too) was that whenever I would establish a VPN connection to my work’s network (cisco vpn), what would happen is the DNS servers and search domains from the VPN network would be appended to resolv.conf *after* the existing entries (my local dns server and search domain entries).

        the correct behaviour in my opinion would be that after successfully connecting to the VPN, that the VPN network should take priority and resolv.conf should be modified such that the VPN dns servers and search domains are listed first.

        I havent reverted back to stock configuration lately to see if anything has changed, but my solution right now is to simply replace the resolv.conf (I removed the sym-link) after establishing the vpn connection with another one that I created, and when I disconnect the vpn connection, I restore the original.

        this is extra work, and while annoying, it 100% works correctly. Previous versions of ubuntu, unless I was not using NM, I didn’t have to resort to this type of trickery. With 12.04 and the change to resolvconf, it feels like a step backwards *in my opinion and for my situation* ..

        Of course if this all winds up being a bug in vpnc and/or openconnect or resolvconf, I will gladly accept the changes and pretend there was never a problem.

        -ryan

        Reply
        • Pat says:

          Ryan,

          I am running into this same exact situation. DNS resolution worked perfect for the VPNC pre-12.04.

          Did you ever find a better resolution, or are you still messing with sym-linking to your hand-built resolv.conf?

          Pat

          Reply
          • Ryan Brady says:

            Pat, believe it or not, after fighting with hand-building my resolv.conf every time I used VPNC to establish my vpn tunnel, i just reverted everything back to “stock” configuration with resolvconf.

            After going back to stock configuration, it magically started working again. I’m thinking there must’ve been a bugfix that I missed.

            The only thing i do differently with VPNC configuration is i have it set to do automatic address only, i manually set the DNS servers.

            I also have dnsmasq disabled.

            if you can manually set your dns servers in your vpnc configuration, see if it works properly. (after establishing the tunnel, the vpn dns servers should take priority in resolv.conf over your local dns servers… in my opinion)

            -ryan

            Reply
    20. Tom says:

      Great change, should make NM more robust overall.

      How does this affect unqualified hostnames? For example, if I establish a VPN connection and perform a lookup of ‘machine’, will dnsmasq look on all my networks (appending the relevant search domains) or will it stop after the first one? If it is the latter, which network will be the first one it tries – the VPN or the local net?

      Reply
      • Stéphane Graber says:

        Hi,

        The way Network Manager configures dnsmasq, dnsmasq doesn’t know about the search domains. These instead get sent to resolvconf and can be found at the usual spot in /etc/resolv.conf.
        So when resolving, the libc will iterate through the search domains as it usually does and dnsmasq will only do the resolving.

        For VPNs, I didn’t actually know if NM would do the right thing so I did a quick check.
        Network Manager asks resolvconf to add the VPN search domains first, then the local search domains to /etc/resolv.conf

        So the libc as usual will stop after the first valid DNS record but will start by trying the VPN network, which I think is the right thing to do here.

        Reply
        • Tom says:

          Makes sense, I would agree that the VPN is the best first choice for hostname lookups.

          Should an application (such as a VPN client) make manual changes to /etc/resolv.conf, would I be correct in assuming resolvconf will periodically overwrite these changes (assuming the changes end up being written to /run/resolvconf/resolv.conf)? If so, how often would it do this?

          Is there any way to intercept arbitrary changes to /etc/resolv.conf and incorporate them into /etc/resolvconf/resolv.conf.d/[head|tail] ?

          Reply
          • Stéphane Graber says:

            In theory, everything in the distro must be resolvconf aware and won’t touch /etc/resolv.conf directly if resolvconf is enabled.

            resolvconf will regenerate /etc/resolv.conf everytime something changes (interface goes up/down, dhcp changes, …) but won’t otherwise.

            As far as I know resolvconf doesn’t have any mechanism to extract manual changes happening while it’s running and I’m not sure we’d want that.
            It sounds like a much better idea to do the 2-3 lines change to write to /run/resolvconf/interface/ and then call resolvconf to have it propagate the changes.

            Reply
    21. Thomas Hood says:

      @Ryan:

      Sorry for the delay in replying. I opted to receive e-mail notifications of replies but I didn’t get one for yours. From now on I’ll check back every day or two.

      If your problem is the order of entries in resolv.conf then this can be solved by editing /etc/resolvconf/interface-order. See interface-order(5).

      What are the names of your VPN-related network interfaces?

      Reply
      • Ryan Brady says:

        @Thomas, thanks again for the response, I’ll look at those settings after work today and see if I can make it work properly. To be honest, after my initial troubles with resolvconf and vpnc/openconnect, I (understandably) opted to disable resolvconf and just go with manually editing resolv.conf. Obviously I would like it working correctly.

        To answer your second question, the vpn interface would be tun0 (once established), assuming thats the answer you’re looking for.

        Reply
    22. Peter says:

      “The DNS configuration for a static interface should go as “dns-nameservers”, “dns-search” and “dns-domain” entries added to the interface in /etc/network/interfaces”

      Could you give an example of this? I need to add two manual entries for dns name servers on eth0. I can’t make it work
      cheers
      Peter

      Reply
      • Stéphane Graber says:

        auto eth0
        iface eth0 inet static
        address 172.17.0.10
        netmask 255.255.255.0
        gateway 172.17.0.1
        dns-nameservers 8.8.8.8 8.8.4.4
        dns-search mydomain.com google.com

        Reply
        • Peter says:

          Thanks….

          Reply
    23. Nishant says:

      I updated to Pangolin yesterday, and networking does not work. DNS lookup errors pop up all the time. I have a router connected to the college network that is configured with a static IP, DNS and gateway. It worked fine with Ocelot, and my Kindle Fire still works. Even the system works with limited connectivity. Both wired and wireless connections are facing the same issue. I am willing to concede that the college network is rubbish, it is on the unreliable side of things, so something somewhere in the OS does not agree with it. Is there anything that can be done about it?

      Reply
      • Stéphane Graber says:

        From what you describe, it sounds like your college network sends you multiple DNS servers (that’s a good thing) but some of them return invalid results.
        dnsmasq tries to figure out the best DNS server, based on how quickly it gets results (as far as I know, I’m not a dnsmasq expert), so it might be that one of your DNS servers is returning bogus records causing this.

        In the past, when we were only using the libc dns resolver, it’d take the servers sequentially from /etc/resolv.conf and so assuming the first DNS server you receive is a working one, it’d always hit that one. Trying each DNS server listed in /run/nm-dns-dnsmasq.conf individually with dig should let you find the problem. You may then either complain about it to whoever is in charge of the network or just hardcode the right one in NetworkManager’s configuration.

        Reply
        • Nishant says:

          Yeah, the thing is, I managed to find out that I could fix the problem by disabling resolvconf and giving a custom resolv.conf file with the correct DNS(my router’s IP). The only trouble is, it now waits for several minutes for network configuration.
          My network admin is useless. Complaining will not help.

          Reply
          • Thomas Hood says:

            Your problem may be bug #1003842.

            Reply
    24. ijk says:

      >I really don’t want resolvconf, how can I disable it?
      >I certainly wouldn’t recommend disabling resolvconf but you can do it by >making /etc/resolv.conf a regular file instead of a symlink.
      >Though please note that you may then be getting inconsistent /etc/resolv.conf >when multiple software are fighting to change it.

      dpkg-divert –add –rename –divert /etc/resolv.conf.ubuntu-version /etc/resolv.conf

      Reply
      • Stéphane Graber says:

        That won’t work as /etc/resolv.conf isn’t actually a conffile shipped by the resolvconf package.

        Please follow the instructions in the blog post to turn off resolvconf (make the symlink a static file).

        Reply
    25. Pingback: LUG Mureş » Noutăți în Ubuntu 12.04 LTS

    26. sjoerd says:

      Thanks for the post! Weird that nothing is mentioned in the upgrade notes :(
      Anyway on a test server it seems to work to follow your first bullit point (putting it in /etc/network/interfaces)…
      Certainly something that should be mentioned for server upgrades (or systems with static configurations)..

      Reply
      • Stéphane Graber says:

        Hmm, where wasn’t it mentioned exactly?

        I made sure to reference this blog post in the official Ubuntu release notes under Desktop and CommonInfrastructure:https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop

        If there’s anywhere else I missed, I’ll be happy to look at updating it too.

        Reply
    27. sjoerd says:

      Hi Stéphane,
      Hmm there’s the problem: you refer to the desktop version, where you normally not even mess with the /etc/resolv.conf, but the DNS change isn’t mentioned in the server release notes at :
      https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuServer

      Reply
      • Stéphane Graber says:

        What about the 4th bullet point in the Common Infrastructure section of that page?

        Reply
        • sjoerd says:

          Hmmmmissed that point indeed…searched for dns i.s.o. resolv….
          Ah well bottom line thanks thanks to your posting I new where to look and next time maybe look better in the release notes although I wouldn’t have expected this impact. For desktops it shouldn’t be a problem and with another server upgrade it still did work out fine. So beats me why the first server went faulty.

          Reply
          • nish says:

            That happens with me when i try to read after two beers down :) jk

            Reply
          • Neal McBurnett says:

            Good point – I think others might just search for ‘dns’ after encountering a dns problem and miss that reference. Any chance of adding that helpful keyword to the release notes?

            Reply
    28. Kevin Otte says:

      Any reason why we are staying with 127.0.0.1 and not moving to ::1 for the local resolver?

      Reply
      • Stéphane Graber says:

        No particular reason other than it was the default in Network Manager’s code.
        I think moving to ::1 would actually solve a few of our existing bugs where NM’s dnsmasq conflicts with an existing local resolver (unless that local resolver also binds ::1).
        Another thought was to use 127.0.1.1 or a similar non-127.0.0.1 loopback address to workaround the same problem.

        Reply
        • Kevin Otte says:

          I was reminded that using IPv6 only resolution could break a few apps with lingering legacy code. Most notable is mtr:https://bugs.launchpad.net/mtr/+bug/752583

          Reply
        • Thomas Hood says:

          See bug #959037 and in particular the comments starting with #60.

          Reply
    29. murex says:

      Hello Stéphane,

      On previous Ubuntu releases I had local DNS with Bind9.
      On 12.04, it does not work because dnsmasq uses 192.168.1.1 (Box’s IP) as DNS resolver.
      I have succeed to use Bind9 by disabling dnsmasq in : /etc/NetworkManager/NetworkManager.conf
      Is there any other opportunity to configure in order to dnsmasq uses Bind9 as DNS resolver ?

      Reply
      • Stéphane Graber says:

        There’s indeed a way of doing it though I never tried it.

        Get bind9 to listen on 127.0.5.1 for example (any non-127.0.0.1 loopback address), then in Network Manager configure your dns server to be 127.0.5.1.

        This should make your system use 127.0.0.1 (dnsmasq) as a DNS dispatcher (for split-DNS) with 127.0.5.1 as its upstream (your bind9 server) which will then do the DNS resolving and caching.

        Reply
        • murex says:

          First of all, many thanks for your answer.
          Sorry to be late but until now I don’t succeed to implement it.
          One problem is dnsmasq and Bind9 are using together port53.

          So, I have added in /etc/bind/named.conf.options
          listen-on port 5353 { 127.0.5.1; };

          I have set Network-Manager with :
          Automatic Addresses only (DHCP) → 127.0.5.1

          Re-enabling dnsmasq in /etc/NetworkManager/NetworkManager.conf

          and reboot PC.

          I still looking for, and reading a lot of manpages…
          If you have any idea ???
          Thanks

          Reply
          • Thomas Hood says:

            Don’t use port 5353 which is intended for multicast DNS.

            Bug #959037 deals with the same issue with respect to standalone dnsmasq and NM-controlled dnsmasq.

            Comment #67 of that bug describes one way of solving the problem in the dnsmasq case. Might give you some ideas.

            Reply
    30. Todd Vierling says:

      These changes are nice and good, but there’s a huge argument to be made for manual hooks to add lines to the generated dnsmasq.conf. The VPN I use for work (in split-horizon configuration) announces one domain, which ends up in the generated config as:

      server/private.domain/private.dnsserver

      However, this is not the only DNS domain I need to look up through the private DNS. “Tell my employer to fix it” isn’t an acceptable option, as this worked previously thanks to the private DNS server previously (pre-12.04) coming *first* in the resolver list.

      So… where can I specify the extra domains that should go through that server?

      This is probably a trick question, as I’m fairly certain there is no such place. And that’s the problem: no override capabilities. 100% hardcoding of configuration is a Bad Thing.

      Reply
      • Stéphane Graber says:

        Network Manager could do with some more configuration around the DNS resolver features indeed.

        In your case, I’d expect that changing the VPN configuration from “Automatic (VPN)” to “Automatic (VPN) addresses only”, then fill the “DNS servers” and “Search domains” field with the right values.
        Connecting should then generate the righ dnsmasq configuration file.

        Reply
    31. nish says:

      I am using proprietry VPN that uses tun kernel netdev.
      Question is that is it a good idea to just “echo “customeDNS” and “127.0.0.1″ | resolvconf -a [name]” and “resolvconf -d” after connection is over?
      (commands used are not exact).

      Also whats the order in which domains are searched? That is when i add custom dns suffix as well along with customDNS.
      For example /etc/resolv.conf ( its a link as per resolvconf ) looks like this after changes made to it:
      search customDNSSuffix
      nameserver customDNS
      nameserver 127.0.0.1

      Also does the resolver library in libc continues to find the dns name if it couldnt be found with customDNSSuffix in customDNS server?

      Reply
      • Thomas Hood says:

        The VPN daemon should indeed register search domain names and nameserver addresses with resolvconf after connection and de-register them after connection.

        The record name used for the registration should have a higher priority than “eth0″ as determined by /etc/resolvconf/interface-order.

        Reply
    32. Pingback: DNS Fail? Not anymore | MWJ Computing

    33. Tobias says:

      I have a similar problem as Nishant. Since I’ve changed to Precise, I experience massive DNS problems. This happens on an upgraded system (formerly Oneiric) as well as on a new installation (both are Desktop edition). I’ve tried a couple of angles and introduced additional nameservers to my wireless connection, but my resolv.conf still shows 127.0.0.1 as the only nameserver, and any lookup that doesn’t specifically use a different nameserver will almost always time out (at least 9 times out of 10). Something like “dig @8.8.8.8 stgraber.org” works, but I want DNS to work everytime and not only on special occasions. Any help is appreciated.

      Reply
      • Stéphane Graber says:

        We have a known race condition where in some rare cases (though on affected systems this is very reproducable), dnsmasq fails to bind 127.0.0.1 at boot time.

        To check if you’re affected, simply get Network Manager to reconnect on your network after boot. If that fixes DNS resolving, then that’s our bug.

        This bug is high on the priority list and we’re hoping to have a fix land in the next couple of weeks.
        https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/993379

        Until then, you can either use the trick I just described (re-select the network in the applet, causing a reconnection) or disable dnsmasq as described in the blog post. (All that assuming, you’re indeed hitting that bug).

        Reply
        • Tobias says:

          Thanks for the quick reply, Stéphane. Reconnecting didn’t change anything, DNS still worked on rare occasions but by far not as it should. But disabling dnsmasq did the trick, I now have working DNS again.
          I’m not sure if the bug you describe fits my situation, though. You made it clear that reconnecting should work as well, which it didn’t.

          Reply
      • Thomas Hood says:

        Could be bug #1003842.

        Reply
    34. Pingback: Appending Search Domain with Ubuntu | GAWAG

    35. Dan says:

      A very stupid question. I am no programmer so no good at handling scripts etc and for a regular person who has nothing to do with programming the “To turn off dnsmasq in Network Manager, you need to edit /etc/NetworkManager/NetworkManager.conf and comment the “dns=dnsmasq” line then do a “sudo restart network-manager” leaves one major question: comment the “dns=dnsmasq”? how should it be commented? I mean what should be written and changed in the “dns=dnsmasq”?

      Thank you for your help!

      Reply
      • Stéphane Graber says:

        The configuration file is in “ini” format, so putting a # in front of dns=dnsmasq will comment it.

        Reply
        • Dan says:

          Thank you! :)

          Reply
        • Thomas Hood says:

          Stéphane: Shouldn’t there be a GUI way to disable dns=dnsmasq mode?

          Reply
    36. Marcus Moeller says:

      I need to deploy a custom resolv.conf, as our dhcp server delivers the wrong settings for our requirements.

      Right now, I have added the necessary settings to the ‘head’ file, but this leads to duplicate entries.

      Is there a way to force pre-defined content?

      Reply
      • Stéphane Graber says:

        I see two options here:
        - Set the IP as a dhcp append or dhcp override in /etc/dhcp/dhclient.conf, this should do what you want without actually messing with resolvconf
        - Remove the /etc/resolv.conf symlink and replace it by a standard /etc/resolv.conf file with the usual content

        Reply
      • Thomas Hood says:

        If you put the entries in /etc/resolvconf/resolv.conf.d/base then they will be de-duplicated before they are included in the dynamic resolv.conf file. They will also be subjected to reordering according to interface-order(5).

        Reply
    37. Chris says:

      I recently upgraded to 12.04, and now Ubuntu does not correctly read the domain/search/nameserver values from my brand-new Cisco/Linksys router, meaning I can’t resolve any internal domain names, although I still seem able to resolve external domain names.

      Everything had worked perfectly in 11.10/10.04.

      Is this a bug or does Ubuntu now need some sort of special configuration just to work with standard network routers?

      Reply
      • Thomas Hood says:

        Although the nameserver information no longer appears in /etc/resolv.conf it probably does appear in /var/run/nm-dns-dnsmasq.conf. Does it?

        If the information does appear in /var/run/nm-dns-dnsmasq.conf and you can’t resolve names then that’s a bug. As a workaround try commenting out “dns=dnsmasq” in /etc/NetworkManager/NetworkManager.conf.

        Could be bug #1003842.

        Reply
    38. Daniele says:

      Hello there,

      I upgraded a few days ago to kubuntu 12.04. I need many different VPN connections: the connection works smoothly but resolution for internal names no, for none of those.

      I had a look to syslog and /run/nm-dns-dnsmasq.conf: the issue is VPN provider dosn’t properly publish the list of internal domain to resolve through VPN, probably becouse they rely on the fact CISCO vpn client always place internal VPN dns server as first so it doesn’t matter. But with new logic, it does matter: queries for internal names are sent to main DNS that of course doesn’t know about.

      The wka I found with kde-network-manager is to manually specify both DNS servers and domains. This worked fine! The issue here you need to have a look syslog to unerstand which DNS is provided by the VPN and then manually place it in VPN config.

      Will be nice to have the possibility to just add manually internal domains without having to specify DNS server names, but this maybe something that is more related to KDE enanchement.

      Daniele.

      Reply
      • Stéphane Graber says:

        Another suggestion we discussed at the Ubuntu Developer Summit last week was to add a checkbox in the Network Manager UI to force it to route all DNS queries over the VPN (but without requiring you to also route the actual trafic).

        Reply
      • Thomas Hood says:

        You have hit bug #1003842. The workaround is to comment out the line “dns=dnsmasq” in /etc/NetworkManager/NetworkManager.conf.

        Reply
    39. Pingback: Using host networking and NAT with VirtualBox, v2.0 | tolaris.com

    40. sam says:

      I upgraded today from mint 12 to mint 13 RC. (based on ubuntu 12.04)
      Everyting went perfect, but… one new problem came up.

      I have installed virtualbox and run a windows xp inside.
      No way to get the internet running again. I think I need to downgrade back to mint 12.

      Reply
    41. asb says:

      Updated today to “Precise” and immediately lost any capability for DNS resolution. Very simple setup – one network interface, static IP address, local nameserver, followed this article’s instructions – no luck.

      Ubuntu 12.04 = no networking. That’s real progress :-(

      Reply
      • Neal McBurnett says:

        @asp you might have hit the rare race condition bug that
        Stéphane noted before: “Network Manager starts before the loopback device is ready, leading to dnsmasq not listening on any interface, breaking DNS resolutionion”
        https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/993379

        A fix was released on June 1 – can you check whether that resolved your problem? Thanks.

        Reply
      • Thomas Hood says:

        The local nameserver address probably has to be added to a “dns-nameservers” line in /etc/network/interfaces.

        Reply
    42. TheOldFellow says:

      How do I turn Caching back on? I don’t use VPN, and the system has only one user, me. There are very good reasons for wanting a caching DNSmasq.
      Thanks.

      Reply
      • Thomas Hood says:

        What would you say to running the traditional dnsmasq server and having it forward queries to the NM-controlled dnsmasq process? (Currently not possible — see bug #959037.) The traditional standalone dnsmasq server does caching.

        Reply
    43. Pingback: Características de Ubuntu 12.04 LTS

    44. Pingback: (English) DNS in Ubuntu 12.04 | Senouf.fr Conseil Systèmes et Réseaux

    45. Chris says:

      Help w/ the following?:

      VPN disconnected: resolve.conf not refreshed

      Reply
      • Thomas Hood says:

        Looks like bug #694425.

        Reply
      • Thomas Hood says:

        I just posted an answer to the askubuntu question you referred to. HTH.

        Reply
    46. Pingback: DNS resolver changes in Ubuntu Precise (12.04) | sandipb.net

    47. Brian Marks says:

      Upgraded from 11.10 to 12.04. VPN hosts no longer resolve to IP addr when connected to VPN. I can use the linux ‘host’ command and specify the VPN dns server and resolution works. VPN hosts were always resolved correctly under 11.10.

      I have reviewed the resolv.conf file before and after connecting and the problem appears to be that the VPN DNS servers are not getting added to the file although search domains are getting added. The VPN settings are specified as automatic vpn addresses only through network manager ui. DNS servers and search domains are both entered as comma-delimited entries into the ui settings. If I add the nameserver entries manually to resolv.conf and test host command in term then it works. Of course resolv.conf is overwritten by network manager later.

      I can hard-code the entries in head of /etc/resolvconf/resolv.conf.d/ directory but this is probably not a good long-term solution. Is this a bug in dnsmasq or resolvconf or do I have a broken component in my system? dnsmasq v2.59-4 and resolvconf 1.63ubuntu14 shows installed via synaptic.

      The problem is also documented inhttps://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/994575.

      Reply
      • Thomas Hood says:

        I have replied to your bug report at bug report #994575. We can continue to discuss your case there.

        Reply
    48. Pingback: Ubuntu 12.04 and resolv.conf - The Data Nest

    49. Pingback: How to disable DNSMASQ in ubuntu 12.04(Precise) | .::Madesumitre blog's

    50. Gonzalo says:

      I would like to turn on the local cache, where can i do that¡?

      Reply
      • Thomas Hood says:

        It is on by default in a fresh install of Ubuntu 12.04 Desktop.

        It is enabled if there is a line “dns=dnsmasq” in /etc/NetworkManager/NetworkManager.conf.

        Reply
    51. Pingback: Upgrading to Ubuntu 12.04 | thestorey.ca

    52. Pingback: DNS Cache su ubuntu 12.04 | ReefBits.net

    53. Tim Riker says:

      If a command line vpn script wants to add dns servers and/or search paths to dnsmasq, how should it do this? passing arguments to resolvconf does NOT seem to effect dnsmasq. I would think that this should take effect. Can we get resolvconf updated such that it effects the network-manager dnsmasq if one is configured?

      Reply
      • Thomas Hood says:

        The command-line VPN configurer should call resolvconf to register and deregister nameserver information. See resolvconf(8). The registered information will be included in resolv.conf but will not affect NetworkManager or its slave dnsmasq process at all.

        Reply
    54. shadab khan says:

      The “Using dnsmasq as local resolver by default on desktop installations” broke the whole internet usage functionality on my PC.

      In essence I could visit websites by typing in their IP addresses, but not their names.

      check this out: http://forums.linuxmint.com/viewtopic.php?f=61&t=106740
      also we have many similar problems:https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/989900

      Do you think a new user would stick to Ubuntu after encountering such loss of functionality? (especially since the 11.10 worked flawlessly)

      Reply
      • Thomas Hood says:

        Issues with the local caching nameserver did emerge after 12.04 came out and it’s very regrettable that this has inconvenienced a number of users. We are working on solutions.

        Fortunately it is easy in the meantime to disable the local caching nameserver. Comment out the “dns=dnsmasq” line in /etc/NetworkManager/NetworkManager.conf.

        Reply
    55. Pingback: Ubuntu 12.04 LTS

    56. Pingback: Easily ssh to your containers and VMs on Ubuntu 12.04 LTS | Stéphane Graber's website

    57. Pingback: Problemes amb el DNS (/etc/resolv.conf) amb el nou Ubuntu 12.04 ? | DomestiCAT

    58. Tom says:

      THANKS!! This post just solved my problem after a 3h long troubleshoot period!

      Reply
    59. Pingback: YV Tech | Ubuntu Desktop 12.04 LTS

    60. Mariano Absatz (el Baby) says:

      Hi Stéphane,

      great article… I found it yesterday ’cause I noticed the changes and had to document for a project of mine and for the Argentina LoCo Team.

      I just translated into Spanish in my own wiki athttp://wiki.clueless.com.ar/Resoluci%C3%B3nDnsEnUbuntu1204

      Feel free to refer Spanish readers to it.


      https://launchpad.net/~el-baby

      Reply
    61. Vaidy says:

      I am still trying to figure out how this works.

      I have everything working fine with my LenovoT520 without vpn.
      once i connect to my vpn i am unable to browse the internet. here are the details of my machine please do suggest me any workarounds i am really interested using Ubuntu, but only this issue is causing me not to.

      Before VPN:
      ——————-
      root@vaidy-pc:/home/vaidy# ifconfig -a
      eth0 Link encap:Ethernet HWaddr f0:de:f1:fe:d5:b6
      UP BROADCAST MULTICAST MTU:1500 Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
      Interrupt:20 Memory:f5200000-f5220000

      lo Link encap:Local Loopback
      inet addr:127.0.0.1 Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING MTU:16436 Metric:1
      RX packets:67 errors:0 dropped:0 overruns:0 frame:0
      TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0
      RX bytes:5983 (5.9 KB) TX bytes:5983 (5.9 KB)

      wlan0 Link encap:Ethernet HWaddr 8c:70:5a:88:2d:b8
      inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
      inet6 addr: fe80::8e70:5aff:fe88:2db8/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      RX packets:53392 errors:0 dropped:0 overruns:0 frame:0
      TX packets:32998 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:74758806 (74.7 MB) TX bytes:3244266 (3.2 MB)

      root@vaidy-pc:/home/vaidy# cat /etc/resolv.conf
      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
      # DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
      nameserver 192.168.1.1
      root@vaidy-pc:/home/vaidy# route -n
      Kernel IP routing table
      Destination Gateway Genmask Flags Metric Ref Use Iface
      0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
      169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
      192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
      root@vaidy-pc:/home/vaidy#

      After Connecting to VPN:
      ————————————-
      root@vaidy-pc:/home/vaidy# ifconfig -a
      eth0 Link encap:Ethernet HWaddr f0:de:f1:fe:d5:b6
      UP BROADCAST MULTICAST MTU:1500 Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
      Interrupt:20 Memory:f5200000-f5220000

      lo Link encap:Local Loopback
      inet addr:127.0.0.1 Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING MTU:16436 Metric:1
      RX packets:67 errors:0 dropped:0 overruns:0 frame:0
      TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0
      RX bytes:5983 (5.9 KB) TX bytes:5983 (5.9 KB)

      tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.74.229.181 P-t-P:10.74.229.181 Mask:255.255.252.0
      UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412 Metric:1
      RX packets:71 errors:0 dropped:0 overruns:0 frame:0
      TX packets:85 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:500
      RX bytes:15614 (15.6 KB) TX bytes:8956 (8.9 KB)

      wlan0 Link encap:Ethernet HWaddr 8c:70:5a:88:2d:b8
      inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
      inet6 addr: fe80::8e70:5aff:fe88:2db8/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      RX packets:53530 errors:0 dropped:0 overruns:0 frame:0
      TX packets:33165 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:74795070 (74.7 MB) TX bytes:3275221 (3.2 MB)

      root@vaidy-pc:/home/vaidy# cat /etc/resolv.conf
      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
      # DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
      nameserver 10.73.158.106
      nameserver 10.73.158.107
      nameserver 192.168.1.1
      search hq.netapp.com
      root@vaidy-pc:/home/vaidy# route -n
      Kernel IP routing table
      Destination Gateway Genmask Flags Metric Ref Use Iface
      0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
      10.74.228.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0
      169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
      192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
      202.3.120.38 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
      root@vaidy-pc:/home/vaidy#

      i am able to access my internal sites but not the external sites.
      please do guide me through if i am making any mistakes.

      Reply
      • Stéphane Graber says:

        So, one thing I see above is that you are using your VPN as the default gateway for all outgoing traffic, not just the internal subnets.
        Is that actually what you want? Does that VPN let you surf on the internet or is it restricted to just the company’s internal network?

        If the later, then you’ll want to change your VPN setting and tick “Use this connection only for resources on its network”, which will make Network Manager only route the subnets received over the VPN (and same thing for the DNS).

        Reply
        • Vaidy says:

          No I am unable to surf internet. It is restricted to the company’s internal network only.
          I will change the VPN Settings.
          What about DNS? i didn’t get what you meant on DNS Settings.

          Reply
          • Thomas Hood says:

            Routing is one issue, as Stéphane has already mentioned.

            DNS could also be an issue for you. Your configuration is correct only if the VPN nameservers 10.73.158.106 and 10.73.158.107 can resolve all domain names, i.e., not only private names but also names of machines on the Internet. Can they?

            Reply
        • Thomas Hood says:

          Stéphane wrote:
          > tick “Use this connection only for resources on
          > its network”, which will make Network Manager
          > only route the subnets received over the VPN
          > (and same thing for the DNS).

          I believe that, for DNS lookups to be routed, the
          NetworkManager-controlled dnsmasq process
          must be enabled: i.e., there must be a line

          dns=dnsmasq

          in /etc/NetworkManager/NetworkManager.conf.

          Reply
          • Vaidy says:

            I updated the VPN Settings by enabling the “Use this connection only for resources on its network” option. Also i have the dns=dnsmasq entry in /etc/NetworkManager/NetworkManager.conf. now i am able to access the internet but not the intranet sites.. :( . I am very bad at networking. Please excuse me.

            Reply
            • Thomas Hood says:

              Hi. This discussion really belongs in a bug report at launchpad.net.

              Did you reboot after reconfiguring? If not, please reboot and try again.

              When saying “access … network” please draw a distinction between being (un)able to resolve domain names and being (un)able to communicate with other machines. To test name resolution use tools like dig. To test communication with other machines use tools like ping with an IP address. See the man pages.

    62. Vaidy says:

      No I am unable to surf internet. It is restricted to the company’s internal network only.
      I will change the VPN Settings.
      What about DNS? i didn’t get what you meant on DNS Settings.

      Reply

    Leave a Reply












  2. root@Ttpod:~# cat /etc/network/interfaces  
  3. # This file describes the network interfaces available on your system 
  4. # and how to activate them. For more information, see interfaces(5). 
  5.  
  6. # The loopback network interface 
  7. auto lo 
  8. iface lo inet loopback 
  9.  
  10. # The primary network interface 
  11. auto eth0 
  12. iface eth0 inet static 
  13. address 192.168.1.82 
  14. netmask 255.255.255.0 
  15. gateway 192.168.1.1 
  16. dns-nameservers 8.8.8.8
原创粉丝点击