Hi Francis,

Thanks, it turns out that my previous fix was only temporary which made 
me realize that this actually is a problem with DNS since it was 
probably caching the host lookups and that is why it works for a little 
while.

I can not do a dig when the firewall is active(just hangs). However, my 
external DNS servers appear to be ips on my private network and it looks 
like there is a rule in my config to allow all traffic/protocals across 
eth0(private nic) so I am not sure what is going on. I also have port 53 
open to tcp/udp on both devices.

Thanks again for all your help.

Thanks,
Kris




Francis Cianfrocca wrote:
> On 10/4/06, Joe Regular <kristapestry / yahoo.com> wrote:
>>
>> Not sure what is going on with this thread but hopefully this post makes
>> it to the correct location...
>>
>> I checked the logs and all it says is basically that NET::HTTP cannot
>> resolve the host, so there isn't enough information to figure out
>> exactly why the connection is failing. I will give the SYN flag a try
>> and also look into understanding iptables on my own without the KISS
>> script. Thanks again for your help.
> 
> 
> There you go, that's good information. You need to look at how the 
> server is
> doing DNS. DNS works on port 53, usually by UDP (which rules out an
> interaction with TCP packet flags like SYN and ACK), but also 
> occasionally
> by TCP. Additionally, you need to make sure that /etc/resolv.conf looks
> proper, and that you have routes (through eth1) and firewall rules (port 
> 53
> outbound udp/tpc) to your DNS servers. Since you're using iptables, 
> you're
> also probably using Linux. Make sure that dig is installed on the box, 
> and
> then try to run dig against the hostnames of your external HTTP servers.
> That should give you a lot of useful information. Addtionally, go back 
> and
> try Net::HTTP with raw IP addresses instead of hostnames. If that works,
> then you've confirmed it's a DNS problem.
> 
> For what it's worth, I work with highly-secure perimeter-facing
> installations all the time- my company makes remote access appliances. 
> DNS
> misconfiguration (especially when split-horizon is involved) is one of 
> the
> biggest problems I see on a daily basis. Right up there with bad cabling
> ("Of course we checked the cables!"), dead switch ports ("No, we didn't
> change anything else in the DC"), and missing routes to LDAP servers 
> ("but I
> can ping that server from everywhere else!").


-- 
Posted via http://www.ruby-forum.com/.