• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 119
  • Last Modified:

sonicewall interface routing

We have a sonicwall NSA3500 (current firmware SonicOS Enhanced 5.9.0.2-107o)

The other day when we were transferring data from our wireless network to a file server I could not get over 10mbit. I noticed that it was bouncing the gateway! and have no idea why. 90% of the time the wireless devices are going out to the internet so no one noticed this issue.

x1 Lan1 10.10.10.x network gate 10.10.10.254
x3 Lan2 10.10.2.x network gate 10.10.2.254
Both of these interfaces go out through x0 to the internet.

IP of wireless laptop 10.10.2.168 goes out to the internet with zero issues. Can talk to anything on the 10.10.10.x network however they cant join a domain if they are on the 10.10.2.x network...seems to be bouncing the gateway to get back inside to the 10.10.10.x network Or its blocked some how.

Do I have to build a rule to prevent this? Firewalled subnet rule?
0
wlacroix
Asked:
wlacroix
  • 5
  • 3
1 Solution
 
Aaron TomoskySD-WAN SimplifiedCommented:
Are lan1 and lan2 in different zones? Also are you sure they aren't x0 and x2? Normally x0 is lan, X1 is wan.
0
 
wlacroixAuthor Commented:
They are both marked as LAN.
We also have 2 wans on this with different IPs from different providers.

x0 LAN 10.10.10.x
x1 WAN
x2 LAN 10.10.1.x (voice)
x3 LAN 10.10.2.x
x4 unassigned
x5 WAN
0
 
Aaron TomoskySD-WAN SimplifiedCommented:
if x0 and x3 are interfaces with the correct subnet masks, and they are in the same zone, then by default all communication between them should be routed. The nat rules to do this are created automatically when you create the zones, same with x1 (wan). When you add x5 (wan2) you would have to add rules to choose which traffic goes out x5 vs x1. Since the default setup of a single wan and multiple lan subnets in the same zone shouldn't have the problems you are showing, it's probably some custom nat rules causing the problem.
0
NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

 
wlacroixAuthor Commented:
Aaron, that makes total sense, I did a packet capture and test yesterday and it does NOT go out, but I have another tool that is reporting traffic on the interface and I have no idea why. I think the other tool has led me astray, because so far I cant verify it at all.
0
 
wlacroixAuthor Commented:
So I had a route on one of my other sonicwalls to move the 10.10.2.x traffic, so this was being dropped.

This rule was removed, and recreated on the other sonicwall.
After my test things seem alright now.
0
 
Aaron TomoskySD-WAN SimplifiedCommented:
So you had a route in another piece of gear you didn't tell me about and that was causing the problem? Alright, and maybe next time you ask a question you can give all the details. We would have resolved this much quicker if you had explained the whole situation.
0
 
wlacroixAuthor Commented:
The original sonicwall that had this stuff still had the left over route in it. I was not part of that change over.
The issue above was with the old device, which had 2 route rules in it that I was unaware of.

So here is what they did.

x3 was moved from an old gateway\sonicwall NSA3500 to a new NSA 3500 on x3, different internet providers. They were trying to minimize downtime.
they built the interface on the new device, deleted the interface on the old device then nothing worked. I was just working on the wireless side bouncing the gateway, unaware of the other ticket that was issued to move this interface to another provider.
Anyway.....
Once this interface was created on the NEW NSA 3500, and moved over nothing worked at all with regards to in\out.

the old NSA was .254, the new NSA was .253
On the .254 they had a route for 10.10.2.x that pointed to the old provider
10.10.10.x and 10.10.2.x could not talk at all, due to old route.

Once I removed the route on .254 it all started working. Then I moved back to my original ticket about the 10.10.2.x network bouncing the gateway.
We did a packet capture on .253 sonicwall
This showed me the 10.10.2.x traffic going to the x0 interface with no issues, and no traffic bouncing the gateway.

At the time this was posted I did not know about the other ticket to move the interface, my apologizes.
0
 
wlacroixAuthor Commented:
No solution given by an outside individual, this was handled internally.
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

The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now