Kernel debug ('fw ctl debug -m fw + drop') on Standby cluster member shows: ;fw_log_drop_conn: Packet ..., dropped by do_inbound, Reason: Address spoofing;
SecureXL SIM debug ('sim dbg -m pkt + pkt drop spoof ; sim dbg -m db + get') on Standby cluster member shows:
Matching range wasn't found, IP address is invalid for <Interface_Name>
packet dropped (spoofed address)
Example:
; Date Time;[kern];[tid_2];[SIM-...]do_inbound: got packet 0x... on cpu 2 of <192.168.14.251,64308,172.16.3.45,80,6>(vsid=4);
; Date Time;[kern];[tid_2];[SIM-...]sim_db_get_conn: conn <192.168.14.251,64308,172.16.3.45,80,6> not found for vsid 4 (inbound=yes, ifn=43).;
; Date Time;[kern];[tid_2];[SIM-...]sim_validate_address: ifn: 43, conn: <192.168.14.251,64308,172.16.3.45,80,6>, ttl: 126;
; Date Time;[kern];[tid_2];[SIM-...]sim_validate_address: Matching range wasn't found, IP address is invalid for bond1.315;
; Date Time;[kern];[tid_2];[SIM-...]do_inbound: packet dropped (spoofed address);
; Date Time;[kern];[tid_2];[SIM-...]sim_pkt_send_drop_notification: recieved drop, reason: 19;
; Date Time;[kern];[tid_2];[fw4_0];fw_log_drop_conn: Packet <dir 1, 192.168.14.251:64308 -> 172.16.3.45:80 IPP 6>, dropped by do_inbound, Reason: Address spoofing;
Disabling SecureXL on the involved Virtual System(s) resolves the issue.
Shutting down all cluster members except one member resolves the issue.
Enabling the FireWall kernel parameter fwha_vmac_disable_promisc_on_standby from sk100405 does not resolve the issue.
Cause
When VMAC mode (sk50840) is enabled, all cluster interfaces are going into promiscuous mode, which causes the SecureXL to process the packets.
Example Topology (from the case reported to Check Point):
[Client] --- [switch] --- [Check Point Cluster in HA mode] --- [switches for NLB] --- [Microsoft NLB]
Client sends traffic to Virtual IP address of Microsoft Network Load Balancer
Microsoft Network Load Balancer is configured in Multicast Mode
Microsoft Network Load Balancer returns Multicast MAC address in ARP Reply for its Virtual IP address
Multicast MAC address returned by Microsoft NLB is not bound to any specific port on the NLB switches (IGMP is disabled) - therefore, traffic sent to that Multicast MAC address would be forwarded by NLB switches on all their ports
Client sends traffic to Virtual IP address of Microsoft Network Load Balancer
Traffic from Client is forwarded by switches to all members of Check Point Cluster
Active cluster member inspects the traffic
Active cluster member sends ARP Request for Virtual IP address of Microsoft NLB
Microsoft NLB sends ARP Reply with its Multicast MAC address
Active cluster member sends the traffic to Virtual IP address / Multicast MAC address of Microsoft NLB:
Layer 2 - multicast MAC address of NLB (03:BF:XX:XX:XX:XX)
Layer 3 - unicast Virtual IP address of NLB (XX.XX.XX.XX)
Since Multicast MAC address of Microsoft NLB is not bound to any specific port on the NLB switches, this traffic is forwarded by NLB switches on all their ports
As a result, the same traffic that was sent by Active member now reaches the Standby member
Standby cluster member drops this traffic with "Address spoofing" log
