# 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:

```
                 

                        Network I                                        Network II

Gentoo Box A <---------------------------> Gentoo Box B <-----------------------------> Gentoo BoxC

   192.168.22.223                 192.168.22.209       192.168.33.193                 192.168.33.228                

```

This diagram greatly simplies the actual network, but does illustrate where the static route is defined (that is from Box A to Box C, through Box B). Static route's have been defined for both machines, BoxA to locate Network II through gateway 192.168.22.209, and BoxC to Network I throu gh gateway 192.168.33.193.

I am able to ping from Box A to Box C -- No problem

I am able to ping from Box C to Box A -- No Problem

I am able to ssh from Box A to Box C -- No Problem

I am NOT able to ssh from Box C to Box A -- Problem!!!

I am running out of idea's of what to try and really what to look for. Its ackward how ssh work in one direction but not the other ..  should I be investigating the Gentoo Box B more for the problem??

Thanks again for your time

Take careLast edited by NiceGuy on Mon Apr 16, 2007 1:44 pm; edited 1 time in total

----------

## timeBandit

Is Box B a firewall? If so, is it configured to forward traffic on port 22 in only one direction?

----------

## 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.

 *Quote:*   

> 
> 
> Is Box B a firewall? If so, is it configured to forward traffic on port 22 in only one direction?
> 
> 

 

Yes box B is a Firewall,  and ssh is configured for port 22 ...  but I am unsure of if it is configured in one direction ... I am sorry but how would I verify this??

 *Quote:*   

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

 

When I attempt to ssh from Box C to Box A, I get a connection to Box B .. I know that sounds wierd, but it is true. So imagine trying to login to Box A like so.

```

prompt@BoxC$:    ssh username@192.168.22.223

passwd: xxxxxx

promtp@BoxB$:    ( Now in Box B  NOT Box A!!!)

```

Nothing hangs .. it's just simply not ssh'ing into the Network I when I'm in Network II (the one direction only seems to be limited), However,  ssh' ing into Network II from Network I, is fine as dandy.

Thanks again for your time

Take Care

p.s --> sorry I don't usually use the word 'dandy'

----------

## 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?

----------

## NiceGuy

Hello again,

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

```

prompt@BoxC:  netstat -an | grep :22

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

tcp        0      0 192.168.33.228:42959    192.168.22.223:22       ESTABLISHED

```

** This shows (improperly, mind you) the connection from Network II (BoxC) to Network I (BoxA) via gateway BoxB

```

prompt@BoxB:  netstat -an | grep :22

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

tcp        0      0 192.168.22.209:22       192.168.33.228:42959    ESTABLISHED

```

** This shows that th actual connection is between BoxB and BoxC

```

prompt@BoxA:  netstat -an | grep :22

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

```

**This shows BoxA knows nothing about an ssh connection to Network II??

So it appears as though Box B is stealing the ssh connections from Box A  ... but I am not sure how to correct (or explain) this ..  any suggestions??

Thanks again and Take Care

----------

## timeBandit

OK, so again: *timeBandit wrote:*   

> ... can you connect from C to A via SSH if you shut down the SSH server on box B?

 You have SSH servers listening on all three boxes, as confirmed by netstat. Get rid of the one that's on the gateway and see what happens. If Box B is headless and you depend on SSH to administer it, you'll need to temporarily install telnetd or a keyboard & monitor so you can make this test.

If you still can't connect from C to A, it's a gateway configuration problem (routing tables, iptables, etc.)--because it would mean the connection request is being routed no further than B and there is no longer be a process there to accept it.

If you can connect properly, it's either an SSH configuration problem alone, or an interaction between the SSH and gateway configurations.

----------

## NiceGuy

Hello again,

 *Quote:*   

> 
> 
> .. can you connect from C to A via SSH if you shut down the SSH server on box B?
> 
> 

 

I shutdown the ssh server on BoxB, First I attempted to:

1   ssh into BoxC from BoxA  -- No Problem, works fine.

2.  ssh into BoxA from BoxC  -- Probem, does not work .. reports back the following:

```

prompt@BoxC:  ssh username@192.168.22.223

ssh: connect to host 192.168.22.223 port 22: Connection refused 

```

Now that the ssh server is down at the gateway BoxB ... ssh into Network I from Network II is not even accepted. 

After reading your last post timeBandit .. I suppose the problem may be with a routing /iptables  configuration ... I assume this is a configuration problem that resides on the gateway (BoxB) .. does that sound about right?? 

My route tables for the following three boxes look like:

```

prompt@BoxA ~ $ netstat -rn

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

192.168.33.192  192.168.22.209  255.255.255.192 UG        0 0          0 eth0

192.168.22.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo

0.0.0.0         192.168.22.48   0.0.0.0         UG        0 0          0 eth0

```

```

prompt@BoxB ~ $ netstat -rn

192.168.33.192  192.168.33.193  255.255.255.192 UG        0 0          0 eth0

192.168.33.192  0.0.0.0         255.255.255.192 U         0 0          0 eth0

192.168.22.0    192.168.22.209  255.255.255.0   UG        0 0          0 eth1

192.168.22.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo

```

```

prompt@BoxC ~ $ netstat -rn

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

192.168.33.192  192.168.33.193  255.255.255.192 UG        0 0          0 eth0

192.168.33.192  0.0.0.0         255.255.255.192 U         0 0          0 eth0

192.168.22.0    192.168.22.209  255.255.255.0   UG        0 0          0 eth1

192.168.22.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo

```

Addionally, the Network Address/Masks for the networks:

Network I:   192.168.22.0 / 255.255.255.0

Network II:  192.168.33.192 /255.255.255.192

Thanks again for your time and guidance

----------

## 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  :Smile: 

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.

----------

