controlling a linux box behind a router

I am trying to make it possible to control a shell on a linux box behind a router which is not under my control.

My first idea was to make the client (the box behind the router) to ssh to a server under my control and forward the local ssh port, periodically from cron, like this:

client$ ssh -L 40000:localhost:22 root@server

It works with my private, less secure server, but fails with the customers server, which is a grsecurity hardened CentOS, 2.6.24.5-grsec-xxxx-grs-ipv4-32 ([email protected]). I do not know a thing about grsecurity and particularly not about how it is configured on this server. The AllowTCPForwarding option is sshd_config is on its default, which is supposedly(as of RTFM) 'yes', and ssh -v tells me

debug1: Local connections to LOCALHOST:40000 forwarded to remote address localhost:22
debug1: Local forwarding listening on 127.0.0.1 port 40000.

but all I get when trying to ssh back to client from this server is 'Connection refused'.

Next idea:
On client:

client$ bash -i <in >out 2>err &
client$ ssh root@server 'cat <client.in' >in &
client$ ssh root@server 'cat >client.out' <out &
client$ ssh root@server 'cat >client.err' <err &

On server:

server# cat client.out &
server# cat client.err &
server# cat >client.in
ls

All of these, {client.,}{in,out,err}, are named pipes, made with mkfifo. But somehow the ssh does not work this way for me, nothing ever gets over net. This works partially with normal files (not named pipes) and tail -f. But than I have the feeling this is not how you accomplish this. And the worries about plain files getting too big, and overwriting... it just does not seem pretty.

Any ideas? I have root on customers server, but would prefer not to install kernels and wreak havoc.

UPDATE

Clarification: The client box will be installed by the customer on some distant location behind a router, of which neither I nor the customer has control. So, no port forwarding or dynamic DNS on the router. Just a plain linux box with a private IP somewhere on the net. The first idea I pictured would work out with a server less secure than the customers server. I am supposed to use the grsecured one. I am able to ssh from the customers grsecured server to other locations, so it is not an iptables problem. I am also able to open listening ports (with nc -l) and to connect to them.

I am connecting from the client behind a router to the server, forwarding some high server port (e.g. 40000) to the ssh port on the client, so I can first ssh from home to the server an then ssh from the server to the client. As i said, the client is not in my network and is behind a router which is not under my control.

I am not ssh'ing back home, the client is not the machine I start this wonderful journey from. Home, server and client are on three distinct networks.