4

I have a server that reverse ssh tunnels to a secondary server. The secondary server then acts as a "bridge" to the internal server (the external server's IP address is what I connect to).

This works fine for most services (files, ssh, etc.) but doesn't work for an L2TP VPN. I've tunneled ports 500 and 4500. But what's got me stymied is "ESP value 50“ which is apparently required for L2TP. How do I tunnel this to complete the VPN data path?

Or if this isn't the problem, what would be causing the VPN to not connect under a reverse tunnel?

jstm88
  • 747
  • 2
  • 9
  • 21

1 Answers1

3

Encapsulating Security Protocol (ESP) is IP protocol 50. It has a protocol number in its own right, just as ICMP, TCP and UDP do, and is arguably the right protocol to use for encrypted tunnels.

However, although TCP and UDP have both ip addresses and port numbers associated with both source and destination, ICMP and ESP don't. It's the combination of ports and addresses that make NAT and tunneling practical; without them, traffic is very difficult to handle.

The problem is that, when a tunneling (or NAT) device has two or more input UDP streams to pass on to a single endpoint, and the responses come back from that endpoint to the tunneling device, the source port numbers can be used to disambiguate the two streams. With ESP, there is no port number to serve as disambiguator, so it's hard for the tunneling endpoint to know which of several ESP sources that ESP response should be tunneled back to.

IPSec, which by default also uses ESP, some time ago codified the NAT-traversal extensions, which use UDP/4500 instead. I don't know that L2TP has such a mode, and without it, I fear you won't be able to do what you want to do.

I hope I'm wrong about that, and that someone else will come along and post a better answer. But in the absence of that, I thought I should at least try to explain what ESP is, and why it is a tunneling headache.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • This makes sense, although it doesn't help much. Although it may be a bad idea (let's assume for now that I understand and accept the risks) is it possible to reverse-forward _all_ ESP traffic and assume the endpoint server just won't use it at all? The only alternative is a different VPN, and that's not possible for various reasons. – jstm88 Dec 16 '13 at 19:44
  • Not via ssh, as far as I know, no; via `iptables`, yes. But that's still no help to you. – MadHatter Dec 17 '13 at 00:01
  • And as a further insult, the VPS that I'm tunneling through doesn't support iptables _or_ IPSec (which is exactly why I'm running the VPN on another server). – jstm88 Dec 17 '13 at 02:13
  • Then why not run a VPN you can tunnel? – MadHatter Dec 17 '13 at 08:02
  • Which ones are available that you can connect to natively (NO 3rd party apps) from Mac _and_ iOS devices? L2TP/IPSec, PPTP, and Cisco IPSec are the only options. PPTP is not an option because it's been compromised, and Mac OS X Server supports L2TP which is why I'm using it. – jstm88 Dec 17 '13 at 17:25
  • You do know that product recommendations are explicitly off-topic on SF (and all SE sites), don't you? Moreover, I'm no mac expert. If you require to use one, and refuse third-party apps, you may have just set yourself an insoluble problem. – MadHatter Dec 17 '13 at 19:32
  • It's more of a rhetorical question (because there are none that I'm aware of). Cisco is paid, PPTP is compromised, and L2TP can't be tunneled. I'm still interested in a way to tunnel ESP over the reverse tunnel (even if it's just tunneling everything and preventing the intermediate server from using ESP) but it doesn't seem like there's an easy way. Probably the most robust way to do it would be to build a custom application to emulate the actual network hardware and pass it through in real time, but that's probably beyond the scope of this question. :D – jstm88 Dec 17 '13 at 19:46