Static Route and Remote SSH connection

[NiceGuy]

Hello all,

I have a problem runnig a ssh connection to a computer whose path is defined with a static route, here let me illustrate:

[timeBandit]

Is Box B a firewall? If so, is it configured to forward traffic on port 22 in only one direction?
_________________
Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.

[user11]

What do you mean by "problem"? What is the output if 'ssh boxA' command?

Does it 'hang' for a long time?
If so, try 'netstat -an |grep 192.168.22.223` at boxC at the moment when 'ssh boxA' command is 'hanged'. You will see if it is trying to connect.
Also, the outout 'netstat -an |grep 192.168.33.228' executed at boxA at the same moment would be useful for diagnistics.
What is the output of these commands when you have ssh session from A to C?

[NiceGuy]

Hello,

Thank to both of you for your speedy replies.

[user11]

Looks like B is redirecting connections to itself (iptables?). Netstats (when the session is established) should make the things definite:

@boxC $ netstat -an |grep :22
@boxA $ netstat -an |grep :22

We expect the first command (at C) will display you connection as if it is connected to A, but netstat at A will say it does not know anything of this kind.

If so, it would be interesting to ensure that
@boxB $ netstat -an |grep :22
(yes, the same command)
says there is a connection from C _to_B_.

[timeBandit]

Another easy check, that may help verify whether box B is "stealing" traffic for the 192.168.22.0 subnet: can you connect from C to A via SSH if you shut down the SSH server on box B?
_________________
Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.

[NiceGuy]

Hello again,

I attempted to preform some of the tests suggested in the previouis posts:

[timeBandit]

OK, so again:

[NiceGuy]

Hello again,

[user11]

I am almost sure that netstats have proved that this is a NAT (Network Address Translation) problem.

Look, you have a working connection from boxC to some ssh.
TCP/IP of boxC thinks it is taking to boxA, but boxA does not know this connection.
Moreover, boxB *does* know very similar connection (see the same port 42959 at 192.168.33.228).
So, we can conclude that this is the *same* connection, but it seems to boxB in a different way than to boxC.

That is not possible for tcp/ip (no matter what routing tables are) without NAT.

So, this is some kind of NAT affairs - either at B or at C or somewhere between them.

The behaviour you have seen when B is down is consistent with this model: some NAT translates address from boxA to boxB and your packet hits port 22 of tcp/ip at boxB - there is nothing listening - and you get "connection refused".

The above is logics.
Assumptions follows.

I suppose that that is work of iptables on boxB's, something like "redirect all forwarded connections to ssh at 192.168.22.* to its own ssh".
You need to contact administrator of boxB to check that. If you are one, you will have to remember what is setup on boxB

The possible workaroud may be (but not surely will be!) to try use some other port for SSH daemon at boxA.

(Based on common sense, I can also suppose that you will have the same 'stealing' sympthoms when you try to connect from boxC at any address of 192.168.22.0-192.168.22.255, even if that address is not used at all! If you test this, it might may get more hints about where to look for). Also, maybe from any 192.168.33.192/255.255.255.192 network to any 192.168.22.*. Maybe but not nesessarily.

As for routing tables, they do not perform NAT (hm... at least in classics). Also, they seem ok.

So, I suggest 3 ways.
1. try to find workaround (if you do not need to find what is up or if you cannot contact an administrator);
2. try to find what is happening by studying configurations of various NATs;
3. make some research, if this problem is still actual with other tcp ports, other destination IPs, other source IPs, then think again (if no other ideas).

[desultory]

Moved from Other Things Gentoo to Networking & Security.

[Hu]

Please post the output of iptables -n -v -x -t nat -L and iptables -n -v -x -L.