topic Management-HA: Address spoofing error for FW_Log when gateway sends logs cross-site in Firewall and Security Management

Management-HA: Address spoofing error for FW_Log when gateway sends logs cross-site

Danny — Mon, 11 May 2026 22:30:29 GMT

Environment

R82 Management High Availability (Management-HA)
Two geographically separated offices: Office A and Office B

Topology

Issue description

Log forwarding works correctly when traffic stays local:

GW-A → Mgmt-A: OK
GW-B → Mgmt-B: OK

However, as soon as a gateway sends logs to the management server in the other site, an address spoofing error for FW_Log is triggered:

GW-A → Mgmt-B: Spoofing error
GW-B → Mgmt-A: Spoofing error

The root cause appears to be that each gateway uses the same source IP regardless of which log server it targets. When the log packet traverses the inter-site link and arrives at the remote gateway, the source IP belongs to the wrong network segment, causing the receiving gateway to flag it as spoofed.

What I have tried / investigated

$FWDIR/conf/masters — this file controls which log servers a gateway forwards to (the destination), but it does not provide a way to specify which source IP the gateway should use when initiating the log connection.
We would prefer to avoid NAT if at all possible.

Question

Is there a supported method in R82 to control the source IP a gateway uses when sending logs to a specific log server?

For example, GW-A has multiple interfaces. When it sends logs to Mgmt-B across the WAN, is there a way to tell it to use a specific interface IP as the source — similar to how you can pin a source interface for other connections?

Any pointers to sk articles, CLI parameters, or configuration files would be greatly appreciated.

Re: Management-HA: Address spoofing error for FW_Log when gateway sends logs cross-site

Duane_Toler — Mon, 11 May 2026 23:38:14 GMT

This looks like an asymmetric routing issue on the network path between A and B. You can also update the incoming interface on each gateway to "not check packets from" ... and select a group object containing the gateway in question.

When FWD fires up and initiates the connection to the log server, it binds to the interface closest to said gateway. It will use this interface until FWD is restarted. This will explain why the source is always "that" IP on the gateway. There's also a logging_worker process in (at least R82.10) that I believe handles the log forwarding when gateways become disconnected.

If you can afford it, and you can induce a log server failover, SSH into the problematic gateway and restart FWD manually to see if the source IP changes on a new process. That'll give you the answer. Then do the "don't check packets from" config.

Re: Management-HA: Address spoofing error for FW_Log when gateway sends logs cross-site

Danny — Tue, 12 May 2026 06:40:22 GMT

"Don't check packets from" only applies to external interfaces.
Check Point fixed it by itself automagically by switching to another source IP:

Re: Management-HA: Address spoofing error for FW_Log when gateway sends logs cross-site

Lesley — Tue, 12 May 2026 07:09:28 GMT

This is MDS but they refer only to a NAT solution:

https://support.checkpoint.com/results/sk/sk181701

But if you are going to do NAT you will get new issues like:

https://support.checkpoint.com/results/sk/sk163415

https://support.checkpoint.com/results/sk/sk171665

If issues occurs again, after a restart I would still look into above NAT solution / SK's.

Re: Management-HA: Address spoofing error for FW_Log when gateway sends logs cross-site

Duane_Toler — Tue, 12 May 2026 13:07:53 GMT

Excellent.. so FWD worked itself out after a time. Certainly not "the best" situation, but good that it does adjust. If this is R82 and lower, you might want to look into the log-forwarding configuration to have the gateway send over its disconnected logs to the management on an interval. R82.10 has this enabled by default now (yay!).

Re: Management-HA: Address spoofing error for FW_Log when gateway sends logs cross-site

the_rock — Tue, 12 May 2026 13:19:34 GMT

Thats true, only applies to external interface though.