Announcement

Collapse
No announcement yet.

host unreachable afterr getting new IP

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    host unreachable afterr getting new IP

    Hi,

    I'm using Kubuntu in a local network, I'm connected to the internet via a firewall. My internet provider assigned me a dynamic IP, it changes every 12 hours. I'm having a problem since I upgraded to version 12.04, every time the external dynamic IP is reassigned (this IP is handled by the firewall), my local computer (that is on a private network) starts getting errors when I tried to access the internet, I always have a 'host unreachable' message; I have to do '/etc/init.d/networking restart' in the local computer in order to get access again to the internet.

    Anybody knows what could be the reason for this behaviour?

    Thanks in advance!

    #2
    More than likely your box loses the DNS addresses of your ISP.
    An option in both the NetworkManager and Wicd, which I use, allows you to put in a set of DNS addresses. I use Google's.
    http://en.wikipedia.org/wiki/Google_Public_DNS
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    Comment


      #3
      Toshiro, next time this occurs, please try to ping an IP address directly. A good one to use is 4.2.2.1.

      I'm a bit flummoxed that renewing the north-side IP address causes problems on the LAN behind the firewall. (I also think it's silly to forcibly expire a lease after 12 hours, too, but oh well.)

      Comment


        #4
        I also suspect a DNS issue.

        Is your firewall providing a DNS proxy? Posting the contents of /etc/resolv.conf will reveal this.
        Also, short of doing a full networking restart, releasing and renewing the DHCP address might fix it (and more importantly help show why the problem is occurring):
        Code:
        sudo dhclient -r && sudo dhclient

        What is the firewall/router you are using anyway?
        I'd rather be locked out than locked in.

        Comment


          #5
          Originally posted by SecretCode View Post
          I also suspect a DNS issue.

          Is your firewall providing a DNS proxy? Posting the contents of /etc/resolv.conf will reveal this.
          Also, short of doing a full networking restart, releasing and renewing the DHCP address might fix it (and more importantly help show why the problem is occurring):
          Code:
          sudo dhclient -r && sudo dhclient

          What is the firewall/router you are using anyway?
          Yes, my firewall has a DNS server confgiured. and my local computer uses it My local computer has configured a fixed IP, so I think renewing the DHCP lease will help.

          BTW, I don't think the local DNS server is the culprit because the problem is fixed as soon as I restart the networking services in my local computer only.

          As a firewall I'm using a linux server (of course ), it has installed Ubuntu server 10.04.4 LTS.
          Last edited by toshiro; Aug 15, 2012, 05:03 PM.

          Comment


            #6
            With those conditions it doesn't sound like a dns or dhcp issue.

            Originally posted by toshiro View Post
            As a firewall I'm using a linux server (of course ), it has installed Ubuntu server 10.04.4 LTS.
            Eeexcellent! When the issue occurs on your own computer, does it also occur on the firewall? Can you ssh into it and check? (Can you even ping it?) This would be very informative.
            I'd rather be locked out than locked in.

            Comment


              #7
              Originally posted by SecretCode View Post
              With those conditions it doesn't sound like a dns or dhcp issue.


              Eeexcellent! When the issue occurs on your own computer, does it also occur on the firewall? Can you ssh into it and check? (Can you even ping it?) This would be very informative.
              No, the firewall works ok. I'm currently having this problem so I made a few tests, I found that DNS resolution works ok, but I can't access anything from the computer, but I do have access from the firewall.

              Example:

              LOCAL COMPUTER:

              dig mail01.secureserverdot.com

              ; <<>> DiG 9.8.1-P1 <<>> mail01.secureserverdot.com
              ;; global options: +cmd
              ;; Got answer:
              ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55953
              ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

              ;; QUESTION SECTION:
              ;mail01.secureserverdot.com. IN A

              ;; ANSWER SECTION:
              mail01.secureserverdot.com. 78001 IN A 216.14.208.15

              ;; AUTHORITY SECTION:
              secureserverdot.com. 34673 IN NS ns3.secureserverdot.com.
              secureserverdot.com. 34673 IN NS ns1.secureserverdot.com.
              secureserverdot.com. 34673 IN NS ns2.secureserverdot.com.

              ;; ADDITIONAL SECTION:
              ns1.secureserverdot.com. 77955 IN A 216.14.208.17
              ns2.secureserverdot.com. 77955 IN A 216.14.208.18
              ns3.secureserverdot.com. 76916 IN A 216.14.218.254

              ;; Query time: 0 msec
              ;; SERVER: 192.168.0.1#53(192.168.0.1)
              ;; WHEN: Fri Aug 17 21:50:26 2012
              ;; MSG SIZE rcvd: 162


              ping mail01.secureserverdot.com
              PING mail01.secureserverdot.com (216.14.208.15) 56(84) bytes of data.
              From solaria.empire.org.uy (192.168.0.14) icmp_seq=1 Destination Host Unreachable
              From solaria.empire.org.uy (192.168.0.14) icmp_seq=2 Destination Host Unreachable
              From solaria.empire.org.uy (192.168.0.14) icmp_seq=3 Destination Host Unreachable


              FIREWALL:

              ping mail01.secureserverdot.com
              PING mail01.secureserverdot.com (216.14.208.15) 56(84) bytes of data.
              64 bytes from mail01.secureserverdot.com (216.14.208.15): icmp_seq=1 ttl=46 time=233 ms
              64 bytes from mail01.secureserverdot.com (216.14.208.15): icmp_seq=2 ttl=46 time=237 ms
              64 bytes from mail01.secureserverdot.com (216.14.208.15): icmp_seq=3 ttl=46 time=233 ms


              I don't know, is like the routing table is screwed every time I get a new IP.

              Comment


                #8
                A couple things about your dig... the 0 millisecond response time combined with the long TTL (currently shown as 78001 seconds) hints that the answer came from the cache on your DNS server.

                The traceroute utility could be useful here. You'll have to install it from the Ubuntu repository first. Then, when your network is behaving correctly, run traceroute 4.2.2.1 and save the output to a file. Then, when the problem recurs, try the command again and compare the difference.

                I'm curious why your ISP is forcing an IP address change every 12 hours. Normally, DHCP requests a lease renewal when 50% of the lease time expires, and the renewal is granted. You should be able to keep the same north-side IP address for so long as you keep your external interface enabled.

                Comment


                  #9
                  Originally posted by SteveRiley View Post
                  A couple things about your dig... the 0 millisecond response time combined with the long TTL (currently shown as 78001 seconds) hints that the answer came from the cache on your DNS server.

                  The traceroute utility could be useful here. You'll have to install it from the Ubuntu repository first. Then, when your network is behaving correctly, run traceroute 4.2.2.1 and save the output to a file. Then, when the problem recurs, try the command again and compare the difference.

                  I'm curious why your ISP is forcing an IP address change every 12 hours. Normally, DHCP requests a lease renewal when 50% of the lease time expires, and the renewal is granted. You should be able to keep the same north-side IP address for so long as you keep your external interface enabled.
                  Ok, I'll try your suggestions and I'll get back with the results.

                  Regarding the IP renewal policy, I think is pathetic, but unfortunately there's nothing I can't do about it. I was told that the reason for that is to avoid the users for providing internet services (hosting, etc) from people using this ADSL service, you have to pay more (around 4 times the cost of my plan) to get a plan with a static IP

                  Comment


                    #10
                    I can't help feeling some more comprehensive data would help ...

                    When things are working normally:
                    From your firewall server:
                    ping <your local computer IP>
                    ping 4.2.2.1
                    ping google.com # or any well-known site
                    dig google.com
                    traceroute 4.2.2.1
                    route -n

                    From your own computer: the same tests, plus ping your firewall

                    (Yes, that's 12 tests to do in each set of conditions!)

                    When things are failing:
                    same tests from both your firewall and your own computer
                    Last edited by SecretCode; Aug 19, 2012, 06:11 AM.
                    I'd rather be locked out than locked in.

                    Comment


                      #11
                      Originally posted by SecretCode View Post
                      releasing and renewing the DHCP address might fix it (and more importantly help show why the problem is occurring):
                      Code:
                      sudo dhclient -r && sudo dhclient
                      Hmm, don't do this. When I try it (on 11.10 still), dhcp does not refresh - I lose my IP address.

                      It seems to work if you explicitly specify the interface, which wasn't necessary last time I tried this (on some earlier 'buntu version).

                      Code:
                      sudo dhclient -r && sudo dhclient wlan0
                      This is worth a try.
                      I'd rather be locked out than locked in.

                      Comment


                        #12
                        I came back with new data

                        My exiternal IP has just been reconnected ... look at this:

                        -- From my desktop computer:

                        [root->~] traceroute mail01.secureserverdot.com
                        traceroute to mail01.secureserverdot.com (216.14.208.15), 30 hops max, 60 byte packets
                        1 solaria.empire.org.uy (192.168.0.14) 2996.419 ms !H 2996.415 ms !H 2996.409 ms !H


                        -- From my firewall:

                        [root->~]# traceroute mail01.secureserverdot.com
                        traceroute to mail01.secureserverdot.com (216.14.208.15), 30 hops max, 60 byte packets
                        1 cor1bras1.antel.net.uy (200.40.21.3) 20.369 ms 23.033 ms 25.635 ms
                        2 ibb2cor2-7-2-92.antel.net.uy (200.40.21.205) 41.588 ms 41.817 ms 41.815 ms
                        3 ibb2agu2-8-2.antel.net.uy (200.40.16.165) 53.755 ms 53.969 ms 54.162 ms
                        4 ibr3agu1-p2.antel.net.uy (200.40.18.166) 44.266 ms 46.215 ms 47.410 ms
                        5 So4-1-1-0-gramiana4.red.telefonica-wholesale.net (84.16.7.125) 214.855 ms 217.262 ms 219.680 ms
                        6 176.52.251.198 (176.52.251.198) 307.615 ms 287.057 ms Xe5-0-1-0-grtmiana3.red.telefonica-wholesale.net (94.142.126.198) 204.492 ms
                        7 Xe-1-0-1-0-grtwaseq2.red.telefonica-wholesale.net (84.16.12.181) 204.563 ms 190.302 ms Xe9-0-0-0-grtmiabr3.red.telefonica-wholesale.net (213.140.37.38) 270.677 ms
                        8 Xe0-0-0-0-grtwaseq6.red.telefonica-wholesale.net (94.142.126.205) 197.423 ms Xe1-0-0-0-grtwaseq2.red.telefonica-wholesale.net (94.142.127.189) 193.074 ms Xe0-0-0-0-grtwaseq6.red.telefonica-wholesale.net (94.142.126.205) 198.761 ms
                        9 Tinet-2-0-0-0-grtwaseq2.red.telefonica-wholesale.net (213.140.55.106) 197.207 ms Xe0-0-0-0-grtwaseq6.red.telefonica-wholesale.net (94.142.126.205) 193.013 ms 194.018 ms
                        10 xe-2-0-0.bos11.ip4.tinet.net (89.149.182.170) 212.196 ms Tinet0-1-2-0-grtwaseq2.red.telefonica-wholesale.net (213.140.55.182) 201.182 ms xe-2-0-0.bos11.ip4.tinet.net (89.149.182.170) 200.621 ms
                        11 navisite-gw.ip4.tinet.net (216.221.159.234) 201.855 ms xe-2-0-0.bos11.ip4.tinet.net (89.149.182.170) 196.236 ms 198.006 ms
                        12 216.251.234.181 (216.251.234.181) 210.090 ms navisite-gw.ip4.tinet.net (216.221.159.234) 198.287 ms 216.251.234.181 (216.251.234.181) 208.388 ms
                        13 minairt2501-gi9-1.albz1.navisite.net (207.211.1.6) 209.856 ms 212.016 ms 212.079 ms
                        14 mail01.secureserverdot.com (216.14.208.15) 200.524 ms 196.787 ms minairt2501-gi9-1.albz1.navisite.net (207.211.1.6) 206.194 ms


                        What I've noticed is that kmail was checking for new emails when the IP reconnected ... it looks like a connection (or route) maybe be established and then it got a new IP and it fails from that point, maybe a connection is established and didn't realised it has been broken?

                        Comment


                          #13
                          The !H in traceroute means that the host is unreachable.

                          When your ISP changes your public-facing IP address, the routing and ARP tables currently plumbed in the kernel become invalid. Perhaps this might fix it:
                          Code:
                          sudo service networking restart
                          You need to call your ISP and get them to change their practice. It's wrong, it causes all kinds of breakage, and TCP/IP really isn't designed to be jerked around like that.

                          Comment


                            #14
                            Originally posted by SteveRiley View Post
                            The !H in traceroute means that the host is unreachable.

                            When your ISP changes your public-facing IP address, the routing and ARP tables currently plumbed in the kernel become invalid. Perhaps this might fix it:
                            Code:
                            sudo service networking restart
                            You need to call your ISP and get them to change their practice. It's wrong, it causes all kinds of breakage, and TCP/IP really isn't designed to be jerked around like that.
                            Doing 'service networking restart' certainly fix that; If you read my initial post you'll see I do this to fix everything, what I want is to know why it's behaving that way now so I can find a workaround (I've been using linux for years in the same situation and never had any problem before, so something in Kubuntu, Linux, etc have changed in the last release).

                            Unfortunately asking my ISP politics is out of the question, it's not possible to do anything at all

                            Comment

                            Working...
                            X