Link to home
Start Free TrialLog in
Avatar of Tyler Brooks
Tyler BrooksFlag for Canada

asked on

Sonicwall TZ 205- Dropping Incoming E-mail as IP Spoof

My clients TZ 105 appears to be triggering a false positive when one of their customers attempts to send them email and drops the the packet. When this happens we get the following message in the logs:

 12/06/2016        Priority    Category                          Message                   Source                                   Destination
17:24:19.928       Alert      Intrusion Prevention   IP spoof dropped xx.xx.204.36, 11413, X3 xx.xx.209.253, 25, X3  MAC address:   fe:05:ca:3e:83:3e

I suspect that this is due to the fact that the other WAN interface on the sonicwall is configured with a WAN IP on the same subnet as the source IP listed above (for some reason their ISP gives out their wan ips with a /24 subnet mask).

What I need to know is if there is a rule that I can configure that will either exclude that IP from the spoof detection, or if I can create a rule to allow it to bypass it?
Avatar of masnrock
masnrock
Flag of United States of America image

It's not tied to being in the same subnet if you're showing the correct numbers for the final 2 octects from the addresses. However, it is probably declaring the source IP too similar.

Disabling would be a horrible idea for obvious reason, but here's an EE article that will show you how to create an exclusion for the address in question: https://www.experts-exchange.com/questions/28563728/Dell-Sonicwall-IP-Spoof-Detection.html
ASKER CERTIFIED SOLUTION
Avatar of J Spoor
J Spoor
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Tyler Brooks

ASKER

When I disabled spoof detection on the diag page it looked like the alerts that were generated for the spoof detection went away but the email was still not being delivered.
I'd recommend to try creating an exclusion, and then we can reevaluate from there. I did see some articles where people who turned that off still had issues.
This sonicwall has only the most basic licensing, so no license for the IPS module which means I can't create an exclusion as above.
You could try to create a policy based route
source = any
destination = the IP that is the "offending" one
service = any
gateway = primary WAN gateway
interface = primary WAN
metric = 5
disable route when interface disconnected enabled

this then tells the Sonic that that specific IP is on the primary WAN instead of the secondary WAN.
Unfortunately that also did not work (I assume by the offending IP you meant the source IP I had listed above)
can you send a screenshot of the routing table and the route details you added ?
I ended up implementing an ugly fix for the problem, they have a third public IP on a different /24 subnet that is also on a different subnet that the clients mail server. I wound up switching two of the addresses around so that there would be no conflict on the Sonicwall. This is unfortunately gambling on the fact that due to the small rural nature of their ISP the likelihood of encountering another mail server on that subnet is relatively low.

I am going to leave the question open for a day or two in case this fix does not prove to viable.

Thank you very much for your help.
Funny enough I was going to ask if you could get that IP changed to one in another subnet. Now that you mentioned it is a rural company, switching providers isn't an option.

Unfortunately for the way SonicWalls work, there isn't much you can do unless you were to up the licensing. But given that the newer generation of units is out, it might even turn out more worthwhile to replace the firewall. Not sure SonicWall is doing the upgrade program for TZ105 units yet.
That is my plan with this client, if this fix doesn't work I think I will have to break it to him that he either will need to switch ISP's (he does have a few better options but he is attached to this one for personal reasons) or he will need to invest in a newer firewall. Though in all likelihood we'd be putting in a Watchguard rather than installing another SonicWall.
Why swap to watchguard?

I can tell you a number of reasons why not to :) SonicWalls are superior over watchguard, I even had one of their techs admit it.
I do however suggest if you are looking to renew, is to secure upgrade (get a large discount) to a Generation 6 SonicWALL, e.g. the TZ300.