How to access a web service behind a NAT?

Question

We have a product we are deploying to some small businesses. It is basically a RESTful API over SSL using Tomcat. This is installed on the server in the small business and i

Answer 1

I had to do something similar in the past and I believe the best option is the first one you proposed.

You can do in the easy way, using ssh with its -R option, using publick key auth and a couple of scripts to check for connectivity. Don't forget the various keep alive and timeout features of ssh.

Don't worry about the performances. Use unprivileged users and ports if you can. Don't bother to setup a CA, the public key of each remote server is easier to maintain unless you are in the thousands.

Monitoring is quite simple. Each server should test the service on the central server. If it fails either the tunnel is down or there's no connectivity. Restarting the tunnel will not harm in any case.

Or you can do it at the network level, using IPsec (strongswan). This can be trickier to setup and it's the option I used but I will use SSH the next time, it would have saved me a lot of time.

Answer 2

Solutions exist to "dynamically" access a software on a computer behind a NAT, but usually mostly for UDP communication.

The UDP hole punching technique is one of them. However, this isn't guranteed to work in every possible situation. If both sides of the communication are behind a "Symmetric Cone NAT" it won't.

You obivously can reduce the probability a client can't communicate using UPnP as a backup (or even primary) alternative.

I don't know Web Services enough and don't even know if using UDP for your webservice is an option (or if it is even possible).

Using the same technique for directly TCP is likely to fail (TCP connections aren't stateless - that causes a lot of problems here).

An alternative using the same technique, would be to set up some VPN based on UDP (just like OpenVPN), but as you stated, you'll have to manage keys, certificates, and so on. This can be automated (I did it) but still, it's not really trivial.

===EDIT===

If you really want to use TCP, you could create a simple "proxy" software on the client boxes which would serve as a relay.

You would have the following schema:

1. Web Service on client boxes, behind a NAT
2. The "proxy" software on the same boxes, establishing an outgoing (thus non-blocked) TCP connection to your company servers
3. Your company servers host a WebService as well, which requires a something like a "Client Identifier" to redirect the request to the adequate established TCP connection.
4. The proxy program interrogates the local WebService and send back the response to the company servers, which relay the response to the originate requester as well.

An alternative: you might ask the proxy software to directly connect to the requester to enhance performance, but then you might encounter the same NAT problems you're trying to avoid.