Bizarre Name Resolution/Routing Problem

[Kurt Wall]

Okay, boys and girls, this one beat all. At work, we're having the 
strangest name resolution or routing problem I've yet to encounter.
For the record, the architecture and configuration is legacy stuff
that I/we have to nurse along until we get something better put up.

We have a Web site, www.timesys.com, a CNAME for timesys.com, which
resolves to 66.207.129.180:

$ host www.timesys.com
www.timesys.com is an alias for timesys.com.
timesys.com has address 66.207.129.180

Between the Web server (Apache 1.3.mumble running on Red Hat 3.mumble)
and the Internet sits a firewall device, one of those Watchguard Firebox
gadgets (to which I don't have access). If I traceroute from my house
to the Web site, I get:

[kwall]$ traceroute www.timesys.com
traceroute to timesys.com (66.207.129.180), 30 hops max, 38 byte packets
 1  marta (192.168.0.1)  0.496 ms  0.142 ms  0.128 ms
[...]
13  noused.timesys.com (66.207.129.180)  32.169 ms  32.362 ms  29.906 ms

Note the name: noused.timesys.com. That name doesn't appear anywhere
that I've seen in our DNS files. 

Meanwhile, periodically through the day and especially through the
evening (USA east coast), visitors to the site can't get through. The
name resolves to the proper IP (modulo the noused.timesys.com nonsense),
but nothing comes up. You can traceroute to it, but can't ping it _from the
outside_. From inside the firewall, we can ping the machine and get it to
serve up pages no problem. We use NAT to access the site using an address 
taken from one of the private IP address ranges (10.10.129.180, if you must
know).

What has me baffled is that we can ping the stupid thing from the inside
using the NATed address, but not from the outside using its true address.
I'm starting to suspect a hardware problem on the firewall, but I honestly
don't know. Anyone have some ideas?

Thanks,

Kurt
-- 
"An ounce of prevention is worth a pound of purge."