Unable to update repository …
-
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? -
Tried?: pkg-static install -f pkg
-
@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?
-
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..
-
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.
-
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.
-
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..
-
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
-
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 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!