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!”).
This site has a one free year deal that I used. It works great and
after your ap is running if you need more space or bandwidth you can
always upgrade. Every time I’ve sent their support an e-mail I get a
response that day. They truly are a good hosting company.
I highly recommend Rails Playground. Joe C. has responded to every
email request I have sent in a timely, courteous manner. Once, on a
Sunday afternoon, I sent a request to install a gem. Within a couple of
hours, Joe responded saying it was it done. On a Sunday!
That’s just one example of the outstanding customer service I have
received from Rails Playground.
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.
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!”).
To define your private network, use the PRIV_IFACE configuration
variable above.
We allow all traffic in and out of the private network
if [ ! “$PRIV_IFACE” == “”]; then
$IPTABLES -A INPUT -s 0/0 -e $PRIV_IFACE -d $PRIVATE_IP -p ALL -j
ACCEPT
fi
Francis C. wrote:
I think I remember seeing a rule that inhibited outbound connections of
any
kind except from the public interface (eth1). If your DNS servers are on
a
different network, then you won’t be able to reach them. If dig just
hangs,
then you know it’s a connectivity problem. Do you have any DNS servers
you
can access (like from your ISP) from your public interface?
To define your private network, use the PRIV_IFACE configuration
variable above.
We allow all traffic in and out of the private network
if [ ! “$PRIV_IFACE” == “”]; then
$IPTABLES -A INPUT -s 0/0 -e $PRIV_IFACE -d $PRIVATE_IP -p ALL -j
ACCEPT
fi
Francis C. wrote:
I think I remember seeing a rule that inhibited outbound connections of
any
kind except from the public interface (eth1). If your DNS servers are on
a
different network, then you won’t be able to reach them. If dig just
hangs,
then you know it’s a connectivity problem. Do you have any DNS servers
you
can access (like from your ISP) from your public interface?
Hi Francis,
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.
I think I remember seeing a rule that inhibited outbound connections of
any
kind except from the public interface (eth1). If your DNS servers are on
a
different network, then you won’t be able to reach them. If dig just
hangs,
then you know it’s a connectivity problem. Do you have any DNS servers
you
can access (like from your ISP) from your public interface?