Relevant mostly to OS X admins
Sonicwall “Error: Index of the interface.: Transparent Range not in WAN subnet”
June 12, 2014Posted by on
I recently needed to put an internal server in my org’s DMZ, because the service didn’t play nicely with 1:1 NAT, returning unusable data to remote IP phones. To configure my Sonicwall, I started following a blog post by guru-corner.com, as I often find what is documented by an outsider as more complete than the manufacturer docs (YMMV). However, my efforts to set up both the X4 and a vlan in transparent mode were rejected with a “Error: Index of the interface.: Transparent Range not in WAN subnet” alert. It wasn’t until I read Dell SonicWall’s documentation that I focused in on the one key word: primary.
We have 3 WAN links here, 2 I use for traffic, and a small link only suitable for “when all else fails”. SonicWall devices give a number of options for failover and load balancing:
- Basic Failover: Always route traffic out primary connection, secondary quietly waits to take over iff primary fails
- Round Robin: Cycle through the outbound links for each new connection, maintaining an approximately equal number of connections through each.
- Spill-over: Use the first defined interface for traffic, until a certain bandwidth usage is reached. Once that happens, use round robin logic across the remaining link(s). If there’s only a secondary link, then once primary hits the usage threshold, all subsequent requests go out the 2nd link. (I’ve not found it documented for what duration traffic must exceed the threshold. 1 second? 1 minute? Rolling average over $time?)
- Ratio: Round Robin, but instead of equal distribution, it can be weighted. I see using this when there are multiple links, you’d like to use them all, but they’re not equal bandwidth. You could set a ratio of use proportional to their percent of their bandwidth contribution to the whole.
Since the device was brought online, I’ve defined our cable modem as the primary link, with a Spill-over at 85% of inbound capacity to the 2nd link. This has worked well, but it’s what tripped me up: our cable provides a single IP, while my 2nd link routes a /28 network. It was one of these /28 I wished to apply transparent IP mode to, but since it wasn’t defined as the primary in my load balancing configuration, my change was rejected. After redefining the load balancing group to have X2 as the primary with a low exceeds value, I was then able to define the transparent mode as desired.
Additionally, when configuring failover criteria for SonicWall links, you want to set up multiple conditions with “Probe succeeds when either a Main Target or Alternate Target responds”, with a very reliable external host as the Alternate Target- I use ICMP to http://www.google.com, with 3 DNS servers on 3 networks configured under Network:DNS. Default SonicWall conditions for the probes that monitor “is this link up?” is to connect to responder.global.sonicwall.com:5000. This is fine for one of the criteria, but consider what would happen if you have multiple links, all only asking “is responder.global.sonicwall.com up?” and something happens to the service, which has happened. Both links simultaneously and erroneously say “probe failed, therefore the WAN link failed. I’m supposed to shut down”, and dutifully do so- unnecessarily taking that location offline. Not fun.
This configuration is found under Network: Failover and LB: [expand the group]: click [configure] for each link member.