• Status: Solved
  • Priority: High
  • Security: Public
  • Views: 98
  • Last Modified:

SonicWALL IP Spoof on WAN from Similar Subnet

Brief: SonicWALL IP Spoof on WAN from Similar Subnet.

While this article seems like the resolution doing what it detailed did not resolve the issue:
https://www.experts-exchange.com/questions/2856328/Dell-Sonicwall-IP-Spoof-Detec tion.html

I have a Unifi Controller behind a SonicWALL.
We have multiple sites we control from it.

If the site is on a static IP from the same ISP (only 2 ISPs in town) and has the same first 3 octets the traffic passes fine.
Example:
Server site WAN IP: 50.50.50.15
Client site WAN IP: 50.50.50.230

However if a site is on a different octet then they cannot communicate due to "IP Spoofing" detection.
Example
Servers site WAN IP: 50.50.50.15
Client site WAN IP: 50.50.45.59

I've talked with SonicWALL and their engineers are working to find a resolution but I don't know if they can come up with anything.

The server site ISP WAN IP is a /30 net mask.
0
rodneygray
Asked:
rodneygray
  • 6
  • 4
1 Solution
 
Blue Street TechLast KnightCommented:
Hi Rodney,

The most common cause for IP spoofing is a network loop or an improperly configured node downstream from the SonicWALL. IP Spoof drops are caused when the SonicWALL sees an IP address on one network segment that (per firewall config) believes the traffic belongs to a different network segment. ARP table discrepancy and the MAC Address of the packet arriving, among other causes.

The MAC address in the logs for the IP Spoofing events should give you a lead as to what kind of device is throwing the error so you can trace it and start investigating there.

It sounds like a possible ARP issue but please address the questions below.

So the Server Site is in another location outside of your SonicWALL site?
And where is the Client Site in relation to the SonicWALL?
Can you provide a simple diagram?
0
 
An Average Forum Participant Just For FunHardware Tester and DebuggerCommented:
Hi! :)

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

You may refer to the link below for further explanation:
https://www.sonicwall.com/en-us/support/knowledge-base/170505528391975
0
 
rodneygrayAuthor Commented:
So the Server Site is in another location outside of your SonicWALL site?
No we host the Server. It is on the primary LAN subnet.
And where is the Client Site in relation to the SonicWALL?
WAN side we have multiple Client Sites some with SonicWALLs and some without. Either way they have issues unless that are on the same 50.50.50.x network. (The 50. is just a place holder for illistration)
Can you provide a simple diagram?
I'll work on this shortly.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
rodneygrayAuthor Commented:
WAN IP Spoofing Diagram
0
 
rodneygrayAuthor Commented:
Update:

Our IP: XX.XX.179.18
XX.XX.184.50 can communicate with our IP
XX.XX.179.232 can communicate with our IP
XX.XX.179.146 can communicate with our IP
XX.XX.183.118 cannot communicate with our IP
and 1-2 others also can not communicate that are on the same ISP but not same segment.

Also on the diagram above the SiteC IP is 50.50.53.243 not the one listed.
0
 
Blue Street TechLast KnightCommented:
What are site B & C's mask bits.../28, /29, etc.? Do they overlap with your 50.50.50.201/30?

If you have configured port forwarding on your SonicWALL or VPN with any of these sites make sure your Address Objects for the networks are configured correctly and are not overlapping.

Is there a common router or switch that is being shared by all these sites?

Make sure the Unify Management server doesn't have any other those Public IPs configured and/or are overlapping.

Downstream from your SonicWALL if there is anything else with these configurations you are going to want to remove them to resolve the conflicts.
0
 
rodneygrayAuthor Commented:
What are site B & C's mask bits.../28, /29, etc.? Do they overlap with your 50.50.50.201/30?
The remote sites have /30 net masks also. (Confimed Site A + C are /30, I do not have access to router at site B)

Is there a common router or switch that is being shared by all these sites?
All 3 sites have mixed, different hardware.

Site C we were able to get working about 2 weeks ago by having the ISP change their static IP to the same XX.XX.XX.00 subnet range as us.
But there are not enough free IPs to give all our clients an IP in that block and that would be problem-some for clients who already use external access.

Downstream from your SonicWALL if there is anything else with these configurations you are going to want to remove them to resolve the conflicts.
There really isn't anything downstream that I can remove, we have a switch then the server.

The SonicWALL is were my issue stems but it really doesn't make sense. I can't even ping remotely from Sites
0
 
rodneygrayAuthor Commented:
If our ISP has our WAN IP's SNM as 255.255.252.0 would that cause this issue? I believe that is what they had it set to to begin with and I changed it to 255.255.255.252
0
 
Blue Street TechLast KnightCommented:
Site C we were able to get working about 2 weeks ago by having the ISP change their static IP to the same XX.XX.XX.00 subnet range as us.
But there are not enough free IPs to give all our clients an IP in that block and that would be problem-some for clients who already use external access.
Is should not be a prerequisite for networking. What you are essentially trying to do is creating a large private WAN incorrectly. Each network should be able to communicate with each other in disparate ranges if configured correctly. You should not be overlapping with any other public network. How are you trying to communicate with these sites VPN or Port Forwarding?

There really isn't anything downstream that I can remove, we have a switch then the server.
I'm not saying to remove anything but there is a misconfiguration somewhere and typically it is downstream from the reporting device (SonicWALL). In the SonicWALL logs where you found the IP Spoof drops what is the MAC address noted there?

The SonicWALL is were my issue stems but it really doesn't make sense. I can't even ping remotely from Sites
Your SonicWALL is not the problem it is just telling you there is one! Not being able to ping is not necessarily an issue either if the receiving devices are not configured to allow ping. If they are configured to accept ping then that's a different story.

If our ISP has our WAN IP's SNM as 255.255.252.0 would that cause this issue? I believe that is what they had it set to to begin with and I changed it to 255.255.255.252.
That is an enormous range and should not be configured as such unless this is a cable-type WAN connection. That specifies a 50.50.48.0/22 network giving you a range of 50.50.48.0-50.50.51.255 (1022 hosts). If your ISP has provided you with 1 static IP then a /30 (255.255.255.252) would be appropriate, however if they have given you 5 static IPs then a /29 (255.255.255.248) is appropriate.

This is a big misconfiguration and should be changed but it would only cause an issue to IPs lower than 50.50.50.200. If Site B & C where in the lower range like 50.50.50.154 or 50.50.48.3 then this would work but is not the solution. Site A works because it is in that range but it shouldn't be the case either. I'd make this change on the WAN (X1) Interface.
0
 
rodneygrayAuthor Commented:
Thanks for pointing me in the right direction.
There was more information I should have included but it had been so long ago I set it up that I forgot.

X3 is interface we were using but we also assigned an X1 interface. The X1 interface had a 255.255.252.0 subnet defined and it was within the range of the networks we were having issues with. Changing both adapters to 255.255.255.252 subnet resolved the issue and it is working now.


Thanks!
0
 
Blue Street TechLast KnightCommented:
I'm glad I could help & you got it sorted out...thanks for the points!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

On-Demand: Securing Your Wi-Fi for Summer Travel

Traveling this summer?Check out our on-demand webinar to learn about the importance of Wi-Fi security and 3 easy measures you can start taking immediately to protect your private data while using public Wi-Fi. Follow us today to learn more!

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now