[plug] Routing with nonat - ssh tunnel and port forwarding

[Daniel Pittman]

Carl Gherardi <carl.gherardi at gmail.com> writes:

>> For simply tunnelling the IP traffic across the network you can
>> create a tunnel trivially, with either IP-in-IP or GRE, on Linux,
>> without a problem.

[...]

> Thanks for this. I found ssh -w last night and that seemed
> appropriate.

Woah!  No, it isn't, in almost any circumstances.  That passes your
traffic over the ssh link, which is a reliable TCP connection.

You absolutely do *NOT* want to run a reliable protocol, including TCP
or UDP-with-retries, over a TCP link, because you *will* end up with
problems.


Specifically, what happens is that when a packet is lost the outside
TCP connection ensures it is retransmitted ... but, so too does the
inner connection.

This means that you now have *two* packets that need to get through,
increasing network load and making the loss of another packet more
likely.

Of course, that retransmitted packet *also* gets duplicated, so you
very, very rapidly get to the state where the time taken to send all
those duplicate frames is enough that *all* inner packets are duplicated
and, boom, no more like.


Don't do that!  It *is* going to hurt.  Use a real tunnel of some sort,
where the outer layer is in IP, GRE or UDP, so you only have *one*
retransmission timer running.

> I've had problems stacking the additional tun device on the existing
> vpnc connection (which is how i'm hopping the broken equip in 1
> direction)

Unless you absolutely need to work with a Cisco device at the far end,
and I presume you do, then you would be better using a different VPN
solution such as OpenVPN.

...um, and if you already have a tunnel why can't you just use that?


>> and that PMTU discovery is enabled on your application servers, or
>> manually configure their MTU.
>
> Need to look this up.

It /should/ be enabled by default on anything vaguely modern.


>> Footnotes:
>> [1]  ...well, personally I would make the life of whoever owned the
>>     faulty device in the middle hell until they fixed their problem, so
>>     that I didn't have to work around it, since it saves work in the
>>     long run, but if you can't do that then you are correct... ;)
>
> The broken peice of equipment is 'no line installed', which we are on
> but is going to take longer than acceptable.

*nod*  Well, at least you don't have to look forward to the workarounds
forever, I guess. :)

Regards,
        Daniel