Matt Singerman wrote:
Wow, that came out looking all messed up, let me try sending that again:
Hmmm... That is definitely part of it, yeah. But there is something
else going on here.
So I tried changing the chain policy to ACCEPT and to just block all
traffic using an iptables rule. When I implement the rules as
follows, things work:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT
tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh
flags:FIN,SYN,RST,ACK/SYN
DROP tcp -- anywhere anywhere tcp dpt:ssh
flags:FIN,SYN,RST,ACK/SYN
As you can see, that is just blocking all traffic from anywhere to
anywhere on port 22 after allowing traffic from x.y.z.116 to x.y.z.120
through. (x.y.z.116 and x.y.z.120 are both on the same subnet, but
120 is behind the firewall and 116 is not.) x.y.z.116 can SSH in to
x.y.z.120, but nothing else can.
If I try to change it so that it isn't just blocking traffic on port
22, but rather all traffic:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT
tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh
flags:FIN,SYN,RST,ACK/SYN
DROP tcp -- anywhere anywhere
No SSH connections can get through at all, even from host x.y.z.116.
Any ideas what could be causing this odd behavior?
Nothing odd here. First you allow all all syns from .116 to .120. You
dorp all other syns. You allow all other traffic, which includes all
non-syn traffic. In the second scenario you aloow the syns, but frop all
non syn traffic. So the syn gets through, but the syn-ack from the ssh
server gets dropped.
What you should be doing is this:
# let through all traffic from established connections
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# let through the connection request
-A FORWARD -p tcp --dport 22 -s x.y.z.116 -d x.y.z.130 -j ACCEPT
# log and drop all other traffic
-A FORWARD -j LOG
-A FORWARD -j DROP
For further information, read the howtos at the www.netfilter.org site.
HTH,
M4
