can't update pfsense or install packages
-
Aha! Well that is almost always something blocking it.
Are you running Snort or Suricata? pfBlocker maybe? Check it's not blocking that traffic.
-
@stephenw10 i had to google all this tools to know about em, i don't have any of these
the router had only the os installed, i have been unable to install nothing else -
[2.6.0-RELEASE][admin@pfSense.xxxx.local]/root: pkg info | grep 'snort|suricata|pfb'
[2.6.0-RELEASE][admin@pfSense.xxxx.local]/root: -
Something is blocking it. Do you see anything in the firewall logs?
-
@stephenw10 i see the same log repeating over & over
-
Is your WAN using a private IP?
If not what is that rule? Is that something you added?
Do you see the TCP traffic from pkg blocked there also?
-
@stephenw10 said in can't update pfsense or install packages:
is your WAN using a private IP?
yes, its 10.x.x.x
-
@stephenw10 said in can't update pfsense or install packages:
Do you see the TCP traffic from pkg blocked there also?
where ?
-
In the firewall log.
However if you have added block rules on WAN or floating they may not be set to log. Have you added rules there?
-
-
Those ping blocks are frequent. Were you running pkg update at the time to generate some tcp traffic.
Also they are shown blocked from the WAN IP to the gateway but not shown as outbound....
Do you have any rules on the floating tab?
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.
-
@stephenw10 said in can't update pfsense or install packages:
Those ping blocks are frequent. Were you running pkg update at the time to generate some tcp traffic.
yes i did run pkg update
-
@stephenw10 said in can't update pfsense or install packages:
Do you have any rules on the floating tab?
no, its empty
-
@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 :)
-
Ok, check the ruleset file /tmp/rules.debug
What is rule 12001 there?
That traffic should not be coming into WAN.
-
@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 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" -
Ok try this. Click on the red X in the firewall log. What rule does it show has blocked that?
-
@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: -
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?
