IPSpoof dropped messages in the SonicWall Log (With Video and KB Article)

03/26/2020 104 23599

DESCRIPTION:

IP spoof log messages are caused when the SonicWall sees an IP address on one segment that it believes belongs on another segment. For instance, an IP spoof  will be logged if the SonicWall sees an IP address on the LAN that it believes belongs on the WAN.

IP Spoof messages are generally indicative of malicious attempts to access a network, but they can also result from bad network or VPN routes. The log message shows the packet was detected and dropped. 

RESOLUTION:

Video Tutorial:  Click here for the video tutorial of this topic

The following are some of the factors responsible for IP Spoof messages:

• Misconfigured node on the LAN.
• Physical Connectivity
• Additional LAN Subnet behind the SonicWall
• Mutliple Network Interface Cards (NICs)
• Packets from additional NIC with APIPA address ( 169.254.x.x)
• Virtual (e.g. VMware) interfaces / adapters

Misconfigured node on the LAN.

The most common cause of IP spoofs is a misconfigured node on the LAN. All LAN nodes must have an IP address that is in the same subnet as the SonicWall's LAN IP address. If a SonicWall interface is in the 192.168.168.0/24 subnet, a node with an IP of, say, 192.168.0.1 is present, the SonicWall will drop the traffic from the node as IP Spoof. The screenshot below is an example:

Physical Connectivity

Another common cause would be a loop in the physical configuration of the Sonicwall and the devices connected to it. For instance, if a switch behind the SonicWall is connected both to the X0 (LAN) and another interface (X2,X3) of the SonicWall, it can cause IP Spoof messages if the switch does not have VLANs configured or not configured properly.

Additional LAN Subnet

Another cause of IP spoof messages is the existence of additional subnets on the LAN. In a standard setup, the SonicWall will only recognize the subnet of its LAN IP address as being valid. If there are additional subnets connected to the LAN, in the SonicWall you must create a route policy for those networks.

For eg. if the SonicWall X0 (LAN) is configured in the 192.168.168.0/24 subnet and a host or hosts with IP address in 192.168.200.0/24 subnet tries to go online, the SonicWall will drop the packet as IP Spoof. The screenshot above is example of such an IP Spoof. 

If the network is behind a router please refer KB ID 3559: How to Configure Static Routes in SonicOS (Standard and Enhanced)

To configure additional subnets behind the SonicWall without a router please refer KB ID 7711: Configuring secondary subnets with static ARP which allows multiple subnets to be connected to a single physical interface

Mutliple Network Interface Cards (NICs)

A host with multiple NICs configured with IP addresses on different subnets. One NIC (NIC A) is connected to the X0 and the other (NIC B) to a router. At times traffic meant to go out through NIC B may try to go out through the SonicWall. When this happens it will be dropped by SonicWall.

This could also happen over a VPN tunnel when a GVC user is connected to the SonicWall and has a Wireless LAN (WLAN) adapter which tries to pass, more often than not, UDP port 137,138, 139 which are Microsoft NetBIOS broadcast traffic. The workaround to this would be to temporarily disable the WLAN adapter.

Packets from additional NIC with APIPA address ( 169.254.x.x)

Hosts with multiple NICs could also pose problems when one of the NICs has an automatic private IP address (APIPA). These NICs could try to pass traffic through the SonicWall with the MAC address of the adapter connected to the SonicWall.

Workaround is to disable these adapters or ensure that a valid IP address is configured on them.

Virtual (e.g. VMware) interfaces / adapters

Nodes with Virtual Machines connected to virtual adapters with an IP address not in the same subnet as the host physical adapter may also cause IP Spoof when the virtual adapters try to access the internet through the SonicWall. Workaround is to disable the virtual adapters or create a route policy on the SonicWall for those networks.