-
Products
-
SonicPlatform
SonicPlatform is the cybersecurity platform purpose-built for MSPs, making managing complex security environments among multiple tenants easy and streamlined.
Discover More
-
-
Solutions
-
Federal
Protect Federal Agencies and Networks with scalable, purpose-built cybersecurity solutions
Learn MoreFederalProtect Federal Agencies and Networks with scalable, purpose-built cybersecurity solutions
Learn More - Industries
- Use Cases
-
-
Partners
-
Partner Portal
Access to deal registration, MDF, sales and marketing tools, training and more
Learn MorePartner PortalAccess to deal registration, MDF, sales and marketing tools, training and more
Learn More - SonicWall Partners
- Partner Resources
-
-
Support
-
Support Portal
Find answers to your questions by searching across our knowledge base, community, technical documentation and video tutorials
Learn MoreSupport PortalFind answers to your questions by searching across our knowledge base, community, technical documentation and video tutorials
Learn More - Support
- Resources
- Capture Labs
-
- Company
- Contact Us
IPSpoof dropped messages in the SonicWall Log (With Video and KB Article)
03/26/2020 
162 People found this article helpful
487,165 Views
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:
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.
Related Articles
- Cysurance Partner FAQ
- How can I enable Enhanced Audit Logging Support?
- How to stop the creation of Auto-Added Access Rules and enable the ability to edit or delete the existing rules?
Categories
- Firewalls > TZ Series
- Firewalls > SonicWall SuperMassive E10000 Series
- Firewalls > SonicWall SuperMassive 9000 Series
- Firewalls > SonicWall NSA Series
YES
NO