Hi Steve, Unfortunately no. The physical machine this runs on is a server class (re-purposed HPC node) hardware which takes _forever_ to reboot, at least 4-5 minutes and that is not an exaggeration. Not the best choice based on that fact but it was available and full of resources, didn't make sense to buy a new piece of hardware at the time (who else has a 24 core 64gig firewall with SAS drives?).
Loosely based on that, I decided to backup the config and perform an upgrade before rebooting and hope that rectified things. My bad, I was feeling the pressure. best, greg On Mon, Aug 21, 2017 at 2:17 PM, Steve Yates <[email protected]> wrote: > "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 > _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
