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.
Best Answer
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.