We help IT Professionals succeed at work.

Sonicwall IP Spoof in log when accessing internal resource from WAN

Medium Priority
1,832 Views
Last Modified: 2012-05-12
I have a Sonicwall NSA 2400 with the following interfaces:
X0: LAN (10.9.0.0/16)
X1: WAN (11.22.33.154/29)
X2: WAN (44.55.66.245/30)

Our X1 WAN zone has a number of NAT policies that translate inbound traffic to private IPs in the X0 LAN zone.  We have an IP webcam at 10.9.50.200, and I want to be able to access port 80 on that webcam from the Internet.  I currently have NAT policies that translate 11.22.33.155:80 to 10.9.50.200:80.  However, when I try to hit 11.22.33.155:80 from a computer outside our network, the connection times out and I see the following log on the Sonicwall:

11/02/2011 13:47:44.688      Alert      Intrusion Prevention      IP spoof dropped      72.66.229.30, 2849, X1, pool-72-66-229-30.ronkva.east.verizon.net      11.22.33.155, 80, X1, 11-22-33-155.unassigned.myisp.net      MAC address: 00:18:b9:0e:4a:65

I will also mention that I have several other similar NAT policies in place that are working fine.  Just this one isn't working.  Thanks for any help!
Comment
Watch Question

Most Valuable Expert 2011

Commented:
Not really enough information to determine anything.

Using fake IP#s does not help.

Author

Commented:
What difference do fake IPs make?  I'd rather not broadcast my static WAN IPs on an open forum.

What additional information do you need?  I would be glad to expound or post screen shots... what kind of information is needed?
Most Valuable Expert 2011

Commented:
Your choice on the IPs, but what is needed is a clear understanding of the topology,...the routing scheme,..and the Firewall's config.  My personal view is that this won't get solved here,...you need to call Sonicwall Support instead of us,...but I'm willing to at least take a look and at minimum give an opinion.

The reason knowing the IPs helps solve the problem is because the alerts of this nature happen generally in one of a couple ways,...either the devices interface see a packet from an IP# that is not logically supposed be reachable from that interface. Another way is if it see packets on the wire that did not begin with a SYN packet,..for example it may see an ACK packet but never have seen the SYN Packet that the ACK was acknowledging.  Another way is the flip side of that is when it see a bunch of SYN Packets but never sees any corresponding ACKs.   Asynchronous Routing is the cause of much of that (Routing should be Synchronous).  So,...knowing the network more intimately helps to sort out all of that,...and Fake IPs make that nearly impossible,....in fact Fake IP#s are the same as just giving no IPs at all.

Again your choice on the real IPs,...but here is my viewpoint on it....
Your Static WAN IPs are already public knowledge anyone can look them up if they know the company name or at least one of the IP# from the range.   So publicly revealing something that is already public anyway is not a risk,...that's why they call them Public IPs.  security doesn't come from hiding them,...security comes from what you do with them and what you allow over them.   Revealing the LAN IPs aren't a big deal either, since we are all using RFC Private Ranges we are then basically all using the same thing on our LANs and everyone knows what the RFC Private Ranges are,...and they aren't reachable or routable from the Internet so again,...not a real risk.

Commented:
I figured it out.  It had to do with firewall routing.  We had changed the primary Internet route to go through X2 instead of X1, but the WAN IP for the camera was in the X1 subnet.  There wasn't a proper route for the traffic to/from the camera.

Author

Commented:
Self-resolved