First time for me as well. I want to believe it was induced by human, but there is no evidence of on the surface. Perhaps there is something in the logs which would indicate what happened, but I'm not sure for how long those rules went dark.
I'm deploying an instance of zabbix in the wifi zone to test inward readability, the DMZ's already have zabbix hosts so will configure those to do so as well. I failed to mention in OP, this issue was only related to the wifi zone. The DMZ/inside/outside policies were functioning as expected. -greg On Mon, Aug 21, 2017 at 12:45 PM, Moshe Katz <[email protected]> wrote: > I know that negative experience isn't so helpful to diagnose an issue, but > we have a very similar setup that's been in place for over 10 years, and > we've never seen such a thing. > > Moshe > > > > On Mon, Aug 21, 2017 at 12:09 PM, greg whynott <[email protected]> > wrote: > > > I'm not seeking help but rather thought I'd share an experience we had > last > > week which has caused quite a hit on the confidence levels of pfSense. > > > > I tried to find where it may of been human error but seen no evidence of > > such. Happy to upload logs to any member of the team should they care to > > investigate for their own reasons. > > > > > > > > We have pfsense with 5 zones connected to the internet via gigabit, all > > physical interfaces. From time to time we'll saturate the line for days > at > > a time, keeping pfsense busy (media co). > > > > Zones: > > Inside > > Outside > > WiFi > > DMZ1 > > DMZ2 > > > > > > > > The zone of concern is the WiFI zone. Its rule set is very simple. > > > > 1. Allow from wifi to inside webmail server on port 443/80. > > 2. Block all from wifi to inside any any. > > 3. Allow from wifi to internet any any. > > > > > > This was tested when the policy was put into place last winter and > > functioned as expected. Fast forward, 140 days up-time at this > point. > > > > > > Helpdesk staff informs me people on the wifi are able to mount internal > > CIFS shares and browse internal web resources. > > > > I look at it, verify this is the case using tcpdump on the wifi > > interface. > > > > look at the rules, disable and re-enable them, nothing changes. > > > > There is an update waiting to be applied. We apply the update and > reboot. > > (in hind sight, wish we didn't but were getting the "fix asap!!" message) > > > > when it comes up again, all is back to "normal". Policy is being > > respected. > > > > > > It seems as if at some point the policy stopped working, even a > flip/flop > > of the rule set didn't help. No one has made changes in that zone since > > the device was deployed. > > > > > > As you can imagine this is a cause of huge concern for us. I've been > using > > pfSense for about 11 years and this was quite the blow.. I hope it was > > something we did, but I can't think of how things could become so broken > > that disabling the rule then re enabling it did nothing to correct... > > > > > > Has anyone else experienced policy 'failing' after a period of time? > > > > take care, > > greg > > _______________________________________________ > > pfSense mailing list > > https://lists.pfsense.org/mailman/listinfo/list > > Support the project with Gold! https://pfsense.org/gold > > > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold > _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
