Need a bit of help from a SonicWall ninja.

First off, I'm guessing this is actually a relatively easy problem to solve. I unfortunately don't have a ton of experience with SonicWall (we use WatchGuard at work) and the UI on their devices is so eye-bleedingly bad, I don't really know where to start working on this. I have a client who runs a translation business. They don't have a huge office but a previous IT consultant of theirs installed a SonicWall which they continue to use, despite it being overkill for their operation. They have a Windows 2008 server that hosts an Active Directory domain. The domain is called CompanyX.com on Active Directory (not going to post their real domain publicly) and it's the same as the domain where their e-mail and web site are hosted on.

The problem is that they can't read or edit their web site from inside their network. If they try to go to www.companyx.com, they get a message saying the web site is not available and to come back soon. It doesn't time out, that's an error page being generated from somewhere and it works perfectly fine from anywhere else. I'm presuming this is because something with the SonicWall is trying to direct internal web requests to that domain to somewhere other than their web hosting company. If they try to access the Outlook Web Access on their hosted Exchange service, that works fine. This has been a problem for a long time but they need to start updating their web site more frequently and thus, need to get this fixed.

Does anyone with SonicWall knowledge have an idea what this could be? Like I said, I'm sure it's not a difficult problem for someone with more SonicWall experience than I have. Thanks guys!

Was this an issue before the SonicWall was installed?

I ran into something similar a few years ago and I think the issue was DNS related and the way the domain was made. The AD domain being a .com points internally instead of their webhost. If I am remembering correctly, this is because AD conventions say you should do something like companyx.local for AD.

If my memory is correct, the solutions are to have a DNS entry that points to the webhost or to re-do the AD to be a .local. I would see what others have to say first as I'm pulling sh*t out of my memory's ass after being awake all night long.

Turn logging on for every network object and fw rule and see if you can catch what's going on in the logs. Short of that, around 50% of every SonicWall problem I have ends up being resolved with Wireshark.

Also what you're describing doesn't sound like a firewall rule. Are you definitely being routed to the right address? Checked what companyx.com resolves to and checked the access log on the actual site?

I don't know if this was an issue before. Another consultant setup his server, domain and SonicWall long before I entered the picture and he didn't document anything. Yeah, some more in depth diagnosis may be in order.

(a) turn logging on for everything
(b) isolate each step individually
(c) it's always DNS

You need to see what IP you're getting for www.companyx.com, both internally and externally. If it's the same, that's the basic problem. The typical solution for that is either a 'split horizon' DNS, where it answers differently based on the source IP address, or else two completely separate DNS systems, one for public consumption, and one for private. That's typically a good idea anyway; I don't like exposing Windows DNS services to the Net as a whole. (or Windows at all, really.)

Switching to a .local internal namespace would also probably work.

I typically approach this type of problem by hosting external DNS on Linux, usually in the DMZ, perhaps in the cloud. It's nice to have servers in different geographic locations. What I'll usually do is have a master server that's not accessible to the outside world at all, and is open on TCP and UDP port 53 only to my public nameservers. I do my editing on the master server, and then everything automatically gets pushed out to the public machines. If they crash or reboot or whatever, the open ports let them fetch new copies of the zone whenever they need it.

