Source NAT Hides Client Addresses From a Later Firewall

A rule authored for staff and lab clients goes onto the new edge firewall, and it silently matches everything or nothing. The reason sits upstream: a gateway already rewrote the client addresses, so the rule sees one transit address instead of two groups. Adding an appliance does not restore information the path removed. Find the last point where the distinction still exists before writing the policy.

Why the edge rule sees one address

Many-to-one translation maps each internal address and port tuple to a shared external address with an assigned port. Conversations stay distinguishable to the translator through those port bindings, yet a downstream device performing a simple source-prefix match sees only the shared address. That is enough to make two groups identical at the rule. The packets still arrive; the grouping does not.

Check what the firewall's interface actually observes rather than what the diagram promises. The two differ more often than anyone expects.

Find the last enforceable identity

Start at the enforcement point and walk backwards until the original prefix appears. Two commands usually locate the boundary.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

The NAT table shows which traffic is translated and by which rule, while the conntrack listing shows original and translated tuples for live flows. Where the upstream firewall only ever sees the translated address, per-group source rules cannot work there no matter how they are written. Walk forward or backward along the path until you reach a device on which the two client prefixes remain distinct. Record the source at each hop instead of trusting an inside or outside label.

Three placements and what each costs

The policy can live on the translating gateway, where the original sources are still visible. It can live on the upstream firewall if the transit becomes routed rather than translated, which means adding return routes and removing the source rewrite. Or it can be enforced on identity rather than addresses, through an authenticated control that knows the user or device. Each choice has an owner and a failure mode, and only the first two keep the rule purely about source addresses.

Whichever you pick, document the rule together with the address it matches. A rule whose address assumption changed silently is worse than no rule at all, because it keeps matching traffic while protecting something else entirely.

Acceptance: one allowed and one denied client

Test with a pair of clients, one from each group, and capture how each arrives at the enforcement point. Retain both tuples next to the rule result, so the evidence shows the distinction survived rather than that another firewall exists. Repeat the test after a NAT or routing change, because the presented address is the part that breaks quietly. Keep authentication in place wherever people must be distinguished, since a source address is a policy input rather than proof of identity.

Write the enforcement point, the observed source and the rule into the ticket. Otherwise the next engineer adds a second firewall and the same rule.