VOIP, NATting, routers, trigger ports, private IPs, and bears, oh my!

Factual Questions
1

I’ve got a pair of voice-over-IP boxes. You can plug an analog phone into them, and you get a dial tone; you can program numbers to dial, and associate them with external IP addresses. If used on an internal network, you get very high-quality voice communication - indistinguishable from telephones.

Now I’d like to use these two boxes between two locations.

Here’s where things get tricky.

At one location, I have a pretty standard home set-up: a NATting firewall/router that gets a public IP address from the ISP (66.x.x.x) , and has a private IP on the back end (192.168.x.x.)

Fortunately, my router here permits both trigger ports and a DMZ. So I can figure out what IP ports the VOIP device uses, and set my router to direct traffic on those ports to the VOIP device. Indeed, I could even define the VOIP device as my DMZ machine (all incoming traffic goes there) since I’m not worried about anything like an undiscovered RPC vulnerability on a box that’s not really running an OS in the traditional sense.

If the other side looked like that, then this post would not be written.

The other side of the equation ALMOST looks like that. It, too, has an ISP and a NATting firewall/router. But here’s the catch: the IP address assigned to the public side of that router by that ISP is 10.x.x.x! In other words, the ISP is handing out private IPs, and IT is doing some address translation somewhere down the line.

So I’m flummoxed. I can’t tell the ISP to set up trigger ports to me. I can’t capture incoming traffic.

So my thoughts turn to setting up some sort of VPN/tunnelling system.

How can I do this?

2

Any chance of talking that remote ISP into giving a more traditional IP?

3

No. For one thing, they speak only Spanish. For another, they don’t do that. They apparently have a single Class C address, and more than 253 customers. :slight_smile:

4

OK, until 9 months ago this was my job – now I discover I barely remember any of it. As you’ve discovered this is one of the major issues with VoIP – it gets screwed by NAT.

I’m afraid I think you might be screwed.

You need to work out what public IP/port is being mapped to your phone. Now this should be possible (you can use a protocol called STUN, which discovers the mapped IP/port through some cleverness). Hopefully you can enable this on your phone/device (or it may have some other type of NAT traversal option). These typically only work across one NAT step.

Now you should be able to dial out from that phone to the other (or anywhere else) , and it’ll tell the called phone the current mapped public IP. Hence you’ll get a call setup that way. If you can get access to the data for this call you should be able to find the IP/port combination the phone provided.

The problem, of course, is calling to the NAT’d phone. Even if you used something to discover it’s public IP/port at any given time you’ve no way of knowing if it’ll stay the same.

The way round that is to have your phones connect to a central server, then each phone contacts the server to be redirected to the other. This complicates your previously simple situation – and probably costs you money.

This is probably the way to go, but VPNs are a bit out of my expertise. I don’t know off hand if you’ll be able to make it work since you still don’t have access to a public IP on one side of the network.

You’re going to need VPN cabaple hardware on each side of the network, so either a VPN router or a machine running VPN software (either 3rd party, or from it’s OS). Anytime I’ve looked at VPNs I’ve decided it’s more effort than it was worth and that there was another way.

Hopefully someone can chime in with more on VPNs.

If you didn’t mind using a USB handset connected to a PC I’d suggest getting Skype and using that. It pretty much ‘just works’ (like it says) for this sort of thing. But I guess you want the to have real phones and not have a computer running to make your calls.

Finally, just for completeness, I’ll note that although you’re probably right about the device being safe on a public IP it’s not a 100% certainty. A lot of these devices are basically just running cut down versions of Linux, and some aren’t even that cut down. They aren’t popular enough yet for anyone to be seriously trying to exploit them, but I’d be surprised if there weren’t exploits possible and I’d wager that they’ll crop up in time. I should note that I’ve been saying that for a year or so now, but still …

Hopefully some of that helps, or at least the bump gets you some more answers.

SD

5

Your ISP is dishing out network 10 addresses? Are you in a rented office unit in a managed complex or something?

6

No, I’m a client of Codetel, an ISP in the Dominican Republic.

I’m hoping someone can recommend a VPN solution.

7

So no one on your Codetel ISP can play any peer-to-peer games?

8

Unless it’s with each other across the 10. network… correct.

9

Or unless a one-way connection is sufficient to let the game work, I guess.