can't update pfsense or install packages
-
@NETLOGIC said in can't update pfsense or install packages:
Bad Request
That Bad Request error means that then client didn't send a currently valid certificate. So either it can't pull a new cert or simply hasn't tried.
Try runningpfSense-repocfirst. -
@stephenw10 After issuing the following command at the command line:
pfsense-repoc
I saw this:
pfSense-repoc: failed to fetch the repo data
failed to read the repo data. -
Try:
pfSense-upgrade -dcWhat errors are shown?
-
@stephenw10
Command : /root: pfSense-upgrade -dcpfSense-repoc-static: failed to fetch the repo data
failed to read the repo data.
failed to update the repository settings!!!
failed to update the repository settings!!!However when I go to the main status page it shows that it can see and check for current firmware.
23.05.1-RELEASE (amd64)
built on Wed Jun 28 03:57:27 UTC 2023
FreeBSD 14.0-CURRENTThe system is on the latest version.
Version information updated at Wed Aug 9 12:25:29 MDT 2023 -
Ok send me your NDI in chat and I'll check it.
-
E eduardomozart referenced this topic on
-
D Darkk referenced this topic on
-
Well, I don't know what I did, but it worked for about 10 minutes again and that is it, not working anymore.
I noticed that my ISP now supports ipv6, I started to configure ipv6 here, but ipv6 is so weird, I think I will not be able to configure in my setup.
Then I updated the Mikrotik's firmware and packages, which is my router that provides a WAN connection.Weird, as I was writing this comment something changed, it is working again. Trying to update pfSense.
-
Update failed, the problem is back.
-
'Permission Denied' like that really looks like something blocking access and sending that back via icmp. If you're not running pfblocker or Snort it pretty much has to be something upstream.
-
@stephenw10 If on my computer within that network I can access the website and download the files, then does it mean that the connection is blocked within the pfSense environment? Is this logic correct? Or maybe because a different port is being used?
For example, I have no problems downloading files from https://pkg00-atx.netgate.com/. -
Unlikely, it's just https. In that case I expect to see it blocked on the firewall itself. Usually that's Snort/Suricata but it could be anything blocking outbound traffic. pfBlocker adds rules that could do it. If you have user rules blocking outbound that could also do it.
-
This image is from a video.
This is mine.
Shouldn't my DNS servers show up here as well? I think there is something wrong with my setup.
-
I dont have any DNS servers on my WAN interface either. But i have no issues.
-
They only show there if the WAN is being passed DNS servers by the upstream connection method. So PPPoE or DHCP usually.
-
I did a clean install of version 2.7 (I was using 2.6), before configuring something it was already blocked.
-
Hmm, so on a clean install you were still seeing those errors? That really does look like an upstream issue then.
-
@stephenw10 Yes, I'm now seeing how packet capture works.
17:01:11.934116 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.057763 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 0
17:01:12.057779 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.063808 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 517
17:01:12.185245 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 1428
17:01:12.185262 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.185365 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 1428
17:01:12.185369 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.185463 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 1240
17:01:12.185466 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.186727 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 1035
17:01:12.186735 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.187326 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 80
17:01:12.187400 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 491
17:01:12.303401 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 271
17:01:12.303417 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.303420 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 271
17:01:12.303421 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.306885 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 238
17:01:12.306896 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.306990 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 24
17:01:12.307386 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.321463 IP 179.16.0.4.59588 > 208.123.73.80.53: UDP, length 56
17:01:12.321528 IP 179.16.0.4.41858 > 208.123.73.80.53: UDP, length 44
17:01:12.423343 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 24
17:01:12.423356 IP 179.16.0.4.65535 > 208.123.73.212.443: tcp 0
17:01:12.423359 IP 208.123.73.212.443 > 179.16.0.4.65535: tcp 0
17:01:12.437823 IP 208.123.73.80.53 > 179.16.0.4.59588: UDP, length 138
17:01:12.437847 IP 208.123.73.80.53 > 179.16.0.4.41858: UDP, length 60
17:01:12.437923 IP 179.16.0.4.60631 > 208.123.73.80.53: UDP, length 56
17:01:12.437970 IP 179.16.0.4.64708 > 208.123.73.80.53: UDP, length 44
17:01:12.554299 IP 208.123.73.80.53 > 179.16.0.4.64708: UDP, length 60
17:01:12.554371 IP 208.123.73.80.53 > 179.16.0.4.60631: UDP, length 138 -
If you set the view level higher or download that and open it in Wireshark does it show the TCP terminations or permission denied errors?
I don't see any icmp traffic there.
-
@stephenw10 Most of the time it ends with TCP RST.
I executed pkg-static -d4 update and that was the result.
-
That looks OK. What was the result of running the command?
-
Look how funny. I changed the DNS Resolution Behavior to "Use remote DNS Servers, ignore local DNS" and I put a totally different DNS server that I never used, 9.9.9.9. Everything is working normally. Let's see if it will be a permanent solution or the problem will come back in a while. I had never been able to reach this update stage, so it's already a step forward.
