# tunnel over high latency link



## ericx (May 13, 2016)

We're trying to establish and maintain some sort of tunnel from a ship at sea over a high latency satellite link. Several satellite links are in use simultaneously. Bandwidth and latency vary considerably depending on the vendor in use and the position of the ship (this is an R/V; so the ship is just as likely to steam off the New Jersey shore as the Antarctic Ocean). We have seen ground-station round trip times as high as 2000 msec (way higher than the propagation time to even a geosynchronous comm sat).

There is currently an appliance in place attempting to maintain a link back to an identical appliance at the research facility. The appliance is a black box; so we've had to infer most of what we know. But by tapping the ethernet, it's apparent that it is using an ESP tunnel within UDP encapsulation (NAT-T). The appliance is not designed for the high latency and routinely times out and disconnects even tho we are using a null cipher.

If I were to replace the appliance with FreeBSD (probably pfSense), how would I increase the default ESP timeout?

What sort of counter-indications should I watch for? i.e.: what am I going to break if I crank this number way up?

Is this simply a bad idea?


----------



## tingo (May 14, 2016)

High latency links requires protocols that are suited for that. In effect; ssh might work, VNC isn't going to work.
If you are just trying to "insert" two FreeBSD boxes as routers in the link I don't think that is going to work, your black box appliance is still going to timeout.


----------

