This TURN server implementation cannot work behind NAT about rfc5766-turn-server HOT 12 CLOSED

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

Oleg

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.

What an amazing turn around time.

Thank you I will try very soon.

Warren  

It was a simple minor change :)

Thanks for reporting

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

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.

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

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.

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.

I filed a related Issue 25.

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.

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

thx.