Project

General

Profile

Bug #3612

Packages through proxy doesn't work since change to HTTPS

Added by Chris Buechler over 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Category:
Package System
Target version:
Start date:
04/20/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.1.x
Affected Architecture:

Description

Since changing from HTTP to HTTPS for packages, it seems connectivity doesn't work if via a proxy. Multiple reports here:
https://forum.pfsense.org/index.php?topic=75265.0;topicseen

I haven't had a chance to test it yet myself via proxy. It reportedly does work just changing HTTPS to HTTP in globals.inc for packages.pfsense.org.

History

#1 Updated by Chris Buechler over 5 years ago

  • Affected Version set to 2.1.x

#2 Updated by tall tree over 5 years ago

I have just upgraded from 2.1 to 2.1.3 and now have this issue too. pfSense is configured to use an external proxy server in System: Advanced: Miscellaneous. The Proxy URL is of the form http://proxy.lan and the proxy port is set to 3128, the local squid proxy. That worked fine in 2.1 for both pfsense updates (I used it to upgrade to 2.1.3) and package lists and installation. Now I can still see the pfSense version update status on the System Information widget. But the Available Packages page gives this message:
Unable to communicate with https://packages.pfsense.org. Please verify DNS and interface configuration, and that pfSense has functional Internet connectivity.

Checking the logs on the squid proxy server, I see the following log for the pfSense version update status check:

1400767651.268      0 192.168.1.1 TCP_MEM_HIT/200 389 GET http://updates.pfsense.org/_updaters/amd64/version - NONE/- application/octet-stream

Checking for available packages shows the following proxy logs:

1400767664.876      0 192.168.1.1 NONE/501 2052 POST NONE://packages.pfsense.org:443/xmlrpc.php - NONE/- text/html
1400767667.873      0 192.168.1.1 NONE/501 2053 POST NONE://packages.pfsense.org:443/xmlrpc.php - NONE/- text/html

The thing that stands out for me there is the protocol type of NONE. I can't recall what all the squid log fields are, but surely the NONE:// should be https:// ??

#3 Updated by tall tree over 5 years ago

I made the change to /etc/inc/globals.inc mentioned in the Bug Description and can successfully see the Available Packages. These are the squid proxy logs from that session:

1400768708.590      0 192.168.1.1 TCP_MEM_HIT/200 389 GET http://updates.pfsense.org/_updaters/amd64/version - NONE/- application/octet-stream
1400768777.921      0 192.168.1.1 NONE/501 2052 POST NONE://packages.pfsense.org:443/xmlrpc.php - NONE/- text/html
1400768780.982      0 192.168.1.1 NONE/501 2053 POST NONE://packages.pfsense.org:443/xmlrpc.php - NONE/- text/html
1400769199.880    512 192.168.1.1 TCP_MISS/200 1834 POST http://packages.pfsense.org/xmlrpc.php - DIRECT/208.123.73.88 text/html

I then went on to re-install nmap successfully. Here are the logs:

1400769501.671    516 192.168.1.1 TCP_MISS/200 2611 POST http://packages.pfsense.org/xmlrpc.php - DIRECT/208.123.73.88 text/html
1400769502.875   1195 192.168.1.1 TCP_MISS/200 11227 CONNECT packages.pfsense.org:443 - DIRECT/208.123.73.88 -
1400769511.064   7838 192.168.1.1 TCP_MISS/200 6083396 CONNECT files.pfsense.org:443 - DIRECT/208.123.73.81 -

And there we see that I've downloaded the package via https anyway.

#4 Updated by Renato Botelho over 5 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

A fix was pushed few weeks ago on branch master 81c8b51db2

I cherry-picked it to RELENG_2_1 today - 1930a63e81 and now a gitsync should be enough to properly fix it.

#5 Updated by Jim Thompson about 5 years ago

  • Assignee set to Renato Botelho

#6 Updated by Chris Buechler about 5 years ago

  • Status changed from Feedback to Resolved

fixed

Also available in: Atom PDF