Unable to update repository …

banana222

I can not install new packages or do upgrades. Every time I receive the following message(s):

Updating pfSense-core repository catalogue...
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
Unable to update repository pfSense
All repositories are up-to-date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
	pkg: 1.7.2_2 -> 1.9.4_1 [pfSense]

2 MiB to be downloaded.

Even if I choose "yes" for the last step, pkg will never be upgraded.

How can I get more information what is going wrong? I have no idea where to start …

In case it is useful:

 pkg info -x pfSense
pfSense-2.3.1
pfSense-Status_Monitoring-1.3_1
pfSense-base-nanobsd-2.3.1
pfSense-default-config-serial-2.3.1
pfSense-kernel-pfSense_wrap-2.3.1
pfSense-rc-2.3.1
pfSense-repo-2.3.1
php56-pfSense-module-0.12

cat /usr/local/etc/pkg/repos/pfSense.conf
FreeBSD: { enabled: no }

pfSense-core: {
  url: "pkg+https://pkg.pfsense.org/pfSense_v2_3_1_i386-core",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/local/share/pfSense/keys/pkg",
  enabled: yes
}

pfSense: {
  url: "pkg+https://pkg.pfsense.org/pfSense_v2_3_1_i386-pfSense_v2_3_1",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/local/share/pfSense/keys/pkg",
  enabled: yes
}

Thanks a lot for any help

Mark

banana222

Is there really nothing I can do?
Any log files which might contain more detailed information?
Any "verbosity" settings which might give me more information?

PiBa

Tried?: pkg-static install -f pkg

banana222

@PiBa Thanks a lot for your proposal, however, all pkg commands fail with the same error.

Meanwhile I was able to trace the problem further down. For some reason, the files can not be downloaded

This step seems to fail repeatedly …

DBG(1)[66953]> Fetch: fetching from: https://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz with opts "i"

"Manually" fetching the file also does not work and results in a timeout:

fetch -vv -4 -T 300 "https://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz"
looking up files01.netgate.com
connecting to files01.netgate.com:443
fetch: https://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz: Operation timed out

From my browser, however, I can download the file "https://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz" without problems.

It does not seem to be a connectivity problem, because I can download other files to the pfSense device via ftp or http without problems …

fetch -o /dev/null http://speedtest.tele2.net/10MB.zip
/dev/null                                     100% of   10 MB 1543 kBps 00m07s

fetch -o /dev/null http://speedtest.tele2.net/10MB.zip
/dev/null                                     100% of   10 MB 1543 kBps 00m07s

