I am running a TURN server (http://tools.ietf.org/html/rfc5766) on a server that is behind a firewall. The machine has a public IP address where incoming and outgoing network packets are sent to/from the server’s private IP address. Basically, the server cannot bind sockets to the public IP address, only the private IP address. Running ifconfig shows the network device having a private IP address.
When I run the TURN server, I have to bind to the private IP address (since the server doesn’t think it is connected to the public Internet). All responses to allocation creations send back the XOR-RELAYED-ADDRESS with the private IP address. Clients receive the XOR-RELAYED-ADDRESS and send data to the server’s private IP address, which clearly fails.
There are two options I am considering to overcome this:
- Have my client code ignore the IP address of the XOR-RELAYED-ADDRESS and only use the port of XOR-RELAYED-ADDRESS. Clients will send all relayed messages to the TURN server’s public IP (since the client already knows this value beforehand) and the XOR-RELAYED-ADDRESS port.
- Alter my server to know about its public IP (even though it can’t bind sockets to it), and always send back the public IP in XOR-RELAYED-ADDRESS responses.
I feel like the first method breaks the TURN RFC…even though I can’t imaging a situation where the TURN server would send back the IP of XOR-RELAYED-ADDRESS as something other than the TURN server’s public IP, the RFC says that the XOR-RELAYED-ADDRESS is what clients should be sending data to.
I feel like the second method breaks the RFC less…if that makes sense. Furthermore, this method doesn’t force clients to do anything special, whereas the first method needs all clients to abide by the above.
What do you think about this? Has anyone experienced this, and/or have any opinion on which method breaks the RFC less, or if the RFC is even violated by either method?
I have nearly the same exact problem running my STUN server code on Amazon EC2. The origin address and the alternate address returned by the stun server to the client are NAT’d IP addresses.
Some solutions I have thought about:
Just assume clients are pre-configured to know the alternate IP address if they actually want to do the additional NAT type detection tests. This is not a bad assumption to make for STUN. After all, they are expected to know the primary IP address of the stun service.
Modify the server code to be passed it’s mapped IP addresses from the command line or config file. This is equivalent to your second method described above. I could have the server self-discover it’s own external IP address via a web request (or test another stun server) when it starts up to make this automatic.
Your first proposal – clients are aware of the IP mapping – is perfectly fine assuming you aren’t trying to interop with other clients other than your own. But if you think you’ll have a need to use someone else’s client stack, then this option becomes less desirable. You could do a hybrid approach – invent a new custom attribute for TURN Allocate responses that your client understands to mean, “ignore relay IP, just assume the port is correct”. This is OK, but not great.
Your second proposal is more in line with my #2 above. There’s one other thing to think about. What happens if your clients are also behind the same firewall as your TURN server? Do you want the internal address or the external? Then again, if both your clients are behind the same firewall, they likely won’t need TURN to communicate. The other issue is just the administration overhead of passing the right IP address to the server.
I like your second proposal.
You could consider posting a question to the BEHAVE IETF email discussion group. They are the open committee that drafted the STUN and TURN specs. I think they should be aware that servers in the cloud running behind NATs are becoming increasingly common. They may have some advice. I would be keenly interested in joint authoring this email with you. Or at least reading their response.