Support Center > Search Results > SecureKnowledge Details
SecureXL on Standby cluster member drops traffic with "Address spoofing" log
Symptoms

  • SmartView Tracker log shows "Address spoofing" logs from Standby cluster member.

  • 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
  • Network Load Balancing Technical Overview
  • Catalyst Switches for Microsoft Network Load Balancing Configuration Example

Chain of events:

  1. Client sends traffic to Virtual IP address of Microsoft Network Load Balancer
  2. Traffic from Client is forwarded by switches to all members of Check Point Cluster
  3. Active cluster member inspects the traffic
  4. Active cluster member sends ARP Request for Virtual IP address of Microsoft NLB
  5. Microsoft NLB sends ARP Reply with its Multicast MAC address
  6. 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)
  7. 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
  8. As a result, the same traffic that was sent by Active member now reaches the Standby member
  9. Standby cluster member drops this traffic with "Address spoofing" log

Solution
 Note: To view this solution you need to Sign In .