This post is not an exact duplicate of How to configure remote access to multiple subnets behind a SonicWALL NSA 2400 . However, I am having this problem, almost verbatim. Unfortunately, we even have paid SonicWALL support and even they're being thrown through loops.

Where we differ is that I'm simply trying to use Layer 2 Bridge Mode. No NAT, no routing. Our desire is to have the SonicWALL do nothing more than listen on the wire, block all traffic except select UDP and TCP ports, and provide stateful inspection for all other undesired traffic such as denial of service attacks, anti-virus, anti-spyware, etc. The X1 interface is configured on subnet A. The rest of the usable IPs in the subnet are assigned to servers connected to the switch on the X2 (DMZ) port.

Up until recently, this configuration has worked great. However now we are faced with a problem. We used our entire subnet A and required more, so we were assigned another /28 subnet. The servers running in this subnet are plugged into the same switch on port X2 and VLANs are not being used, so we have two networks living inside the same broadcast domain. This seemed fine, because all the SonicWALL should be doing is packet inspection and shouldn’t care about the routing aspect of the traffic running through it. We would have the network’s router (that we are not in control of) on port X1 worry about routing between the two subnets that are actually in the same broadcast domain.

From the internet, this configuration works fine. We are able to access both the subnet A and subnet B networks. There becomes a problem when we want the two networks to communicate with each other. We expected the two networks to use the router on the other side of the SonicWALL in order to communicate with each other, but I have proven that packets do not get past the SonicWALL. There are no firewall logs indicating that it is dropping the communication due to rules. Instead, when I perform a packet capture on the SonicWALL, I am able to see that the packets come in on port X2, and are not forwarded. The status simply says “Received” (Which oddly, cannot be found as a valid status in ANY documentation (Documentation says 'DROPPED' is for traffic dropping due to a firewall rule)).

Support sent me the exact document that is referenced in the above post, but it doesn't apply to this situation. After talking to the more-than-difficult support for days, I was finally suggested to do nothing more than add a static route:

Source: Any, Dest: subnet B, gateway:, interface X2.

The current routing table only has the default items that it adds on its own. So even if you don't know anything about SonicWALL specifically, tell me if adding the above static route makes sense to anyone. The current table is:

Source: Any, Dest: Subnet A gateway, gateway:, interface X1. Source: Any, Dest: Subnet A, gateway:, interface X1. Source: Any, Dest: Any, gateway: Subnet A gateway, interface X1.

It seems odd to me that none of the values are already X2. I feel as though the fact that subnet A gateway is the only reason traffic makes it out of subnet A, but then it doesn't make sense for how it comes back, since that should leave interface X2 and the above table has X1 listed. It's also interesting that subnet B is able to communicate with the internet, which I feel is due to the last rule. Subnet A and B's gateway have the same MAC address: so it must only be a coincidence that it works. Still doesn't make sense how traffic makes it to either subnet initially from the Internet.

  • Got the exact same issue, have contacted SonicWall support, but going by past experience with their support don't hold up much hope. Thanks though for posting as had spent 6 hours working on this and now I have found this know this to be a bug in Sonicwall and not a configuration issue. – Borg Jan 19 '12 at 14:21
  • Your use of ports and zones is a bit confusing to me. Can you give me more details about the router that's in front of the firewall? – SpacemanSpiff Apr 12 '12 at 0:34
  • Nope. I have no control over it. It's effectively "the Internet". – Sam Rueby Apr 12 '12 at 2:18

It turns out that no one was capable of solving my problem. I spoke with SonicWALL support for two months, and received nothing but shot-in-the-dark "solutions". They made it very clear they didn't understand the devices they supported and gave me unacceptable solutions. They didn't care what I thought about their unacceptable solutions because all they did is suggest them again. There's no emulation software for these products (at least Cisco has packet tracer) and they're pretty expensive, so there was no way to test their ridiculous solutions besides the small time frame I had every so often on the live server during a scheduled down-time. They didn't respect this either, and would call me on Monday and ask for access to the SonicWALL. They seemed baffled when I said absolutely not.

Worst support for enterprise products I've ever had, especially because it wasn't free to get treated this poorly. We abandoned the case, and I have a very-high suspicion what I have found is a bug in their software. It would have been so much better if they just admitted to that instead of jerking me around for two months.

