Choose from several options for complete web, email and data security.
Learn more
Evaluate Websense products by watching demos and installing evaluation software.
Learn how Websense solutions help keep our customer safe, secure and productive
Get information on product updates, support resources and more.
Get the most out of support in five simple steps.
Find tools and assets to help sell Websense solutions.
Come work for the global leader in unified information security. Go
When trying to set up an ESG (v7.6.2) to its remote SQL server, the field in TRITON says you can use the host name or the IP address.
In fact, when you're using a remote SQL server and Windows authentication, the ESG installation program for TRITON very nicely builds the correct ODBC connection and fills in the Log Database field in Email Security with the FQDN of the SQL server.
So it you're using "websensedb.sql1.example.local" as the remote SQL server, it very nicely prefills that in.
But it doesn't work. The ODBC connection passes its Connection Test satisfactorily but when you test the connection from the ESG it fails. Not only does the FQDN fail, so does just the host name. You MUST enter the IP address of the SQL server and then it works from the ESG immediately.
We use CNAMEs for all database connections. This lets us do DR faster because we just have to change one DNS entry. But in the ESG we must use the IP address even though the ODBC connection on the same server works fine by the fully qualified CNAME.
I do believe this is a DNS issue on the ESG side. Meaning, if the ESG cannot resolve your dns entry, then you do need to use IP addresses. Are you putting ESG into a firewalled area where it can't resolve your DNS entries?
JACOB SLOAN, CCNA, WCSE
Well, that kind of depends. The C interface where the log traffic is routed through is configured with our internal DNS servers and it can and does query them.
The E1 interface, the TCP 25 SMTP port, also has valid DNS servers but they query the ISP's DNS servers. We run a split DNS system so our internal DNS entries are only available on our internal DNS servers.
It would really suck if our internal DNS servers were available from an Internet-accessible server and the server got hacked, revealing our internal DNS structure. (Not necessarily an ESG hack but we have a lot of other Internet-accessible servers).
It sounds like you're saying the DNS query might be routed out the E1 interface even though we use a Module Route to put the log database traffic through the C management interface.
I could live with that if there was a way to put a HOSTS entry on the appliance. I don't recall seeing that in its interface.
BTW, it took quite awhile to figure out what was going on. An error message that name resolution did not work FROM THE APPLIANCE would have saved a couple of hours as we checked and rechecked the firewall and database server logs. Because we were doing everything from TRITON we thought it was a TRITON issue.
From TS, we can help adding the information to the HOSTS file, but upgrades and patches may destroy such information.
What i would personally do is to have ESG query the internal DNS server. ESG itself should be behind a firewall and not publically available. IF ESG is in a DMZ, and there is a firewall NAT rule in there that allows ESG to query the internal DNS, then that should work and would not directly expose internal dns structure.
And yes, DNS queries are routed through E1.
This problem reoccurred and as part of a support case we figured out what was happening. Somehow the ESG configuration process takes the domain of the ESG and puts it in the resolv.conf file as a DNS search order. While we could set up the DB connection by IP address it would fail later on. The only way to get it working again was to put invalid DNS servers on the E1 interface temporarily.
Apparently when the ESG connects to the SQL server by IP it retrieves the SQL server's hostname and tries to use it for some operations. So it tries to do a DNS lookup on sqlhostname.ourcompany.com on the Internet but there is no such record so it should fail.
But it succeeds because of a wildcard entry in our Internet DNS. The wildcard entry returns the IP address of our public website at a third-party. So we see SQL connection attempts over the Internet to our website.
Also putting in a hosts file entry on the appliance did not fix it. While it should have, apparently the ESG software does not look at the hosts file.
We *fixed* it by putting in a module route to the internal DNS servers and configuring the E1 interface to use the internal DNS servers. We also had to add A and PTR records into the internal DNS because the Internet zone is a different domain (.local instead of .com)
While this was going on, the problem manifested it as an inability to get to the PEM login page. The browser just hung on "connecting" for thirteen minutes until it finally comes up. Must be some kind of timeout in the software at thirteen minutes.
Ray
