After failover, secondary firewall started to deny connection for which a rule exists
-
Hello,
We did a failover from Primary firewall to the secondary firewall and after firewall, for one specific connection, the traffic was going to deny rule though an allow rule exists above that and on Primary firewall it is working fine but not on secondary. We had to add a specific rule to allow the dropped connection and then it was allowed.
We are using Netgate 8300, version 24.03
Is it a bug on this OS?
Thank you
-
What was the rule in question? What was the traffic getting denied?
There wasn't any bug I was aware of in 24.03 but that is a very old version at this point. You should upgrade those anyway.
It sounds more like a rule that applied to the Primary only for some reason. Like something not using the CARP VIP for example.
-
@stephenw10 The rule in question allows traffic to a specific hosts (an object group created for those hosts) from any source on smtp port.
The rule in question is being used but the not from one specific source though we can see the traffic going from this same rule from the source in same subnet to that specific destination on smtp port.
Example:
the rule says : any to 10.10.10.10/11/12/13 on smtp port
the traffic is allowed from 172.20.10.4 to 10.10.10.10 on smtp port via this rule
but traffic for 172.20.10.5 to 10.10.10.10 on smtp port is going to deny rule
When we added the specific rule for 172.20.10.5 to 10.10.10.10 on smtp, it worked.This connection was working before failover via the any to 10.10.10.10/11/12/13 on smtp port rule.
-
What block rule is the traffic hitting? The default deny rule?
There is no NAT happening here? It's all local subnets?
-
Yeah seeing the full rule list and order would be helpful, floating rules? etc.
What would make sense is you had a rule above your smtp allow any source that blocked this specific client, and then you added a rule above the block rule you where hitting.
Without seeing your rule list, it's all guess work - my guess pebkac.
Maybe an out of state condition maybe, what was the specific block you were seeing? Also why would you still be running such an old version? Maybe during the failover a state did not get synced because of the failure? Maybe the other clients just started a new session with a new state, and this guy failed to do that?
-
Yeah hard to see why that would be different on the Primary but it is possible to set rules not to sync between nodes.
-
@johnpoz @stephenw10 we have multiple other rules on this firewall and all other connections are worked fine except this one connection and the deny rule was and is below both the rules. There is no nat, just local subnets.
-
Does the alias exist on both nodes?
-
@stephenw10 Yes, it does. The configuration between both the nodes is in sync.
The strange part is that the connection still works via this rule "any to 10.10.10.10/11/12/13 on smtp port to host 10.10.10.11" but not to 10.10.10.10 from the same source 172.20.10.5 -
Is it actually populated? Check the rule actully exists on the secondary as expected by running:
pfctl -vsrThat will create a lot of output but you should see the same set of expanded rules on both nodes. I suspect something will be missing on the secondary since it isn't matching.
