How to use UDP hole punching for a SSH tunnel / session

Question

I want to deploy a Raspberry Pi in my weekend cottage. The Raspberry Pi is there to log the temperatures and send them to a remote server which has a fixed ip, saves the data and displays it on a simple website.

However the situation may arise that I want to change something on the Raspberry Pi. For example system updates or a change on the program which sends the data to the server or whatever.

With the proposed setup I wouldn’t be able to connect to the Raspberry Pi from outside of it’s LAN.

NOTE: I do not want to change the network, and the existing router doesn’t have the ability for port forwarding, dynDNS or VPN.

I recently read over UDP hole punching. The basic idea is, that the client sends a UDP Package to a known server address (i. e. with a public IP or dynDNS enabled). Client B which would want to connect to client A asks the server for the public IP and Port number of client A.

It then can connect to client A directly on it’s public IP and port which is dynamic. Because client A first connected to the server on the now used port, the NAT will forward the packages to client A.

I hope I summarized the idea correctly, more or less…

This all sounds nice, but the problem is, that this is not quaranteed to work with a TCP connection, as the router is able to “understand” the handshake of the TCP connection and if it is not built up correctly, it will not forward the packages.

So, how can I open a SSH Session from client B to client A, without client A sitting behind a router with dynDNS, a fix public IP or the ability for port forwarding? The usage of a central server with a public, fix IP or domain name would be possible tough.

Solution 1

pwnat

---

"..it is not trivial to initiate a connection to a peer behind NAT."

"..almost all NAT implementations refuse to forward inbound traffic that doesn't correspond to a recent matching outbound request."

---

"..The pwnat tool is a GNU/Linux-only, stand-alone implementation of autonomous NAT traversal. After contacting the server behind the NAT, it establishes a channel with TCP semantics, using UDP packets. It supports both client and server behind NAT (if one of the NATs allows the fake [custom] ICMP messages to be transmitted). This implementation targets end-users."

---

  
usage: ./pwnat <-s | -c> <args>

  -c    client mode
    <args>: [local ip] <local port> <proxy host> [proxy port (def:2222)] <remote host> <remote port>

  -s    server mode
    <args>: [local ip] [proxy port (def:2222)] [[allowed host]:[allowed port] ...]

  -6    use IPv6  
  -v    show debug output (up to 2)  
  -h    show help and exit  

Examples:  

    Server side allowing anyone to proxy:
      ./pwnat -s

    Client wanting to connect to google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Then, browse to http://localhost:8000 to visit the google!  

---

---

"The key idea for enabling the server to learn the client’s IP address is for the server to periodically send a message to a fixed, known IP address. The simplest approach uses ICMP ECHO REQUEST messages to an unallocated IP address, such as 1.2.3.4. Since 1.2.3.4 is not allocated, the ICMP REQUEST won't be routed by routers without a default route."

"As a result of the messages sent to 1.2.3.4, the NAT will enable routing of replies, in response to this request. The connecting client will then fake such a reply. Specifically, the client will transmit an ICMP message indicating TTL_EXPIRED. Such a message could legitimately be transmitted by any Internet router and the sender address is not expected to match the server’s target IP."

"The server listens for (fake) ICMP replies and upon receipt, initiates a connection to the sender IP specified in the ICMP reply. If the client is using a globally routable IP address, this is entirely unproblematic and both TCP or UDP can be used to establish a bi-directional connection if the client listens on a pre-agreed port."

"(In cases where there is no pre-agreed port, a port number can in most cases be communicated as part of the payload of the ICMP ECHO RESPONSE)."

---

Source: http://samy.pl/pwnat.pdf
https://github.com/samyk/pwnat

Solution 2

Here is a couple of solutions:

You can setup your Raspberry Pi to connect back to an OpenVPN server and you will have access to it all the time.

You can take a look at PageKite. Check https://pagekite.net/wiki/Howto/SshOverPageKite/

Comments

[cpt_fink]

You have an internet facing device that is capable of UDP hole-punching but not TCP? Get a better NAT device.

[barlop]

I haevn't done ssh with udp but here is a link on it zarb.org/~gc/html/udp-in-ssh-tunneling.html

[barlop]

I don't know but I asked an ssh guru, they said ssh can forward udp, but only if it acts like a vpn, and there is a switch for it , he said it's -w but he said udp over tcp (perhaps by that he includes any attempt to forward udp with ssh), involves issues such as high latency, and retransmits of stuff you don't want anymore. I guess it's still an interesting thing to try though. I see this vpn via ssh and -w mentioned here too wiki.archlinux.org/index.php/VPN_over_SSH

[kabadisha]

I'm curious as to why you don't want to open an inbound port? - this doesn't sound like a scenario that requires super awesome security... Alternatively, you could have client A maintain an outbound SSH connection with a reverse port binding to a server that client B has access to. That way you can connect via the middle-man server. However, these sorts of arrangements are prone to failure and so are pretty undesirable given limited physical access to sort it out when it goes wrong.

[voices]

How does this relate to "UDP hole-punching" ?

[voices]

How does this relate to "UDP hole-punching" ?

[ZEE]

?how does this traverse NAT ??

[Him]

pwnat is barely functional for even localhost to localhost connections. I can send and receive some packets, but for establishing robust connections it is not very useful.

[voices]

@Scott Well, it's an interesting hack, but it's really just a proof of concept based on the misuse and abuse of network protocols like ICMP. I wouldn't rely on it. It's old and unmaintained and I wouldn't recommend using it. I wouldn't have even mentioned it if the question didn't specifically stipulate UDP holepunching. If you want reliable, hook up a VPN tunnel.

[Him]

I'm not complaining, but I think that "this solution is not for use in a production environment" is useful information for anyone coming here looking for a potentially stable solution.

[voices]

@Scott It's not, not for use in such and such an environment. Plenty of proprietary products employ thesez techniques. Anyway, there's enough information here for people to make their own decisions. I don't recommend it. But I use VPN tunnels. On the other hand, some networks filter VPN traffic, so you kind of have to take things on a case by case basis. Do you need help getting through a NAT router?

[Him]

I have a currently workable solution using reverse ssh tunnels to link two NAT'd machines. However, it requires a "middleman" machine that either has a static IP or for whom I can configure port forwarding on the router. This would have enabled me to cut out that middleman. Oh well.

[voices]

@Scott who's your service provider

[Him]

Arbitrary coffee shop, or sometimes open university network. :)

[Leo]

I'm a little confused. Does the pwnat server need a public IP?

[voices]

@Scott so, let 1.2.3.4 be your middleman.

[voices]

@Chad Well, it depends, but in the example shown: "The key idea for enabling the server to learn the client’s IP address is for the server to periodically send a message to a fixed, known IP address." Client is on the left (Non-NAT). Server is on the right (NAT). "The connecting client will then fake such a reply." The diagram is arguably backwards. Read it from right to left.