corporate firewall blocks apt-get, but only where installed, not LiveCD?

[danielk]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

See this thread:
http://kubuntuforums.net/forums/index.php?topic=3082374

It may help, as it has an identical sources.list file (the repositories are commented out).

That person is having a problem with the incorrect repositories enabled for what they want to do. My issue is I can't even get to the server.

Try uncommenting (by removing the the # from the lines beginning with 'deb' or 'deb-src').

I have to manually re-enable all of the repositories on my list after every update attempt as they get marked as 'failed to verify' when the installer can't contact them. My sources.list file got uploaded after a failed attempt, hence the # symbols.

Why am I not surprised ... mumble, mumble ... back to square one then:

Yeah, pretty much. For a short while I could have sworn our networking guys were advocating us taking the computer(s) home to run updates...

At least for the sake of completeness, I'd reset the (virtual) Kubuntu system to static IP and DNS, respectively, and kill DHCP (as well as "avahi") for the time being.

When I am back in the office, I will do try that. I'm currently at a different site, and I can't ssh back into the machine.

# Just to ensure that the FTP protocol won't get blocked by the firewall(s), I'd fire up an client and try to download some stuff, e.g. from http://www.penguin.ch/repository/.

I was able to download via FTP without any problems. We tried that when we first started having problems.

Postscript: after several hours of poring over absolutely unspectacular source code, I decided to "change (my) target" and installed the Guarddog firewall application on an system working up to now ...

Of course, with all and every protocol blocked, apt-get got nowhere, so to speak - but in order to get things going again, I had to permit the Network File System (NFS) protocol

This sounds interesting. I will relay this to the networking guys, and see what they have to say about it. Was it really slow, or just stopped dead?

BTW, I really appreciate all the help on this. I've run this past all my local linux buddies, and they kinda sit there and scratch their head.

[penguin.ch]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

Was it really slow, or just stopped dead?

Dead as a brick.

In addition, Guarddog may prove more helpful in order to find out what APT factually is trying to do than examining the latter's source code

I've run this past all my local linux buddies, and they kinda sit there and scratch their head.

It's kind of comforting to know that I may be not quite as dumb as this problem is making me feel >

[danielk]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

Was it really slow, or just stopped dead?

Dead as a brick.

Hmm. This appears stone cold dead, but if you let it sit for 10-20 minutes, sometimes instead of timing out, it will show some activity. Granted it's very little, but anything is more than nothing.

In addition, Guarddog may prove more helpful in order to find out what APT factually is trying to do than examining the latter's source code

I've run this past all my local linux buddies, and they kinda sit there and scratch their head.

It's kind of comforting to know that I may be not quite as dumb as this problem is making me feel >

Don't feel bad. No one here has any idea what happened. The networking guys were saying that for whatever reason the session would transfer 20mb of data, then break, and was thinking it was linux itself breaking it.

When we would do the initial install, we would do it disconnected from the network so there would be no traffic, just in case. It didn't make a difference. Once it was installed, updates were no more.

They opened a ticket with Cisco, but they are not hopeful, since we can't really say what broke, just point at the part that isn't working. We can't be the only place that has a PIX firewall with linux boxes behind it.

[penguin.ch]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

This appears stone cold dead, but if you let it sit for 10-20 minutes, sometimes instead of timing out, it will show some activity. Granted it's very little, but anything is more than nothing.

Hmmm ... "Swiss speed" is definitely not what my Guarddog experiments have been resulting in ... mumble, mumble ...

In the meantime, however, I may have been able to reproduce your problem - as well as resolve it by disabling IPv6 (as mentioned by another poster ...):

Could you please, at least for the sake of falsification (...), issue the following console command to the Kubuntu system, then "re-boot & re-try":

echo 'KDE_NO_IPV6=true' >> /etc/environment

[danielk]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

Hmmm ... "Swiss speed" is definitely not what my Guarddog experiments have been resulting in ... mumble, mumble ...

In the meantime, however, I may have been able to reproduce your problem - as well as resolve it by disabling IPv6 (as mentioned by another poster ...):

Could you please, at least for the sake of falsification (...), issue the following console command to the Kubuntu system, then "re-boot & re-try":

echo 'KDE_NO_IPV6=true' >> /etc/environment

Will do. I let the person on site know, and they should get back to me. I will post results as soon as I hear.

Also, heard from the networking guys, we do not support IPv6, and from Cisco, regarding captured packets. I can't copy/paste the email in a public forum due to our security policies, but I can sum up.

First packet is sending SYN to 91.189.88.31,
second is ACK to 91.189.89.6,
third is SYN again,
fourth is ACK again,
fifth is a reset from our side to 91.189.88.31.

They arent certain why we are sending a reset, and required more detailed info. Also, the capture didnt show any return packets from the server to the kubuntu box, (think they forgot that part of the command). They are going to try and recapture more data, and see what comes up.

[penguin.ch]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

They are going to try and recapture more data, and see what comes up.

In this case, a closer look at the way APT communicates may still prove helpful ...

To ease things up, I copied the complete, unaltered source code to my file server.

In particular from the HTTP Aquire Method a bit jostler might gain some insight 8)

