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 is accessed via an iPhone or other device portable device. So, the devices connecting to the server could come from any number of IP addresses.

The problem comes with the installation. When we install this service, it seems to always become a problem when doing port forwarding so the outside world can gain access to tomcat. It seems most time the owner doesn't know router password, etc, etc.

I am trying to research other ways we can accomplish this. I've come up with the following and would like to hear other thoughts on the topic.

1. Setup a SSH tunnel from each client office to a central server. Basically the remote devices would connect to that central server on a port and that traffic would be tunneled back to Tomcat in the office. Seems kind of redundant to have SSH and then SSL, but really no other way to accomplish it since end-to-end I need SSL (from device to office). Not sure of performance implications here, but I know it would work. Would need to monitor the tunnel and bring it back up if it goes done, would need to handle SSH key exchanges, etc.

2. Setup uPNP to try and configure the hole for me. Would likely work most of the time, but uPNP isn't guaranteed to be turned on. May be a good next step.

3. Come up with some type of NAT transversal scheme. I'm just not familiar with these and uncertain of how they exactly work. We have access to a centralized server which is required for the authentication if that makes it any easier.

What else should I be looking at to get this accomplished?

Answer 1

Is there no way this service can by hosted publicly by you or a hosting provider rather than with the customer?

I had a similar situation when I was developing kiosks. I never knew what type of network environment I'd have to deal with on the next installation.

I ended up creating a PPTP VPN to allow all the kiosks to connect to one server I hosted publicly. We then created a controller web service to expose access to the kiosks that were all connected via the VPN. I'm not sure how familiar you are with VPN's but with the VPN connection I was able to completely circumvent the firewall in front of each kiosk by accessing the kiosk via the VPN assigned IP.

Each kiosk node was incredibly easy to setup once I had a VPN server setup. It also brought management benefits and licensing revenue I originally didn't think about. with this infrastructure I was easily able to roll out services accessible via mobile phones.

Best of luck!

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.