This TURN server implementation cannot work behind NAT

[GoogleCodeExporter]

This is not an error or bug but a capability being added to other TURN server 
implementations so that they can be hosted on cloud services such as AWS which 
only offer NAT and not public IPs. 

This can be achieved by creating a config parameter for external_IP which is 
the set to the outside address of the NAT. This address must have port 
forwarding to a valid listening address:port for the rfc5766turnserver. 
Responses to STUN and TURN requests are then formulated using the external_IP 
override rather than the native address of the listening interface.

Would you consider this enhancement to your very good TURN solution. 

Thanks,

Warren      

Original issue reported on code.google.com by warren.m...@gmail.com on 28 Jan 2013 at 3:33

[GoogleCodeExporter]

Thanks for reporting a possible enhancement. I suppose that I can do it, soon.

Oleg

Original comment by mom040...@gmail.com on 28 Jan 2013 at 6:19

• Changed state: Accepted

[GoogleCodeExporter]

I added -X or --external-ip option to define a SINGLE "external" IP address 
that will be used in XOR-RELAYED-ADDRESS response attribute. If the external 
address is not defined, then it works as before.

Original comment by mom040...@gmail.com on 28 Jan 2013 at 8:43

• Changed state: Fixed

[GoogleCodeExporter]

What an amazing turn around time.

Thank you I will try very soon.

Warren  

Original comment by warren.m...@gmail.com on 28 Jan 2013 at 8:46

[GoogleCodeExporter]

It was a simple minor change :)

Thanks for reporting

Original comment by mom040...@gmail.com on 28 Jan 2013 at 8:48

[GoogleCodeExporter]

I mentioned this feature on webrtc Google groups thread and it seems it is 
failing tests from Chrome.

See 
https://groups.google.com/forum/?fromgroups=#!topic/discuss-webrtc/ukNUoHeWm2I
for discussion relating to testing of this feature. Someone is suggesting it is 
failing a hash check. 

Cheers,

Warren

Original comment by warren.m...@gmail.com on 30 Jan 2013 at 2:56

[GoogleCodeExporter]

I am already familiar with the issue. The guy who is running it is not
using the correct command line, he forgot to use authentication.

Original comment by mom040...@gmail.com on 30 Jan 2013 at 3:00

[GoogleCodeExporter]

Comments from Jesse (he resolved the problem):

=======================================================

For anyone that runs into a similar problem in the future, it looks like you 
have to explicitly turn on fingerprinting and message integrity in the 
turnserver command line or it doesn't add HMACs and fingerprints to relay 
requests ... In any case, this is the command line that did the trick:

turnserver -o -X 23.23.238.173 --no-tls --no-dtls -a -b turnuserdb.conf -f -r 
myrealm

Original comment by mom040...@gmail.com on 30 Jan 2013 at 5:18

[GoogleCodeExporter]

how to config turnserver behind fireware(NAT) to implement RFC5780-NAT behavior 
discovery ?

Fireware has two public ip addresses, turnserver has two priviate ip addresses.

thx.

Original comment by lin...@126.com on 14 May 2013 at 2:14

[GoogleCodeExporter]

Working behind NAT is a special case and some functionality, like RFC5780, is 
not supported right now. To support that, we have to implement some kind of 
one-to-one address mapping. Please file an Enhancement Issue and I'll fix it 
later.

Original comment by mom040...@gmail.com on 14 May 2013 at 5:18

[GoogleCodeExporter]

I filed a related Issue 25.

Original comment by mom040...@gmail.com on 14 May 2013 at 3:57

[GoogleCodeExporter]

The new 1.8.4.1. version supports RFC5780 behind NAT. You will have to start 
the TURN server as following:

 $ turnserver ... -X <public-ip-1>/<private-ip-1> -X <public-ip-2>/<private-ip-2> ...

You can find more information in the documentation. Let me know how it works.

Original comment by mom040...@gmail.com on 14 May 2013 at 10:57

[GoogleCodeExporter]

@mom040 
thank for rapid response to RFC5780 issue behind NAT.
-X <public-ip-1>/<private-ip-1> is worked for me.

thx.

Original comment by lin...@126.com on 17 May 2013 at 2:53