Like my title says, why are session states synchronized between peers in most HA protocols? I assume TCP states like Esablished, Invalid, New and Related are synchronized, but I don't get why you want to have that synchronized between peers, since a firewall has nothing to do with a TCP flow between 2 peers?
... since a firewall has nothing to do with a TCP flow between 2 peers?
A stateful firewall has a state for each TCP connection and will only allow packets matching this state to be valid in the context of this TCP connection - and only valid packets will be passed through. "Valid" does not only mean that there is an established connection but also that the sequence numbers of the packets match the range of expected sequence numbers.
These expected sequence numbers are part of the state of the connection and they change whenever new packets for the connection get passed. Insofar these states have to be regularly synchronized between firewall peers inside a HA cluster.
Consider a network device with an “outside” interface which has both ingress and egress access lists applied.
If the device is a stateless router, ingress traffic is evaluated against the ingress acl and egress traffic is applied against the egress acl. This requires both ACLs to permit return traffic. Usually this includes “permit tcp any any established” plus specific UDP return traffic permits. Example: “permit udp any eq 53 any” in the ingress acl to permit DNS return traffic for interior resolvers.
If the device is a stateful firewall, egress-initiated traffic is evaluated against the egress ACL. The firewall remembers the connection in its state table, and return ingress traffic is automatically permitted, without requiring a permit in the ingress ACL.
This eliminates the need for the return “permit tcp any any established” and “permit udp any eq 53 any” rules which can be exploited.
One problem with a stateful firewall is that traffic has to flow through the same device in both directions for the return traffic to be permitted. If the firewall does not have a state entry for the tcp traffic, the established traffic will be denied.
This is a real problem in HA environments. A pair of stateful firewalls have to be engineered so that all traffic goes through one of them under normal circumstances. Usually this is done with a layer-2 vlan inside and outside the active/passive firewall cluster. The firewalls sync their state so after a failover, preexisting tcp sockets are still connected and the return traffic still permitted. That’s not that important for HTTP traffic, but critical for many other long running connections (such as database connections).
Some firewall vendors try to implement a layer-3 active-active firewall cluster with continuous syncing, eliminating the need for layer-2 vlans. How reliably this works (particularly during software upgrades) varies by vendor.
Large enterprises with multiple firewalled ISP points and an internal backbone have another issue: traffic from a particular “site” has to egress and ingress the company through the same firewall for the return ingress traffic to be permitted.