Firewall rules reload blocks all traffic
-
I've recently installed version 2.2 on a new LinITX appliance. This new firewall sometimes seems to block all traffic after a rule add/change which initiates a filter reload. This issue is very similar to Bug #1493 - https://redmine.pfsense.org/issues/1493 but I'm not using Hyper-V. I have two identical appliances, but only one seems to cause this issue at the moment.
If I open an ssh session prior to changing the rules, I can run the /etc/rc.reload_all and the system return to normal operating conditions.
Anyone having similar issues with 2.2 ?
Running pfctl -f /tmp/rules.debug during this issue gives me the following file, which is missing the re0 and re1 interfaces plus a load of rules :-
–----------------------------------------------------------------------------------------------------------------------------------------------------------
more /tmp/rules.debug
set optimization normal
set timeout { adaptive.start 0, adaptive.end 0 }
set limit states 98000
set limit src-nodes 98000#System aliases
loopback = "{ lo0 }"
#SSH Lockout Table
table <sshlockout>persist
table <webconfiguratorlockout>persist
#Snort tables
table <snort2c>table <virusprot>table <bogons>persist file "/etc/bogons"
table <negate_networks># User AliasesGateways
set skip on pfsync0
no nat proto carp
no rdr proto carp
nat-anchor "natearly/"
nat-anchor "natrules/"Outbound NAT rules (automatic)
Subnets to NAT
tonatsubnets = "{ 127.0.0.0/8 }"
Load balancing anchor
rdr-anchor "relayd/*"
TFTP proxy
rdr-anchor "tftp-proxy/*"
UPnPd rdr anchor
rdr-anchor "miniupnpd"
anchor "relayd/"
anchor "openvpn/"
anchor "ipsec/*"Allow IPv6 on loopback
pass in quick on $loopback inet6 all tracker 1000000001 label "pass IPv6 loopback"
pass out quick on $loopback inet6 all tracker 1000000002 label "pass IPv6 loopback"Block all IPv6
block in log quick inet6 all tracker 1000000003 label "Block all IPv6"
block out log quick inet6 all tracker 1000000004 label "Block all IPv6"block IPv4 link-local. Per RFC 3927, link local "MUST NOT" be forwarded by a routing device,
and clients "MUST NOT" send such packets to a router. FreeBSD won't route 169.254./16, but
route-to can override that, causing problems such as in redmine #2073
block in log quick from 169.254.0.0/16 to any tracker 1000000101 label "Block IPv4 link-local"
block in log quick from any to 169.254.0.0/16 tracker 1000000102 label "Block IPv4 link-local"
#---------------------------------------------------------------------------default deny rules
#---------------------------------------------------------------------------
block in log inet all tracker 1000000103 label "Default deny rule IPv4"
block out log inet all tracker 1000000104 label "Default deny rule IPv4"
block in log inet6 all tracker 1000000105 label "Default deny rule IPv6"
block out log inet6 all tracker 1000000106 label "Default deny rule IPv6"IPv6 ICMP is not auxilary, it is required for operation
See man icmp6(4)
1 unreach Destination unreachable
2 toobig Packet too big
128 echoreq Echo service request
129 echorep Echo service reply
133 routersol Router solicitation
134 routeradv Router advertisement
135 neighbrsol Neighbor solicitation
136 neighbradv Neighbor advertisement
pass quick inet6 proto ipv6-icmp from any to any icmp6-type {1,2,135,136} tracker 1000000107 keep state
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} tracker 1000000108 keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} tracker 1000000109 keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} tracker 1000000110 keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} tracker 1000000111 keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} tracker 1000000112 keep stateWe use the mighty pf, we cannot be fooled.
block log quick inet proto { tcp, udp } from any port = 0 to any tracker 1000000113
block log quick inet proto { tcp, udp } from any to any port = 0 tracker 1000000114
block log quick inet6 proto { tcp, udp } from any port = 0 to any tracker 1000000115
block log quick inet6 proto { tcp, udp } from any to any port = 0 tracker 1000000116Snort package
block log quick from <snort2c>to any tracker 1000000117 label "Block snort2c hosts"
block log quick from any to <snort2c>tracker 1000000118 label "Block snort2c hosts"SSH lockout
block in log quick proto tcp from <sshlockout>to (self) port 22 tracker 1000000301 label "sshlockout"
webConfigurator lockout
block in log quick proto tcp from <webconfiguratorlockout>to (self) port 443 tracker 1000000351 label "webConfiguratorlockout"
block in log quick from <virusprot>to any tracker 1000000400 label "virusprot overload table"loopback
pass in on $loopback inet all tracker 1000000561 label "pass IPv4 loopback"
pass out on $loopback inet all tracker 1000000562 label "pass IPv4 loopback"
pass in on $loopback inet6 all tracker 1000000563 label "pass IPv6 loopback"
pass out on $loopback inet6 all tracker 1000000564 label "pass IPv6 loopback"let out anything from the firewall host itself and decrypted IPsec traffic
pass out inet all keep state allow-opts tracker 1000000565 label "let out anything IPv4 from firewall host itself"
pass out inet6 all keep state allow-opts tracker 1000000566 label "let out anything IPv6 from firewall host itself"VPN Rules
anchor "tftp-proxy/*"
Thanks
Roger</virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c></negate_networks></bogons></virusprot></snort2c></webconfiguratorlockout></sshlockout>
-
I will just observe that the rules.debug rule-set has been built as if there is no WAN or LAN at all. It just has the base stuff without any evidence of actual interfaces or their subnets existing. e.g.
# Subnets to NAT tonatsubnets = "{ 127.0.0.0/8 }"
That should have found some LAN subnet that it thinks it should do NAT for.
It sounds like this happens every time you do a rule change - is that so?
What type of install (full/nano)?
What interfaces are defined?
What are their subnets?
What other stuff is set up?
What is in the system log?
-
Though I don't know that we've seen it on anything other than Hyper-V, it's possible bug #4445 applies to things other than Hyper-V (the root cause there is some oddity with the block driver, triggered by unnecessary deletion of the config cache and it not getting rebuilt quickly enough). I'd try 2.2.1 before anything else, either the latest available snapshot, or release will go out later today.