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 <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]> 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]> 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 >>> >>> _______________________________________________ >> 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
