Advice for configuring a SonicWALL NSA 2400 to use two subnets and L2 Bridge Mode

Question

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: 0.0.0.0, 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: 0.0.0.0, interface X1. Source: Any, Dest: Subnet A, gateway: 0.0.0.0, 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.

Solution 1

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.

Solution 2

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.

Comments

[Borg]

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.

[SpacemanSpiff]

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?

[Sam Rueby]

Nope. I have no control over it. It's effectively "the Internet".

[Safado]

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.

[Sam Rueby]

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.

[Borg]

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?

[Sam Rueby]

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]

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]

Doesn't matter. The point of the device in this configuration is to listen and do nothing more than that.