26 May 08 Split access SSH problems

So far everything works flawlessly, all applications, protocols and service with the split access setup, but I have a strange bug with SSH, and it only affects SSH clients built on openssl, such as dropbear and openssh. After authentication, it just hangs, and running in verbose mode shows that it seems to fail upon attempting to resize the tcp window. Only fails occasionally, when it receives no acknowledgement from the server.

After much digging, I only had minimal success getting to the bottom of the issue, but the following hack fixed the issue:

What we do here, is mark all outgoing SSH packets with a mark of ‘22′, and then add a rule forcing all packets marked with ‘22′ out through table 2 (provider 2), which can just as easily be replaced with table 1 if you wish. This technically breaks the split access concept as SSH is now forced out over one connection only, but everything else is still working correctly.

One might assume that as this resolves the issue, some packet is ending up lost down the wrong connection but this is not the case. The routes are cached, and all traffic on an established connection will flow over the same route, it is something to do with the request to resize the tcp window which never gets acknowledged.

I’m pretty sure I’ve discovered a bug somewhere, and would welcome any advice on who to report it to.

It affects openwrt running tc/iproute2 on a mikrotik routerboard 532a when acting as a router for LAN clients trying to make outbound SSH connections but only with SSH clients built on openssl. lol.

Tags: cached routes, dropbear, iproute2, iptables, openssh, openssl, routes, split access, ssh, tcp window

Reader's Comments

1. adam | 27 May 2008 10:06 am

   On further research, the issue seems have been found by other users, which seems to limit it down to using iproute2 with multiple providers and SSH which passes the FORWARD chain in iptables.

Leave a Comment