I've gotten permission to use a Linux OS on my workplaces network, but I strongly suspect that IT has a product that they themselves don't realize is configured to block package managers.

Over the last week I have tried Ubuntu and Fedora and spent close to 30 hours fiddling with proxy setting, and the only thing that doesn't work are apt and dnf. Everything else is fine. There are a number of centOS servers running running in the building, so out of frustration I installed centOS, and yum worked on the first try (with proxy settings). My guess is that the person who set up the servers long ago white listed yum or something.

Is there some way I can prove one way or the other that our workplace proxy is or isn't interfering with apt or dnf?

UPDATE: response when using wget instead of apt-install.

wget http://ftp.riken.jp/Linux/ubuntu/dists/xenial-updates/InRelease

Tcpdumping this request shows it does not contain the same Debian APT-HTTP header as it does when using APT.

Everything appears to be normal.

Hash: SHA512

Origin: Ubuntu
Label: Ubuntu
Suite: xenial
Version: 16.04
Codename: xenial
Date: Thu, 21 Apr 2016 23:23:46 UTC
Architectures: amd64 arm64 armhf i386 powerpc ppc64el s390x
Components: main restricted universe multiverse
Description: Ubuntu Xenial 16.04
 f52f354808b6658dcd8fc47c813cb087        501150562 Contents-amd64
 605d6257d0144333d320d9aa750b19d2         32582143 Contents-arm64.gz

... many many lines ommited...

 e201ab73d77c0208d5dcd4844b6215bc5e18b49d9f9b58d0fb627c47c0438ecd          9802268 universe/source/Sources.gz
 06d5766fba7d0be3e2d0c801f26d10aa8b4e6e8618711445c1373b535777c84b         35812491 universe/source/Sources
 aefe5a7388a3e638df10ac8f0cd42e6c2947cc766c2f33a3944a5b4900369d1e          7727612 universe/source/Sources.xz
Acquire-By-Hash: yes
Version: GnuPG v1.4.11 (GNU/Linux)

  • Make a request, through a means you have already made work with the proxy, for one of the URLs that is failing for apt, and edit the results in. Apr 6, 2017 at 2:14
  • Updated. Looks like everything is working as it should be, at least when using wget. With apt the response never comes back and it times out.
    – Erik
    Apr 6, 2017 at 3:08

1 Answer 1


yes, take your Ubuntu or Fedora system that is NOT connecting to whatever repository when on your work network, and change nothing on that system other than the means which it connects to the internet.

One method that works with a Microsoft Windows system is to connect an android phone via USB and use wifi tethering so the Windows system accesses the internet via your phone through your verizon, at&t, sprint network which obviously does not have a proxy. I must admit I've never tried this with linux, however many internet articles talk about android linux tethering. Or if possible bring the system to some other location to get internet access without a proxy.

Other way is get the website of the repository that doesn't seem to work, put it in to internet explorer of a windows pc set up by IT and see if the specific site is specifically blocked by the proxy.

Other possibility is you don't have your company/corporate certificate authority installed in linux, and your update manager is failing not because it's "blocked by the proxy" but because it cannot establish a secure https connection. See here: "your connection is not private" on linux, but ok on windows

  • Thanks for the ideas! I have recently connected to an external network as you described, and that worked fine I was able to install git and some of the other tools I needed. None of the websites appear to be blocked explicitly, as I can visit them in a browser in both Windows and Linux. The certictaes link you provided looks promising, but I doubt that's the case since yum on centOS worked without a certificate.
    – Erik
    Apr 6, 2017 at 3:41
  • Unless yum uses http by default? Would an ssl cert be required for package managers but not for general web browsing?
    – Erik
    Apr 6, 2017 at 3:44
  • I can speak from experience for SLES and the Novell repositories which definitely use an https connection, and to have any kind of https connection requires a valid SSL certificate regardless of what is doing a connection (web browser, package manager, whatever). Package managers sometimes they can do a bunch of things unbeknownst to you behind the scenes (they are managing it for you) making it difficult to troubleshoot. But you are correct if you don't have a valid SSL cert then your web browser will never make any https connection, but it will do fine all day long for plain old http://
    – ron
    Apr 6, 2017 at 21:14
  • and when you don't have a valid cert, your web browser should throw up a warning saying your connection is not secure and will give option to proceed or gracefully exit, but a package manager usually just hangs then times out saying failed. Also a good idea to read as much documentation about how the package manager that's failing on you works.
    – ron
    Apr 6, 2017 at 21:21
  • For the meantime, I've managed to get dnf working so I'm using Fedora now, but some other people in the company are still struggling with Ubuntu's apt. I was able to confirm that the SSL cert is working, and https services (for example wget) work with https addresses. I still don't known why apt doesn't work. I'll look into the documentation like you suggested.
    – Erik
    Apr 8, 2017 at 11:29

You must log in to answer this question.

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