I checked this post (https://forum.pfsense.org/index.php?topic=119261.0), however, did not find a solution which worked for me.

Any ideas how I can get the download working?

PiBa

Do you have any IPv6 stuff configured?

Perhaps setting pfSense to prefer IPv4 could help then, this can be done under system/advanced/. Other option might be that IPv6 tends to have issues with the MTU value being wrong setting that to something lower might help..

banana222

@PiBa:

Do you have any IPv6 stuff configured?

Perhaps setting pfSense to prefer IPv4 could help then, this can be done under system/advanced/. Other option might be that IPv6 tends to have issues with the MTU value being wrong setting that to something lower might help..

Again, thanks a lot for your feedback.

For IPv6 I have configured nothing I am aware of.

Actually I have tried several options of the fetch command, including "fetch -4" which should make sure that IPv4 is used for fetching. But nothing worked.

banana222

Getting closer ….

Actually, fetching works if I do not use https but http ....

fetch -vv -4 -T 300 "http://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz"
looking up files01.netgate.com
connecting to files01.netgate.com:80
requesting http://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz
remote size / mtime: 2568564 / 1486786479
pkg-1.9.4_1.txz                               100% of 2508 kB  257 kBps 00m10s

So maybe there is a problem with authentication? Maybe invalid certificate?

A workaround might be to tell pfSense to use http instead of https. But I have no idea how to do that. I also think, this is not a long term solution because of security risks.

PiBa

For comparison what it looks like for me (on 2.4beta).

[2.4.0-BETA][root@pfSe.localdomain]/root: fetch -vv -4 -T 300 "https://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz"
looking up files01.netgate.com
connecting to files01.netgate.com:443
SSL options: 83004bff
Peer verification enabled
Using CA cert file: /usr/local/etc/ssl/cert.pem
Verify hostname
TLSv1.2 connection established using ECDHE-RSA-AES256-GCM-SHA384
Certificate subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.netgate.com
Certificate issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
requesting https://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz
local size / mtime: 2568564 / 1486786479
remote size / mtime: 2568564 / 1486786479
pkg-1.9.4_1.txz                               100% of 2508 kB  143 kBps 00m17s

I presume you've got the /usr/local/etc/ssl/cert.pem file and filled with some ca certs.?.

Do other fetches from https sites also fail?

Run a tcpdump while performing the fetch and check if its even connecting/exchanging traffic..
tcpdump -ni em0 "host 162.208.119.40"
Or write it to a file, download it, and inspect it with wireshark.?.
tcpdump -w /tmp/fetchpkg.pcap -ni em0 "host 162.208.119.40"
Other last resort of me would be running 'truss' before the fetch command, maybe thatl tell whats going on..

Might be just changing the 'pkg+https' to 'pkg+http' in the pkg config file would resolve the issue for the moment.? But that wont tell what happened..

banana222

@PiBa:

For comparison what it looks like for me (on 2.4beta).

[2.4.0-BETA][root@pfSe.localdomain]/root: fetch -vv -4 -T 300 "https://files01.netgate.com/pfSense_v2_3_1_i386-pfSense_v2_3_1/All/pkg-1.9.4_1.txz"
looking up files01.netgate.com
connecting to files01.netgate.com:443
SSL options: 83004bff

Wow, thank you! You really put a lot of effort in this!

I followed your proposals and it seems that the https packets are blocked in the pfSense already…

Status/System Logs/Firewall/Normal View

 	Jun 4 14:13:11 	lo0 	192.168.178.2:443		192.168.178.2:12827		TCP:SA
	[...]
	Jun 4 14:13:08 	lo0 	192.168.178.2:443		192.168.178.2:12827		TCP:SA

I tried and tried but I did not manage to make the loopback traffic leave the WAN interface.
The GUI only offers selection from WAN, LAN1, LAN2 and LAN (the latter is just bridging the other interfaces).

I tried source addresses 192.168.178.2, 127.0.0.1 as source addresses, however, without success.

Also, when I try Status/System Logs/Firewall/Normal View -> Easy rule to add the rule to the filter rules and
to analyse/adapt (to arbitrary ports) it there, it does not appear in the rule list.

As a last resort I even temporarily deactivated all blocking rules, but still the Io0 traffic is blocked.

Might be just changing the 'pkg+https' to 'pkg+http' in the pkg config file would resolve the issue for the moment.? But that wont tell what happened..

I got the upgrade working with this, but after each upgrade the conf file goes back to https. But anyway, a cumbersome working solution is 100% than the situation before ;-)

If you can give me another hint, how to get the firewall working with https connections from pfSense it would be great. I any case, thank you very much for your valuable support and your proposals.

With kind regards

Mark

PiBa

The part i don't understand is why http works and https doesnt, regarding firewallrules and passing it there should be no difference between the two..

Also your blocked traffic shows both source and destination to be a local ip.. Would expect one of them to be using the remote ip..

No packages like snort or squid performing traffic interception/inspection/blocking? or traffic shaping/limiting?

Take a look at /tmp/rules.debug are there any rules present for https / 443 that might interfere and are not there for http / 80 ?

banana222

@PiBa:

The part i don't understand is why http works and https doesnt, regarding firewallrules and passing it there should be no difference between the two..

Also your blocked traffic shows both source and destination to be a local ip.. Would expect one of them to be using the remote ip..

No packages like snort or squid performing traffic interception/inspection/blocking? or traffic shaping/limiting?

Take a look at /tmp/rules.debug are there any rules present for https / 443 that might interfere and are not there for http / 80 ?

The problem is that I did not do the installation for this box, so I do not know what the first admin did.
There are three boxes in three youth clubs, all with the same configuration. Two of them have not had
any problem since I have taken over administration, this one had a lot of problems all the time.

Now I have also lost connection to the box,so I can not check
the rules at the moment. I think i must go to the club and pick it up.

Maybe I should do a fresh install and start from the scratch. It is an Alix box, if I am right one has to install Nano-BSD.

I think I need a console cable for Nano-BSD installation, so I will order one and try a fresh install.

Anyway I will be away for some days; I will keep you updated about the further outcome when I am back.

Again, thanks a lot for your ongoing support!