can't update pfsense or install packages
-
You see that on the rule that's marked '12001'?
You would expect to see traffic blocked inbound by the default rule but not what shows in the log there.
It could be something upstream sending back the permission denied response. You have active filtering on the gateway device?
-
@stephenw10 said in can't update pfsense or install packages:
You see that on the rule that's marked '12001'?
i see it on rule 1000000103
-
@stephenw10 said in can't update pfsense or install packages:
You have active filtering on the gateway device?
how can i check that ?
-
Ok, so seeing traffic blocked by the default rule on WAN, like that IGMP traffic in your screenshot, is expected and not an issue. Unrelated to whatever is blocking outgoing requests here.
What is the gateway device here?
Try looking for states to 208.123.73.X when you try to run the update. In Diag > States filter by 208.123.73
You should see states there unless something is blocking it on the firewall itself.
-
@stephenw10 running pfsense on protectli vault fw4b
-
Those are only states from LAN side clients to our subnet on https. So probably you connecting to the forum.
Were you running pkg update when you checked that? I expect to see a state for that on WAN only without NAT.
Try running a port test to it:
-
@stephenw10 said in can't update pfsense or install packages:
ere you running pkg update when you checked that?
yes
-
@stephenw10 said in can't update pfsense or install packages:
Try running a port test to it:
both pkg00-atx.netgate.com & pkg01-atx.netgate.com show failed
-
Do you see states created when running that test?
-
@stephenw10 you mean from Diag -> states ?
i got this when i filter 208.123.73 on WAN interface
-
So still no states. Something is preventing it open states locally.
Do you have captive portal running?
-
@stephenw10 sorry for the late respond ! no captive portal is not active
-
To confirm you are looking at the states correctly try running a port test against something else and then looking for those states.
For example 1.1.1.1:
-
-
From a shell prompt or Diag > Command (preferably a shell prompt), try running the following commands:
$ host pkg00-atx.netgate.com $ route -n get pkg00-atx.netgate.com $ route -n -4 get pkg00-atx.netgate.com $ route -n -6 get pkg00-atx.netgate.com $ nc -vz pkg00-atx.netgate.com 443 $ nc -vz4 pkg00-atx.netgate.com 443 $ nc -vz6 pkg00-atx.netgate.com 443On a working system with IPv4 and IPv6 connectivity, I'd expect to see the following output:
$ host pkg00-atx.netgate.com pkg00-atx.netgate.com has address 208.123.73.207 pkg00-atx.netgate.com has IPv6 address 2610:160:11:18::207 $ route -n get pkg00-atx.netgate.com route to: 208.123.73.207 destination: 0.0.0.0 mask: 0.0.0.0 gateway: x.x.x.1 fib: 0 interface: ix3 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 $ route -n -4 get pkg00-atx.netgate.com route to: 208.123.73.207 destination: 0.0.0.0 mask: 0.0.0.0 gateway: x.x.x.1 fib: 0 interface: ix3 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 $ route -n -6 get pkg00-atx.netgate.com route to: 2610:160:11:18::207 destination: :: mask: :: gateway: 2xxx:xxxx:xxxx:xxxx::1 fib: 0 interface: gif0 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1480 1 0 $ nc -vz pkg00-atx.netgate.com 443 Connection to pkg00-atx.netgate.com 443 port [tcp/https] succeeded! $ nc -vz4 pkg00-atx.netgate.com 443 Connection to pkg00-atx.netgate.com 443 port [tcp/https] succeeded! $ nc -vz6 pkg00-atx.netgate.com 443 Connection to pkg00-atx.netgate.com 443 port [tcp/https] succeeded! -
@jimp the first 3 cmds respond the same way as working system
the rest is below
$route -n -6 get pkg00-atx.netgate.com route: route has not been found $nc -vz pkg00-atx.netgate.com 443 nc: connect to pkg00-atx.netgate.com port 443 (tcp) failed: Permission denied nc: connect to pkg00-atx.netgate.com port 443 (tcp) failed: No route to host $nc -vz4 pkg00-atx.netgate.com 443 nc: connect to pkg00-atx.netgate.com port 443 (tcp) failed: Permission denied $nc -vz6 pkg00-atx.netgate.com 443 nc: connect to pkg00-atx.netgate.com port 443 (tcp) failed: No route to host -
And you are certain there are no rules on the Floating tab?
If you run the command
pfSsh.php playback pftabledrillfrom a shell prompt, do you see anything listed in thesshguardorvirusprottables? -
-
There has to be something in your rules blocking the outgoing connection then, but without a floating rule I'm not sure what it might be coming from. A package, possibly.
Can you post the whole
/tmp/rules.debugfile as a text attachment (e.g. rename it to rules.txt). You can edit out any sensitive IP addresses but please keep the last octet intact and differentiated. For example, you can change 192.168.1.1 to x.x.x.1 and 203.0.113.5 to y.y.y.5 so it's clear they're different subnets. -
Yes, it has to be something blocking it locally. The firewall itself cannot create outbound states.
Do you have outbound NAT set to automatic? If not perhaps you have an overmatching rule doing something odd. That wasn't the same error you saw when it was trying IPv6...
