When I run apt-get update on my machine it gets stuck at:

100% [Connecting to security.ubuntu.com (2001:67c:1562::15)] [Connecting to archive.canonical.com (2001:67c:1360:8c01::16)]

I have made no recent changes to the system and use my home network which worked fine previously.

I can't explain why it switched to using IPv6.
I have IPv6 set to ignore for the wireless network:

enter image description here

Ouput of ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: mlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 4c:0b:be:22:0a:b4 brd ff:ff:ff:ff:ff:ff
inet brd scope global dynamic mlan0
   valid_lft 1814086sec preferred_lft 1814086sec
inet6 ::d5:b551:28db:2789:225/64 scope global temporary dynamic 
   valid_lft 604483sec preferred_lft 85483sec
inet6 ::d5:4e0b:beff:fe22:ab4/64 scope global mngtmpaddr dynamic 
   valid_lft 604779sec preferred_lft 86379sec
inet6 fe80::4e0b:beff:fe22:ab4/64 scope link 
   valid_lft forever preferred_lft forever
  • Change the IP addressing to IPv4 and then try again..
    – heemayl
    May 6, 2015 at 22:33
  • Why are you using IPv6? Like heemayl said, change to using IPv4, under Network Settings>[Adapter]>Advanced. May 6, 2015 at 23:32
  • 1
    It looks as if you may have a host sending router advertisements with 0:0:0:d5::/64. This range is listed as reserved by IETF, so that is definitely not a valid prefix to be advertising. If those RAs have stopped already, it may be impossible to find out, where they came from. In that case all you can really do is to restart the network interface and the problem goes away. If the RAs are still being send, then you can look at a packet capture to see which MAC they are coming from.
    – kasperd
    May 7, 2015 at 8:39
  • 1
    Other than the misconfigured IPv6 connectivity, another contributor to your problem is the lack of RFC 6555 support in apt-get. Had apt-get followed RFC 6555, you would never have noticed any problem.
    – kasperd
    May 7, 2015 at 8:43
  • 1
    Your local router is doing something wrong, and giving you invalid IPv6 addresses. Check and fix the router's configuration. May 7, 2015 at 19:40

5 Answers 5


This worked for me, courtesy of Zach Adams (https://zach-adams.com/2015/01/apt-get-cant-connect-to-security-ubuntu-fix/):

Turns out this is an issue where connecting over IPv6 on some servers causes them to get stuck at this point. The fix is really simple.

Open /etc/gai.conf

Under the line

# For sites which prefer IPv4 connections change the last line to

Uncomment the following line by removing the #:

# precedence ::ffff:0:0/96 100

This will allow you to still use IPv6 but sets IPv4 as the precedence so that apt-get won’t get stuck.

  • 23
    Thanks! This answer is much better than just slavishly disabling ipv6.
    – Cyrusmith
    Jun 17, 2016 at 2:30
  • 2
    If you get no luck with this, try that: askubuntu.com/a/759540/4246
    – Gauthier
    Oct 30, 2016 at 21:24
  • 2
    OMG that helped so much! Jan 9, 2017 at 5:29
  • 4
    Note: This is still valid on 14.04 and 16.04 LTS versions
    – Elder Geek
    Jul 22, 2017 at 18:59
  • 2
    Worked for me on Linux Mint 18.1 & 18.2. This should be default.
    – mat
    Jul 24, 2017 at 17:42

The IPv6 setting for the network were ignored, but disabling IPv6 via /etc/sysctl.conf worked:

Add the following lines at the bottom of /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Run sudo sysctl -p to reload the /etc/sysctl.conf settings.

  • 7
    That's not how you should be doing. Those lines means once you connect to a network, which actually has IPv6, you'll get a less reliable connection than you were supposed to. Also, those lines do nothing to fix the root cause of your problem, which you haven't even identified.
    – kasperd
    May 7, 2015 at 8:33
  • 2
    I do not need IPv6 anywhere so this works just fine.
    – Pabi
    May 7, 2015 at 8:42
  • 4
    That's just silly, because for connecting to hosts on the same network segment there are multiple advantages in IPv6 link-local addresses compared to IPv4.
    – kasperd
    May 7, 2015 at 9:39
  • 2
    Can't do that from my phone ;) Lets just agree that we disagree.
    – Pabi
    May 7, 2015 at 13:00
  • 4
    Do what you want to do. I just comment to ensure that anybody else who might come across the same problem knows that making the suggested changes to sysctl.conf is going to cause problems eventually.
    – kasperd
    May 7, 2015 at 13:10

A better approach is to use apt-get as follows instead of editing gai.conf file.

sudo apt-get -o Acquire::ForceIPv4=true update

If you want to make this persistent just add an alias for 'apt-get' in your bash file.

  • But wouldn't this make connections that could be IPv6 all IPv4?
    – metame
    Feb 16, 2017 at 20:35
  • @metame that's the whole point. OP said his IPv6 is disabled, and attempting to use it causes problems. Apr 10, 2017 at 7:22

Other solutions did not help ... in my case I created an aws ec2 instance Ubuntu 18.04 using

Auto-assign Public IP -> no pick disable

after trying all suggested solutions I threw up my hands and killed that and created a new ec2 instance using

Auto-assign Public IP -> yes  Use subnet setting (Enable) 

and it worked fine ... apt-get update && apt-get upgrade are happy now

  • for me it was the firewall issue. allowing outbound connections worked for me.
    – Akhil
    Feb 4, 2022 at 10:44

On WSL(Ubuntu) this can be caused by some Antivirus rule related to wsl, preventing outbound plain-http access.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .