ssh point-to-point tunnel blocked

As many knows the following things work:

1. port-to-port forwarding eg. for web browsing

ssh linode -ND:8000

2. layer 2 routing using tap1 device used eg. in bridging

sudo ssh linoderoot -w 1:1 -o tunnel=ethernet

However this does not work:

3a. layer 3 tunnel using tun3 device

sudo ssh linoderoot -w 3:3 -o tunnel=point-to-point 'ifconfig tun3 10.0.4.1 netmask 255.255.255.0 up; read'

3b. on local machine in other terminal quickly:

sudo ifconfig tun3 10.0.4.2 netmask 255.255.255.0 up

3c. on local machine, now do ping until it fails, it will work for less than one minute

ping -c1 -W1 10.0.4.1

  • Some sort of firewall starts blocking the packets after a few seconds to a minute

  • No debug output indicates a lost connection on ssh or sshd sides, so it is packet blocking.

  • No ssh keepalive feature maintains a working tunnel

Why is this important?

Some appliance hardware do layer 3.

Any suggestions from the general public?

2 Replies

You should make sure the SSH connection is still working. It seems likely that NAT between you and your Linode is forgetting about the connection, and so everything stops working. I'd remove the command, and just bring the tunnel addresses up by hand after logging in, and then start your ping; when it fails, go back to the SSH connection, and see if you can type anything. If you can't, then NAT between you and your Linode forgot about the connection, and dropped it. All traffic flowing over an SSH connection, including tunnels and port forwarding is encrypted, so it would be impossible for any stateful firewall to determine that you're doing layer 3 tunneling through your SSH connection and block only that traffic.

-Doug

I got this working via Amazon.

I rewrote in accordance with the suggestion, so a main scripts a first check arguments, then forks script b and ends with a regular ssh connection.

script b waits for interface to show up first local where it configures, then the same on remote. It ends with forking again so both ends of the tunnel pings the other. If you start pinging before the tunnel is up at both ends, you're trouble. The local machine has a separate routing table so its other network card can be used independently from this tunnel, even get routed back through its second network card.

This way I can pick what box or phone gets true ip or tunneled ip using my dhcp server.

I presently have two local network cards, a software bridge and nat at the far end. I can probably get rid of the second network card since the bridge has its own mac.

It works now. I will simplify and port back to Linode whenever.

Thanks for your suggestions!

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct