From: Francis Cianfrocca Date: 2006-10-04T22:12:50+09:00 Subject: Re: NET::HTTP behind a firewall? ------=_Part_19348_29547949.1159967565887 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/4/06, Joe Regular 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!"). ------=_Part_19348_29547949.1159967565887--