"Inside" is an interface per his description. Greg, did you reboot before upgrading? It doesn't really help now but I wonder if rebooting would have fixed it. Agreed it seems weird.
-- Steve Yates ITS, Inc. -----Original Message----- From: List [mailto:[email protected]] On Behalf Of PiBa Sent: Monday, August 21, 2017 12:47 PM To: pfSense Support and Discussion Mailing List <[email protected]>; greg whynott <[email protected]> Subject: Re: [pfSense] rules were ignored. Hi, As you probably know pfSense rules don't apply to 'zones' as some firewalls do.. So I'm wondering what is the actual rules set for the configuration of these 3 items on wifi? 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. Okay first one is easy, its a simple pass rule with a specific destination. The second one, is a bit more interesting, how is 'inside' defined? And then the third could be most prone to mistake, how did you define 'to internet' ? Like 'destination NOT 192.168/16' or something similar? Also are any proxy's or other gateway/advanced configurations used? Though only reason i think something might 'disapear' or change kinda spontaneous is if the rules have a gateway defined that went down. Can you describe the rules in detail? Regards PiBa-NL Op 21-8-2017 om 19:20 schreef greg whynott: > 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
