I've added CODE tags to your post in order to add readability.
Going forward, please use CODE tags on your own.
Quote:
Originally Posted by jacques83
Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 3 180 NETWORK_STATS all -- * * 0.0.0.0/0 0.0.0.0/0
2 0 0 ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 0 0 ACCEPT all -- eth0 eth2 0.0.0.0/0 0.0.0.0/0
4 0 0 ACCEPT all -- eth2 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
5 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
6 3 180 ACCEPT all -- eth2 eth0 0.0.0.0/0 10.1.1.2 state NEW
7 0 0 ACCEPT all -- eth0 eth2 10.1.1.2 0.0.0.0/0 state NEW
|
Well, the policy isn't getting hit so that's good. The rule which allows the handshake to start is getting hit, which is good too. No packets in state ESTABLISHED seem to be passing through here, though, which is bad.
Quote:
Code:
root@r-4-TEST:~# iptables -nvL -t nat --line-numbers
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 1 60 DNAT all -- eth2 * 0.0.0.0/0 192.168.30.41 to:10.1.1.2
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 SNAT all -- * eth2 0.0.0.0/0 0.0.0.0/0 to:192.168.30.45
2 0 0 SNAT all -- * eth2 10.1.1.2 0.0.0.0/0 to:192.168.30.41
|
The first POSTROUTING rule conflicts with the second one. That is, packets exiting eth2 will get their source address changed to 192.168.30.45, regardless (the 192.168.30.41 rule doesn't stand a chance). To fix that, just invert the rule order. But still, that doesn't seem to be the underlying cause of your issue, since neither rule is getting hit.
I must ask: Are you sure that the SSH box (10.1.1.2 AFAICT) is properly setup? It seems to me that having the gateway address on it improperly configured could cause these very symptoms. Let us know.