# second network connection, server access

## sorcerer25

hi,

i have a kind of odd problem ...

i have a server used as a router

on the intranet i have a router (device, not a computer) set with port forwarding to the server's ssh port (port forward is working i tested it by changing server gateway)

now, i want to enter server via router's internet connection, but the problem is that router is "so smart" that instead of connecting to the server with it's own local ip address, it connect to the server with the source ip address (which is outside local network) so the server will try to respond via it's own gateway and then this is not working (packets come to one ip from one network connection and try to exit via another ip and another network connection)

any idea how i could make this work ?

----------

## pianosaurus

I'm not sure I understand your description correctly. Does your server have two interfaces (one local + one external)? Here's what I thought I understood:

```

  Ext1        Ext2

   |           |

********    ********

*Router*    *Server*

********    ********

   |           |

   \----LAN----/

```

You connect with SSH to the server from Ext1, router passes data on to the server via port forwarding. The server responds on Ext2 instead. Did I get that right?

If so, your router isn't smart at all. The router just passes the TCP/IP packets on to the server without changing them. The packets already contain the return address, so your router isn't "connecting with" an IP address at all. If you want the server to respond via the router, you need a router capable of packet mangling (changing content of the packets). That would probably not work well with SSH, as both the client and the server will try to verify the validity of the packet source. (Actually, I think it would work, but give you warnings. This would leave you vulnerable to man-in-the-middle attacks, as you will have to ignore the warnings every time.)

I don't think there is an easy solution to this. The only solution I can see immediately is to connect directly using Ext2, or setting up a routing table in the server (if you know here you will be connecting from).

Did I get your problem all wrong?

----------

## sorcerer25

thank you for making it clear

you get it very right

the only thing "wrong" is that router cannot pass packets without changing them be cause i have non-routable IPs on intranet and otherwise that port forwarding won't work at all, but if i change at all default route to the server it is working ...

----------

## pianosaurus

 *sorcerer25 wrote:*   

> thank you for making it clear 
> 
> you get it very right

 

No problem.

 *sorcerer25 wrote:*   

> the only thing "wrong" is that router cannot pass packets without changing them be cause i have non-routable IPs on intranet and otherwise that port forwarding won't work at all, but if i change at all default route to the server it is working ...

 

Yes, the router changes the destination address, but not the source address. There is normally no need to change the source address, so this is considered an extra feature when in routers. Also, as I said, even if your router could do it, it would probably not be a good idea with SSH.

Is there any particular reason you can't connect directly on Ext2? Are Ext1 and Ext2 different networks but with overlapping IP space?

----------

## sorcerer25

this suppose to be a fail safe entry to the server when main connection is down, unfortunately the main connection may go down be cause of multiple points (direct link down, isp internet connection down, isp out-continent down, is working but with a lot of losses, etc. ... i saw them all) so is almost impossible to determine if is not working or only partially not working, so a script to change it automatically

and if main is down i should enter from outside and change local net internet connection (secondary internet connection is intended only for backup purposes and is way less than main) when someone call me  :Smile: 

bottom line is that problem cannot be solved on server but only on router, right ?

----------

## pianosaurus

I believe it can be solved in the router, by changing the source address on incoming packets, but I haven't actually tried it. If the connection is always coming from the same place, it can also be solved in the server by forced routing any response to that address through the router. That last option would of course make it impossible to log on directly through Ext2 from that address.

If the only thing you want to do through the SSH connection is to change the routing table of the server, you could of course find some way of doing it that doesn't require a response at all. For example some form of port knocking.

----------

## boerKrelis

I guess this can be solved with source policy routing. Maybe you need to identify (maybe using iptables + packet marking) traffic coming in on the LAN side (from the router) first, maybe not, but your policy would then be to route the responses to those incoming packets (RELATED in iptables-speak) through your router.

----------

## boerKrelis

Oh and SSH is fine with some encapsulation. A known destination (~/.ssh/known_hosts) whose hostkey changes, now that is a problem (possible MITM). A new destination which has the same hostkey as some other known destination, no problemo. So you can tunnel SSH over SSH and connect to some port on your localhost interface, and all you get is a warning because you don't know this endpoint yet. Something along the lines of 

