Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a sonicwall tz series FW with two internet service providers connected.

One of the providers has a wireless service which works a bit like an ethernet switch in that we have an ip with a /24 subnet and the gateway is .1. All other clients on the same subnet (say 195.222.99.0) have the same .1 gateway - this is important, read on.

Some of our clients are also on the same subnet.

Our config:

  • X0 : Lan
  • X1 : 89.90.91.92
  • X2 : 195.222.99.252/24 (GW 195.222.99.1)

X1 and X2 are not connected, other than both being connected to the public Internet.

Client config:

  • X1 : 195.222.99.123/24 (GW 195.222.99.1)

What fails, what works:

  • Traffic 195.222.99.123 (client) <-> 89.90.91.92 (X1) : Spoof alert
  • Traffic 195.222.99.123 (client) <-> 195.222.99.252 (X1) : OK - no spoof alert

I have several clients with IPs in the 195.222.99.0 range and all provoke identical alerts.

This is the alert I see on the FW:

Alert   Intrusion Prevention    IP spoof dropped 195.222.99.252, 21475, X1  89.90.91.92, 80, X1 MAC address: 00:12:ef:41:75:88

Anti-spoofing is switched off on my FW (network->mac-ip-anti-spoofing -> config for each interface) for all ports

I can provoke the alerts by telneting to a port on X1 from the clients.

You can't argue with the logic - this is suspicious traffic. X1 is receiving traffic with a source IP which corresponds to X2s subnet.

Anyone know how can I tell the FW that packets with a src subnet of 195.222.99.0 can legitimately appear on X1?

I know whats going wrong, I've seen the same thing before, but with higher end FWs you can avoid this with a few extra rules. I can't see how to do this here. And before you ask why we're using this service provider - they give us 3ms (yep 3ms, thats not an error) delay between routers.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

After logging into the sonicwall, go to the diagnostic interface by adding "diag.html" to the URL (If you access your router at https://192.168.5.1, go to https://192.168.5.1/diag.html)

You'll get a warning that you can break things, continue on by clicking "Internal Settings" on the lefthand menu. About a third of the way down, you'll see a check box to disable IP spoof detection.

screenshot

Uncheck the box and see if that makes a difference.

share|improve this answer
    
Aha, now thats something I didn't know existed. I've it a try later on today when its quiet and let you know if its worked. –  Ian Murphy Nov 14 '12 at 9:46
    
It seems to have stopped the spoof detection messages, so thats sort of better, though its not what I was hoping existed, which was a way to tell the box that the subnet on X2 could also send packets to X1. Still at least its not generating all those alerts. Now I have the problem that the rules I was setting up still don't work and my inbound traffic is still not getting through - but thats a whole new problem. –  Ian Murphy Nov 14 '12 at 16:55
    
Here's one more crazy suggestion that I haven't tested, so it may not work - Does the sonicwall complain if you change the subnet mask on the X2 interface to 255.255.255.254 but keep the gateway as X.X.X.1? If it lets you, that would probably stop the spoof messages and allow the other IPs to access the X1 services. –  Jim G. Nov 14 '12 at 17:31
    
No, it doesn't work. I did try various things like this when I first came across the problem but none of them worked. I manage a few Stonegate Firewalls which is what our clients use in many cases. They have an 'anti-spoofing' configuration where you can simply tell it that this subnet is reachable on interface X1 and so it stops generating alerts for it. Stonegates really nice and are in a whole different league. I suspect we are going to end up swapping over in the future. –  Ian Murphy Nov 16 '12 at 16:28
add comment

Do you have both connections (X1 and X2) connected to the same broadcast domain (for example, are they both plugged into the same switch? That can cause spoof messages). Keep each connection in its own broadcast domain.

If that's not the case, how is traffic for X2 reaching the X1 interface?

share|improve this answer
    
No they are not interconnected. If you read the posting again you'll notice that the problem is rather subtle. The first time I hit it at a clients it took me quite a while to cotton on to what was occuring. I'll edit the posting to make this clearer. –  Ian Murphy Nov 13 '12 at 9:02
    
Thanks for the clarification. I'm posting a separate answer. –  Jim G. Nov 13 '12 at 16:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.