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 <mo...@ymkatz.net> 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 <greg.whyn...@gmail.com>
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


_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Reply via email to