```
The authenticity of host '[localhost]:1222 ([127.0.0.1]:1222)' can't be established.
```

Inspect the fingerprint, type 'yes' once, and SSH will never bother you again. Unless you tunnel some other endpoint to your localhost interface on the same port, that is, as explained above.

----------

## pianosaurus

 *boerKrelis wrote:*   

> 
> 
> ```
> The authenticity of host '[localhost]:1222 ([127.0.0.1]:1222)' can't be established.
> ```
> ...

 

That's what I expected. What I'm worried about is if someone then executes some form of man-in-the-middle attack. Will you get the warning again? Or have you just accepted that host key coming from anywhere (since it's coming from the router either way)?

----------

## boerKrelis

 *pianosaurus wrote:*   

> 
> 
> What I'm worried about is if someone then executes some form of man-in-the-middle attack.
> 
> 

 

You'd notice, because the host key fingerprint would not match the one you already know. You know it already because you have connected to this SSH server before. From man ssh: 

```
ssh-keygen -lv -f ~/.ssh/known_hosts
```

will show you all the fingerprints you've collected so far.

 *pianosaurus wrote:*   

> 
> 
> Or have you just accepted that host key coming from anywhere (since it's coming from the router either way)?
> 
> 

 

But it's not coming from the router. Host keys are something internal to the SSH server you're connecting to. It usually lives in /etc/ssh/ssh_host_rsa_key and you can get its fingerprint by running 'ssh-keygen -l -f' on it. Thankfully, it doesn't matter which route the packets take.

If you're connecting to a SSH server you've never connected to before, then yes, if you don't verify the host key fingerprint (call the server administrator, whatever) then there's an opportunity for a MITM. So verify those fingerprints ;-)

To successfully MITM an existing SSH connection you'd need to know the session key. If someone succeeds in doing that, then they'll have broken pretty much all of current crypto. (Grave bugs in SSH not considered).Last edited by boerKrelis on Thu Jan 28, 2010 6:54 pm; edited 1 time in total

----------

## pianosaurus

 *boerKrelis wrote:*   

> But it's not coming from the router. Host keys are something internal to the SSH server you're connecting to. It usually lives in /etc/ssh/ssh_host_rsa_key and you can get its fingerprint by running 'ssh-keygen -l -f' on it. Thankfully, it doesn't matter which route the packets take.

 

Sorry, I misread you. Notice, I wasn't talking about encapsulation, I was talking about packet mangling. If you actually change the source field in the packets, then the packets will really seem to be coming from the router (containing keys that shouldn't be coming from the router).

I agree that encapsulation is not a problem.

----------

## boerKrelis

And I seem to have misread you ;-)

Changing the source field in the packets would break the TCP connection on the OS level, I think. The packets will never even reach the application layer (SSH). It can be done, but then the router would have to recompute the checksum and do some other stuff. That's 'source NAT' and I don't think that that breaks SSH, as the TCP layer should be valid (what's the point of SNAT otherwhise, I'm thinking, but I'd have to dig into some books if I'd want to be 100% sure).

----------

## pianosaurus

 *boerKrelis wrote:*   

> And I seem to have misread you 
> 
> Changing the source field in the packets would break the TCP connection on the OS level, I think. The packets will never even reach the application layer (SSH). It can be done, but then the router would have to recompute the checksum and do some other stuff. That's 'source NAT' and I don't think that that breaks SSH, as the TCP layer should be valid (what's the point of SNAT otherwhise, I'm thinking, but I'd have to dig into some books if I'd want to be 100% sure).

 

The linux kernel for example has the packet mangling facilities to change packets without breaking them, so the TCP layer should not be a problem. I'm more worried about how SSH would handle the inconsistencies between packet headers and packet data. Not that it matters. It is a bad way of doing it at any rate.

@sorcerer25: Look into the source policy routing that boerKrelis mentioned. I think that's your solution.

----------

