subject:"\[pfSense\] rules were ignored."

Re: [pfSense] rules were ignored.

2017-08-22 Thread greg whynott

Hi Ernst,

Many radios, 12ish or so,  but there are no vlans defined on the appliance,
 its all physical interfaces.

I'm going to chalk it up to some sort of human error, i don't want to
believe what appeared to happened,  happened.Will be setting up
services to watch for a similar situation occurrence though.


greg


On Tue, Aug 22, 2017 at 9:07 AM, Ernst den Broeder 
wrote:

> More than 1 wifi radio?  Are you sure they are connected to the same
> pfSense interface?  I've seen something like this before that was caused by
> a single mis-configured radio (wrong vlan).
>
> Sent from my iPhone
>
> > On Aug 21, 2017, at 6:02 PM, greg whynott 
> wrote:
> >
> >> On Mon, Aug 21, 2017 at 5:47 PM, PiBa  wrote:
> >>
> >> Nothing weird i could spot.. Besides that most wifi rules are kinda
> >> duplicated. (Some with 'S/SA' others without.)
> >>
> >
> >
> > You are seeing duplicate rules defined for UDP and TCP,UDP is
> > connection-less,  no SYN SYN-ACK bits to test for.  :)
> >
> >
> > You are correct,  many likely are redundant but since its a 'open to
> > internet' network (such as 80/udp),  I'm ok with it.
> >
> > thanks for taking the time to consider things PiBa,
> > 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

Re: [pfSense] rules were ignored.

2017-08-22 Thread Ernst den Broeder

More than 1 wifi radio?  Are you sure they are connected to the same pfSense 
interface?  I've seen something like this before that was caused by a single 
mis-configured radio (wrong vlan).

Sent from my iPhone

> On Aug 21, 2017, at 6:02 PM, greg whynott  wrote:
> 
>> On Mon, Aug 21, 2017 at 5:47 PM, PiBa  wrote:
>> 
>> Nothing weird i could spot.. Besides that most wifi rules are kinda
>> duplicated. (Some with 'S/SA' others without.)
>> 
> 
> 
> You are seeing duplicate rules defined for UDP and TCP,UDP is
> connection-less,  no SYN SYN-ACK bits to test for.  :)
> 
> 
> You are correct,  many likely are redundant but since its a 'open to
> internet' network (such as 80/udp),  I'm ok with it.
> 
> thanks for taking the time to consider things PiBa,
> 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

Re: [pfSense] rules were ignored.

2017-08-21 Thread greg whynott

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 <st...@teamits.com> 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:list-boun...@lists.pfsense.org] On Behalf Of PiBa
> Sent: Monday, August 21, 2017 12:47 PM
> To: pfSense Support and Discussion Mailing List <list@lists.pfsense.org>;
> greg whynott <greg.whyn...@gmail.com>
> 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 <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
> >>&g

Re: [pfSense] rules were ignored.

2017-08-21 Thread greg whynott

Hi PiBa,

- The rules are applied inbound from wifi zone on the pfs interface.
- inside is defined by an alias which describes all our internal RFC1918
networks.  Without the use of an exclusion operator.
- transparent http proxy is configured for the wifi network. As mentioned,
 while it was experiencing the issue,   it was passing all IP,  including
ICMP at the time to inside destinations,  I don't think squid is in the way
here.  No other application proxies are configured.

Below is a dump of the rules on the interface.  The Alias are correct and
describe our internal networks.


The policy was working originally and again post reboot.  I don't think its
a rule definition issue.   Beyond extra services being added to the 'guest
policy' alias group, there have been no changes in relation to the wifi
zone. I was logging to the splunk server but sadly I see my trial
license has expired,  I'll come back to that another time..



[2.3.4-RELEASE][root@tor-net-fw1]/root: pfctl -sr | grep igb2
scrub on igb2 all fragment reassemble
block drop in log on ! igb2 inet from 10.101.133.0/24 to any
block drop in log on igb2 inet6 from fe80::a236:9fff:fe05:56a8 to any
pass in quick on igb2 inet proto udp from any port = bootpc to
255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on igb2 inet proto udp from any port = bootpc to 10.101.133.1
port = bootps keep state label "allow access to DHCP server"
pass out quick on igb2 inet proto udp from 10.101.133.1 port = bootps to
any port = bootpc keep state label "allow access to DHCP server"
pass in quick on igb2 inet proto tcp from any to  port =
http flags S/SA keep state label "USER_RULE: HTTP on WebMail"
pass in quick on igb2 inet proto tcp from any to  port =
https flags S/SA keep state label "USER_RULE: HTTPS on WebMail"
block drop in quick on igb2 inet from any to  label
"USER_RULE: Block traffic to inside networks."
pass in quick on igb2 inet proto tcp from any to any port = pop3 flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = 8080 flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = imap flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = nntp flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = 3689 flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = ssh flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = http flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = https flags
S/SA keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = imaps flags
S/SA keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = smtps flags
S/SA keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = domain flags
S/SA keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = pop3s flags
S/SA keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = 9339 flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = isakmp flags
S/SA keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = ntp flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = sip flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = time flags S/SA
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto tcp from any to any port = sae-urn flags
S/SA keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = pop3 keep state
label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = 8080 keep state
label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = imap keep state
label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = nntp keep state
label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = 3689 keep state
label "USER_RULE: Default

Re: [pfSense] rules were ignored.

2017-08-21 Thread 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  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 
> 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] rules were ignored.

2017-08-21 Thread greg whynott

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

Re: [pfSense] rules were ignored.

Re: [pfSense] rules were ignored.

Re: [pfSense] rules were ignored.

Re: [pfSense] rules were ignored.

Re: [pfSense] rules were ignored.

[pfSense] rules were ignored.

6 matches

Site Navigation

Mail list logo

Footer information