[SOLVED] IPTables, ssh timeout

SilkBC · 04-16-2012, 04:58 PM

Hello.

I am testing some firewall and VPN-related issues for a client of mine. I have created a simulated environment using VirtualBox with a simulated WAN link between two firewalls (it all uses "internal networking" so there is no actual access to the Internet or even my own LAN).

I have the firewalls in my simulated environment with the actual IPs of their real-world counterparts that they are simulating. Everything works, at least as far as being able to ping between the firewalls, as well as from a client on the "local" network to the "remote" firewall (i.e., routing and NAT works)

The problem seems to be when I try to SSH from one firewall to the other. If I have any "DROP" policies for INPUT in place, the SSH connection times out, but if I change it to "ACCEPT, it works. I do have a rule in my IPTables script that allows SSH.

Here is my IPTables script (just really basic):

Code:

# Default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Flush and delete all rules
iptables -F
iptables -F -t nat
iptables -F -t mangle
iptables -F -t filter
iptables -X

# Enable routing
echo "1" > /proc/sys/net/ipv4/ip_forward

# Set INPUT rules
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -i rth0 -p tcp --dport 22 -j ACCEPT

# Set FORWARD rules
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

# Setup NAT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

When I run "iptables -L" it outputs the following:

Code:

Chain INPUT (policy DROP)
target     prot opt source           destination
ACCEPT     icmp --  anywhere         anywhere
ACCEPT     tcp  --  anywhere         anywhere       tcp dpt:ssh

Chain FORWARD (policy DROP)
target     prot opt source           destination
ACCEPT     all  --  anywhere         anywhere       state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere         anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source           destination

If I change the "INPUT" policy in my firewall script from "DROP" to ACCEPT" on the firewall I am SSH'ing *from*, then I can connect. However, leaving it as "DROP" makes it time out.

I have also tried changing the INPUT policy to ACCEPT then added "iptables -A INPUT -j DROP" at the end of my INPUT rules, but it still times out.

Now one thing that is a bit different is my routing table. In order to simulate the WAN VirtualBox, I had to remove the default gateway for the "WAN" IP and instead use the following to make the "routing" work:

Code:

route add default dev eth0

so my routing table looks like this:

Code:

Kernel IP routing table
Destination     Gateway       Genmask         Flags Metric Ref     Use Iface
111.222.333.444 0.0.0.0       255.255.255.248 U     0      0         0 eth0
192.168.10.0    0.0.0.0       255.255.255.0   U     0      0         0 eth1
0.0.0.0         0.0.0.0       0.0.0.0         U     0      0         0 eth0

Note: In the above, for purposes of this posting, I have replaced the "WAN" IP with <111.222.333.444>

Since SSH works with "INPUT" set to ACCEPT, though, I am not positive it is a routing issue.

Anyway, any insight you could provide on this would be appreciated. Let me know if there is any additional information you need.

-SilkBC

SilkBC · 04-16-2012, 05:28 PM

OK, found the solution. My "INPUT" rules should have one of the following lines at the start:

Code:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

or

Code:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

I am not sure why, but the latter one is apparently superior to the first one. It was suggested to only use the first one if the "conntrack" module is not available (the example given was on a "castrated VPS")

I tried both code snippets and they both work, so now I can SSH between my simulated firewalls without opening it wide.

-SilkBC

okcomputer44 · 04-16-2012, 10:04 PM

Hi,

Apparently the ESTABLISHED,RELATED is a must have line.

Without that it wont work properly even if the connection is already built up.
If you delete that line from the chain you will lose the connection straight away.

These are the explanations for them from man page:

Quote:

NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions.

ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions

RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.