Solution: We dumped the two subnets for one, large one that could support the greater amount of hosts.

  • I had a somewhat similar scenario that resulted in the exact same support response. It was a horrible mess that resulted in us having to change to a less preferred set up. Their support is frustrating at best. Half the time you can't understand what they're saying. I'm a fan of our NSA 3500's, I think they're relatively easy to use and set up, and overall it's a great product. But even the thought of dealing with their support gives me a headache. I've been down that same path and I know your pain. – Safado Sep 23 '11 at 16:09

old post but worth a good comment regarding "received" status in the packet monitor. I couldn't find anything on this status in Sonicwall/Dell documentation. Finally got a tech to explain it, actually got a short description...

Received means that the packet was consumed by the interface. This means the packet did not make it internally on the network. The other use for received is in a VPN scenario where the packet is received and decrypted.


It sounds like you are trying to have the sonicwall just sniff traffic, I would configure a mirrored port (on the switch) for this and then just configure the a wan interfaces for the sniffing. I would configure the port as a 'sniffing' zone as well, since you don't care about routing why have it even forward traffic? Not sure if this is what you were trying to do...

I have used sonicwall for several years, I like all their product for the most part. Can't say that I really use support much but have had up's and downs with the best of support calls. Typically first and second line of support are pretty weak anywhere.

Sonicwall NSA user

  • 1
    It should be in charge of forwarding traffic because it should have the ability to prevent a malicious transmission. It can't do much about preventing an attack if it's sitting on a mirror port. – Sam Rueby Feb 15 '12 at 14:00

After 3 weeks Sonicwall finally came back to me with a reply and even though I included a link to this page they still gave me the exact same reply as you had. Their support do not seem to know the difference between layer 2 and layer 3 on the OSI model.

I did make a complaint and had one of the support staff did phone me, but he did not seem to know what he was doing and I had to keep correcting him, he finally gave up and accepted it was beyond him and said he would need to pass it on to an engineer.

Anyone want to by $15,000 of sonicwall NSA's? Clearly their are issues with Sonicwall Layer 2 Bridging not to mention their support that takes 3 weeks to email a canned reply.

  • 1
    That's exactly what happened to me. In the end they were shocked I told them I was giving up going in circles with them. They were even more devastated when asked if they may close the issue as "resolved" and I said absolutely not. We got a call back later from some superior saying the next time we have an issue we will be immediately elevated to their most skilled support staff. I told them that should have happened 3 weeks ago. – Sam Rueby Feb 1 '12 at 18:30
  • Sonicwall have just closed the case as resolved, without resolving it! They keep doing this. Even worse they have just sent me a $2,000 support renewal invoice. What is the point in paying for support they are not providing? – Borg Feb 13 '12 at 8:50
  • It's sad that their product seems pretty awesome but they're supported by significantly less intelligent people than the people utilizing their product. – Sam Rueby Feb 15 '12 at 14:02

Possible solution / fix for that: Install a cheap router as a simple access router between both subnets. point a static route to it from the sonicwall so that all traffic passing between the two subnets will take place through the 'other' router.

  • 2
    Or get a Palo Alto firewall :) – SpacemanSpiff Oct 17 '12 at 14:36

If you're running bridged mode, there is an option in the bridge interface to "do not route on this bridge pair" which solves the problem and the subnets can talk again (ie: a true pass through).

The problem after this is that all traffic goes out, hits your router and is subject to firewall rules on the way back in (so you need more rules to allow your own ip's). It can also be a pain when you have a packetshaper before your router (or even if your router only has a 100m interface instead of 1gb) as this is no doubt going to shape the traffic as it passes and slow everything down. Its for this reason I contacted sonicwall and i agree, they are terrible and I'll not be renewing the support contract when it is due. All I get from them is irrelevant cut and pasted answerd that are completely useless.

We have an NSA 4500 which is not a cheap piece of kit and I expected more from them. Lets hope the Dell buyout can turn things around. I doubt it though...


The problem is that you didn't use a VLAN, you had overlapping subnets on the same ethernet broadcast domain. That's bad design and always will be.

  • Doesn't matter. The point of the device in this configuration is to listen and do nothing more than that. – Sam Rueby Sep 11 '13 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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