I tried removing the SYN rules and various other ones with no luck. I
also tried allowing all outgoing ports above 10000 with no luck. However
when I allowed outgoing ports below 10000 it worked. Not sure why yet
but I will attempt to figure out the exact port it needs a little later.
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.
Francis Cianfrocca wrote:
On 10/3/06, Joe Regular <kristapestry@yahoo.com> wrote:
Sorry, I meant you won't be able to complete TCP connections that you
initiate.
--
Posted via http://www.ruby-forum.com/\.
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,
In that case, look into how your system resolves names into IP addresses. Do
you have a local name server or do you rely on your ISP's name server? Is
the required port(s) open?
so there isn't enough information to figure out
exactly why the connection is failing.
There is enough to know the problem is name resolution.
···
--
Paul Lutus
http://www.arachnoid.com
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!").
···
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.
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/\.
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?
···
On 10/4/06, Joe Regular <kristapestry@yahoo.com> wrote:
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 beleive this rule should enable me to reach the DNS servers from eth0
since PRIV_IFACE is set to eth0. Do you see anything wrong with it?
···
##############################################################################
#
# 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 Cianfrocca 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?
--
Posted via http://www.ruby-forum.com/\.
In the output of kiss when it starts I noticed there appears to be an
error.
"/usr/sbin/kiss: line 341: [: eth0: unary operator expected"
Line 341:
if [ ! "$PRIV_IFACE" == ""]; then
$IPTABLES -A INPUT -s 0/0 -e $PRIV_IFACE -d $PRIVATE_IP -p ALL -j
ACCEPT
fi
I will have to brush up on my shell scripting sytax to see what is wrong
with comparison but hopefully that does the trick!
Thanks
Joe Regular wrote:
···
I beleive this rule should enable me to reach the DNS servers from eth0
since PRIV_IFACE is set to eth0. Do you see anything wrong with it?
##############################################################################
#
# 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 Cianfrocca 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?
--
Posted via http://www.ruby-forum.com/\.