can't update pfsense or install packages
-
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.
-
The update was a success, but now pfSense is crashing on boot.
The same thing happened when I made the clean install of 2.7 and restored the backup (it was normal before backup).
I am making a clean 2.7 install again and config it from zero. -
Where does it crash? Do you have a kernel panic log?
-
@stephenw10 I have, but everything is working normal after I did the install from scratch. If you want me to send you the file, I can look at it. But that problem is solved now.
-
@mrrobot . I managed to solve the problem, but what exactly is going on? I can't say.
Change DNS Resolution Behavior to "Use remote DNS Servers" and put 9.9.9.9 as your first DNS server.