When I do this, I also usually set the master server to refuse queries from everywhere, and to allow zone transfers only to the designed slaves. The purpose of that machine (and it can be a virtual image just fine, there's just about zero load on it), is simply to be the repository of the master data, replicating it out to the real servers. It's much more difficult to crack or poison a DNS server that won't do lookups for an attacker. But I also make sure it's in the DMZ, because it is accepting direct connections from the outside world. The exposure is limited, but if one of my outside DNS machines get hacked, they've got an open port into my network, so that port needs to go into the DMZ.

Edwin wrote:

Was this an issue before the SonicWall was installed?

I ran into something similar a few years ago and I think the issue was DNS related and the way the domain was made. The AD domain being a .com points internally instead of their webhost. If I am remembering correctly, this is because AD conventions say you should do something like companyx.local for AD.

If my memory is correct, the solutions are to have a DNS entry that points to the webhost or to re-do the AD to be a .local. I would see what others have to say first as I'm pulling sh*t out of my memory's ass after being awake all night long.

I fairly sure this is the issue as well but memory is hazy. Checking MS support I came across this. I put in italics the most relevant part;

Naming conventions in Active Directory for computers, domains, sites, and OUs wrote:

Forests that are connected to the Internet
A DNS namespace that is connected to the Internet must be a subdomain of a top-level or second-level domain of the Internet DNS namespace.

Maximum number of domains in a forest
In Windows 2000, the maximum number of domains in a forest is 800. In Windows Server 2003, the maximum number of domains at Forest Functional Level 2 is 1200. This restriction is a limitation of multivalued non-linked attributes in Windows Server 2003.

Best practices

  • Because the DNS names of all the nodes that require name resolution include the Internet DNS domain name for the organization, choose an Internet DNS domain name that is short and easy to remember. Because DNS is hierarchical, DNS domain names grow when you add subdomains to your organization. Short domain names make the computer names easy to remember.
  • If the organization has an Internet presence, use names that are relative to the registered Internet DNS domain name. For example, if you have registered the Internet DNS domain name contoso.com, use a DNS domain name such as corp.contoso.com for the intranet domain name.
  • Do not use the name of an existing corporation or product as your domain name. You can run into a name collision later on.
  • Avoid a very generic name like maybe domain.local. Another company you merge with in a few years might follow the same thinking.
  • Do not use an acronym or an abbreviation as a domain name. Users may have difficulty recognizing the business unit that an acronym represents.
  • Avoid the use of underscores (_) in domain names as applications might be very RFC obedient and reject the name, and will not install or work in your domain, and you might experience problems with older DNS servers.
  • Do not use the name of a business unit or of a division as a domain name. Business units and other divisions will change, and these domain names can be misleading or become obsolete.
  • Do not use geographic names that are difficult to spell and remember.
  • Avoid extending the DNS domain name hierarchy more than five levels from the root domain. You can reduce administrative costs by limiting the extent of the domain name hierarchy.
  • If you are deploying DNS in a private network, and you do not plan to create an external namespace, register the DNS domain name that you create for the internal domain. Otherwise, you may find that the name is unavailable if you try to use it on the Internet, or if you connect to a network that is connected to the Internet.

Looks like you have to do as Edwin remembers but some more research might be in order.

I feel less sh*tty now posting what I posted.

It occurs to me that I might not have been clear enough; the final goal there is to have outside people be given the public IP for your webserver, and people behind the firewall to get the private IP. The idea of using external Linux/BIND servers is just one approach to getting that done.

Another possibility, a way of dodging the problem, might be configuring the Sonicwall to do NAT from and to inside addresses. I don't know if its engine is smart enough to do this, though. The Linux kernel can sorta do it; if your actual final target is in a different private IP space, then it can successfully NAT when you connect to the public IP.

That is, say you've got a main internal network on 192.168.0.X, and a DMZ on 192.168.1.X. If you have a NAT mapping from public IP 1.2.3.4 to the DMZ webserver of 192.168.1.10, then connections from 192.168.0.X to 1.2.3.4 will be correctly routed and NATted, and everything will work. But, at least as of the last time I tested this, several years ago, connections from 192.168.1.X to 1.2.3.4 will fail, because Linux gets confused when the packet's source and destination end up being in the same network.

There's no real fundamental reason why this couldn't work flawlessly, from and to anywhere, but most NAT engines don't handle that scenario properly. Linux gets about halfway there, and if your public webserver is in a separate private IP space (which it should be!), then a Linux firewall would do what you need. I'm not sure what Sonicwall is using for a NAT engine, so it may not be capable, and of course you may simply not have enough interfaces on the machine. But if it can be configured to work like Linux, and if your network is structured properly, you should be able to get NAT working to your DMZ from your trusted network.

A somewhat irrelevant aside, which may not be even vaguely practical for you: I'm very fond of using Linux as a firewall; the open source fwbuilder package has a rather Checkpoint-like interface, although it's still, um, I guess 'weird' is the right way to describe it. The GUI is functional, and it's easy to read the firewall rules once you've built them, but the interface is kind of strange and arbitrary. It's not that difficult, it just does things differently than you'd really expect. And it can target a whole bunch of different device types; they charge for being able to compile to Cisco's IOS or a few other targets, but a Linux target is free. Between the Linux kernel and fwbuilder, you can put together startlingly fast firewalls, just for the cost of the hardware, once you know how it all works. But you have to know your firewalling.

And, of course, you can skip fwbuilder and just write your own ruleset using a shell script and iptables, but that gets pretty hairy in any kind of complex environment. As soon as you have more than a private and a public network, the number of possible interactions between the various networks can cause a combinatorial explosion of rules, and a GUI can make that a fair bit easier to reason about.