Hi Greg,
Nothing weird i could spot.. Besides that most wifi rules are kinda
duplicated. (Some with 'S/SA' others without.)
It doesn't explain why it 'should?' under some circumstance change the
rules. If that's what happened in the first place.. I guess we will not
know for sure anytime soon. :/
Regards,
PiBa-NL
Op 21-8-2017 om 21:40 schreef 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
<http://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 <WebMail_Inside> port
= http flags S/SA keep state label "USER_RULE: HTTP on WebMail"
pass in quick on igb2 inet proto tcp from any to <WebMail_Inside> port
= https flags S/SA keep state label "USER_RULE: HTTPS on WebMail"
block drop in quick on igb2 inet from any to <INSIDE_Netblock> 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 Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = http keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = https keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = imaps keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = smtps keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = domain
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = pop3s keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = 9339 keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = isakmp
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = ntp keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = sip keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = time keep
state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto udp from any to any port = sae-urn
keep state label "USER_RULE: Default Guest Policy For WIFI"
pass in quick on igb2 inet proto icmp all keep state label "USER_RULE:
ICMP Out"
pass in quick on igb2 proto tcp from any to (igb2) port = 3128 flags
S/SA keep state
pass in quick on igb2 proto tcp from any to (igb2) port = 3129 flags
S/SA keep state
[2.3.4-RELEASE][root@tor-net-fw1.]/root:
thanks,
greg
On Mon, Aug 21, 2017 at 1:46 PM, PiBa <[email protected]
<mailto:[email protected]>> wrote:
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]
<mailto:[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] <mailto:[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
<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
<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
<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
