can't update pfsense or install packages

[mrrobot]

@stephenw10 said in can't update pfsense or install packages:

You also have a pass all IPv4 rule on WAN which is almost always a bad idea. I assume you added that just as a test.

yes i will chage it later once my issue is solved, i hope :)

[stephenw10]

Ok, check the ruleset file /tmp/rules.debug

What is rule 12001 there?

That traffic should not be coming into WAN.

[mrrobot]

@stephenw10 i see no 12001 role in /tmp/rules.debug

[2.6.0-RELEASE][admin@pfSense.xxx.local]/root: grep '12001' /tmp/rules.debug
[2.6.0-RELEASE][admin@pfSense.xxx.local]/root:

[mrrobot]

@mrrobot i see a icmpv6 section thought, can't see icmp v4

.# Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep)
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} ridentifier 1000000108 keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} ridentifier 1000000109 keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000110 keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000111 keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000112 keep state
pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000113 keep state
.# We use the mighty pf, we cannot be fooled.
block log quick inet proto { tcp, udp } from any port = 0 to any ridentifier 1000000114 label "Block traffic from port 0"
block log quick inet proto { tcp, udp } from any to any port = 0 ridentifier 1000000115 label "Block traffic to port 0"
block log quick inet6 proto { tcp, udp } from any port = 0 to any ridentifier 1000000116 label "Block traffic from port 0"
block log quick inet6 proto { tcp, udp } from any to any port = 0 ridentifier 1000000117 label "Block traffic to port 0"

[stephenw10]

Ok try this. Click on the red X in the firewall log. What rule does it show has blocked that?

[mrrobot]

@stephenw10 [2.6.0-RELEASE][admin@pfSense.xxx.local]/root: grep '1000000103' /tmp/rules.debug
block in log inet all ridentifier 1000000103 label "Default deny rule IPv4"
[2.6.0-RELEASE][admin@pfSense.xxx.local]/root:

[stephenw10]

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?

[mrrobot]

@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

[mrrobot]

@stephenw10 said in can't update pfsense or install packages:

You have active filtering on the gateway device?

how can i check that ?

[stephenw10]

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.

[mrrobot]

@stephenw10 running pfsense on protectli vault fw4b

[stephenw10]

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:

[mrrobot]

@stephenw10 said in can't update pfsense or install packages:

ere you running pkg update when you checked that?

yes

[mrrobot]

@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

[stephenw10]

Do you see states created when running that test?

[mrrobot]

@stephenw10 you mean from Diag -> states ?

i got this when i filter 208.123.73 on WAN interface

[stephenw10]

So still no states. Something is preventing it open states locally.

Do you have captive portal running?

[mrrobot]

@stephenw10 sorry for the late respond ! no captive portal is not active

[stephenw10]

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:

[mrrobot]

@stephenw10 here are the results