[danielk]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

In the meantime, however, I may have been able to reproduce your problem - as well as resolve it by disabling IPv6 (as mentioned by another poster ...):

Could you please, at least for the sake of falsification (...), issue the following console command to the Kubuntu system, then "re-boot & re-try":

echo 'KDE_NO_IPV6=true' >> /etc/environment

Tried the IPv6 command. no difference, same issue as before. We are going to try changing all the repository addresses to ftp sites instead of http to see if that makes a difference as noted by one of the other people in our group. Will post as soon as I know. Still haven't heard anything more from Cisco yet.

[danielk]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

We are going to try changing all the repository addresses to ftp sites instead of http to see if that makes a difference as noted by one of the other people in our group. Will post as soon as I know.

Well, update as follows. The person on site did a search and replace for HTTP and replaced it with FTP (not a reliable method,i know, since they may not have a matching ftp server, but anyway). It worked?!? Apt updated and appeared to be working normally. So it appears to be something specific to Apt, while using HTTP sources, while behind the Cisco PIX firewall. While I am happy it works, I still am trying to find the source of the issue.

To ease things up, I copied the complete, unaltered source code to my file server.

In particular from the HTTP Aquire Method a bit jostler might gain some insight 8)

I'm not certain what you need me to do here. I know squat about code.

[penguin.ch]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

I'm not certain what you need me to do here.

Just another one of my silly ideas: maybe one of your C code "pros" would be able to find the "de-facto bug" from within the sources (in particular: the "method(s)" implementations) ...

[danielk]

Re: corporate firewall blocks apt-get, but only where installed, not LiveCD?

Still stuck. Threw a Feisty install DVD in another test machine, loaded it up, and it appeared that all was peachy. Went to try and get the headers, and IT WORKED!! Started the update, got through a couple files, and it stopped dead. I'm guessing we hit that 20mb limit/issue the networking group was telling us about.

Went into the options within Adept, and one of the them was a dropdown with which server group to use. We set it for US servers, tried to get headers again, and it worked?? We figured at this point, our networking group had enabled some filter to block traffic by country or something. We installed some software to make sure the connection would stay working, with the 20mb limit or whatever that was about. It appears that all is good.

Here's where it gets weird. When we went to verify that the country of origin was the issue, by changing the server back to Ubuntu Main, it still worked. > Headers came down no problem, then we installed some more software, aprox 30mb of stuff, just to see if it would die after 20mb. It was a little slow, but nothing horrible.

So, after installing 7.04 on one of the machines that was having issues with 6.06, which initially failed with the default server setup, then worked via US servers, and now mysteriously works after going back to Ubuntu Main servers, I can honestly say I have no idea what the heck is going on.