Firewall has gone erratic, respecting the rule one second, stopping the next
-
@cool1two said in Firewall has gone erratic, respecting the rule one second, stopping the next:
Random comments and suggestions welcome
You rules allowing dns to XYZ "net" don't make a lot of sense. You should use XYZ "address" here.. For example the iot network... Pfsense has no control over A talking to B in the iot net.. So saying your allowing to iot net doesn't make sense, what you can allow is dns to pfsense iot address..
edit: Also not really understanding the point of the multicast and and broadcast traffic rules on your floating.. Other than not logging it.. What for example is pfsense going to do with LLMNR multicast traffic? Or the SSDP stuff? Other than not wanting that logged in the default block rule - Not sure what your expecting those rules to do?
-
@dicmo said in Firewall has gone erratic, respecting the rule one second, stopping the next:
Ok, it seems that fixed the issue of the Gateway going down all the time. I guess now I should go to the VPN section and find out why I have 20%+ packet loss, because I am guessing that is not normal. I am hoping it is a problem with the monitoring and not with the VPN itself.
I had a similar situation with a VPN provider. I got in touch with them and they suggested using the WAN IP address of their server as the monitor IP. That didn't work. They suggested using the IP address of their DNS servers. That didn't work either. Nonetheless running a continuous ping test through their VPN servers out to the internet to various servers all showed acceptable latency and packet loss. It was clearly an issue in ping responses times to their servers which was causing the issue, but it had nothing to do with the quality of their vpn services.
My "fix" was to create 2 other simultaneous connections to servers offered by my VPN provider. (Just duplicate the interfaces, gateways, NAT, firewall, etc. of the existing VPN but point them to different servers.). I disabled the gateway monitoring on each of the gateways and then bound the 3 interfaces as an interface group. You can then use the interface group for policy routing in your firewall rules. Since then, I've never seen a gateway marked as down, and if one of the VPN servers was to go down then traffic would still be able to get routed out the other 2 servers. I've never been in a position to where I've not been able to route traffic through the VPN provider.
-
@johnpoz
Rules 1 and 2 in the VLAN in effect say, if you are using the VLAN gateway as your DNS provider then you can pass, otherwise you will be blocked.This prevents IOT systems with pre-programmed DNS servers, such as Google Mini, from using an unauthorized DNS server.
As far as the IGMP floating rules. All of the switches participate in IGMP Snooping Query election for the network. Additionally, all of the switches are doing LLDP discovery. The Netgate PFsense router was blocking this traffic for all VLANs and for any device on those VLANs. This caused several issues, including all of the switches believing they had been elected as the IGMP Snooping Querier. With these rules in place all of the switches, including the UNIFI now agree on who is doing what.
.25 switch
.26 switch
.27 switch
-
@johnpoz
I did take your advice and switch the VLAN rules to IOT and NGT address instead of Net. Thank you for the suggestion. -
I am quite sure I understand what the rules say and do ;)
IGMP doesn't pass the router.. So those are pointless - other than having them prevents them from being logged.
None of those floating rules make any sense at all - broadcast and multicast is not going to pass the router.. And pfsense sure isn't needing to actually see that traffic..
The Netgate PFsense router was blocking this traffic for all VLANs and for any device on those VLANs.
No it wasn't - can promise you that.. Pfsense is a L3 router, it doesn't care or do anything with traffic on the L2 its attached to - it couldn't even if it wanted to.
You seeing it block it to its interfaces, has zero to do with other devices on that L2 from seeing that traffic.
-
I did take two actions based on your response. The first was to disable all of the floating rules. The second was to update the IGMP poller "IPs" in my switches to "IPs" in the subnet range for those VLAN. According the Netgear's documentation, these are not actually "IPs". They are simply used for the election process, and indeed I cannot ping them and they have no ARP entry. However, this did resolve the issue for the IPV4 floating rules. I still get warnings for the related IPV6 rules, but I do not use IPV6 so I do not worry.
Thank you for your feedback. It was very valuable.
