Firewall has gone erratic, respecting the rule one second, stopping the next
-
@teamits said in Firewall has gone erratic, respecting the rule one second, stopping the next:
@dicmo said in Firewall has gone erratic, respecting the rule one second, stopping the next:
Is it possible that the firewall rule using the VPN_WAN_GW gets ignored because the gateway is not available
That was a complaint in IPv6 No Gateway after 2.5 upgrade and the Redmine report but that's specifically related to IPv6.
Well, I can tell you it is happening in 2.5 with IPv4, that is for sure.
-
@dicmo said in Firewall has gone erratic, respecting the rule one second, stopping the next:
How do I go about debugging what might be happening with this gateway? The logs of OpenVPN, the vpn client I am using, show nothing like that, only show the initial connection and nothing more, and the VPN status says it has been connected without issues. I would appreciate any advice on how to look for the issue.
You can test this by disabling the Gateway Monitor in System/Routing/Gateways for the VPN Gateway. If the IP address that the monitor is using does not respond to the monitoring service then the gateway will be marked as down even if the connection is stable.
-
@dma_pf said in Firewall has gone erratic, respecting the rule one second, stopping the next:
@dicmo said in Firewall has gone erratic, respecting the rule one second, stopping the next:
How do I go about debugging what might be happening with this gateway? The logs of OpenVPN, the vpn client I am using, show nothing like that, only show the initial connection and nothing more, and the VPN status says it has been connected without issues. I would appreciate any advice on how to look for the issue.
You can test this by disabling the Gateway Monitor in System/Routing/Gateways for the VPN Gateway. If the IP address that the monitor is using does not respond to the monitoring service then the gateway will be marked as down even if the connection is stable.
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.
Again, thanks everybody for helping someone who is starting. I never though this would turned to be so involved.
-
@dma_pf
Here to help the cause. Below is a network diagram and screenshots of my rules. There is nothing here that is exotic. Random comments and suggestions welcome :)Network:
FW Floating:
FW WAN:
FW LAN:
FW IOT:
FW NGT - Test Network:
FW NAT:
-
@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.
