What I am trying to do is create a test script (javascript) to check if a client can connect via "server reflexive candidates".

I copied the script from test.webrtc where it basically creates two peers and send some text via data channel and check if both sides receive the text or not.

The problem I am getting is that my "ice connection state" will changed from "checking" to "failed".

I know my browser (chrome) can connect via "server reflexive candidates" and we are not using Symmetric NAT.

I know under normal circumstances when both clients are in the same LAN they will almost always connect via "host candidates" (sometimes via relay candidates, not sure why)

The only reason I am "forcing" it to connect via "server reflexive candidates" because I want to create a test script, so that our users can self-check what connection candidates their browsers are capable of.

The connection scenario can be described like below:

Client A Source - Local IP - 192.168.1.142 - Source Port - 52245 Client A Destination - Remote IP - 99.99.99.99 - Destination Port - 43353

Client B Source - Local IP - 192.168.1.110 - Source Port - 43353 Client B Destination - Remote IP - 99.99.99.99 - Destination Port - 52245

When using "netstat" in my router I get the following:

Proto Source Address                      Destination Address              State 
udp   192.168.1.142:52245                 99.99.99.99:43353                UNREPLIED   
udp   192.168.1.110:43353                 99.99.99.99:52245                UNREPLIED  

I am not sure if this is something to do with router behaviour and I don't see any settings related to the above in router admin console, so I have changed to different routers and I still get the same results described. Is it because connection like above is not permitted?

[EDIT - Include route table]

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
99.99.99.254    *               255.255.255.255 UH    0      0        0 WAN
99.99.99.0      *               255.255.255.0   U     0      0        0 WAN
192.168.1.0     *               255.255.255.0   U     0      0        0 LAN
default         99.99.99.254    0.0.0.0         UG    0      0        0 WAN

What I am trying to do is create a test script (javascript) to check if a client can connect via "server reflexive candidates".

I copied the script from test.webrtc where it basically creates two peers and send some text via data channel and check if both sides receive the text or not.

The problem I am getting is that my "ice connection state" will changed from "checking" to "failed".

I know my browser (chrome) can connect via "server reflexive candidates" and we are not using Symmetric NAT.

I know under normal circumstances when both clients are in the same LAN they will almost always connect via "host candidates" (sometimes via relay candidates, not sure why)

The only reason I am "forcing" it to connect via "server reflexive candidates" because I want to create a test script, so that our users can self-check what connection candidates their browsers are capable of.

The connection scenario can be described like below:

Client A Source - Local IP - 192.168.1.142 - Source Port - 52245 Client A Destination - Remote IP - 99.99.99.99 - Destination Port - 43353

Client B Source - Local IP - 192.168.1.110 - Source Port - 43353 Client B Destination - Remote IP - 99.99.99.99 - Destination Port - 52245

When using "netstat" in my router I get the following:

Proto Source Address                      Destination Address              State 
udp   192.168.1.142:52245                 99.99.99.99:43353                UNREPLIED   
udp   192.168.1.110:43353                 99.99.99.99:52245                UNREPLIED  

I am not sure if this is something to do with router behaviour and I don't see any settings related to the above in router admin console, so I have changed to different routers and I still get the same results described. Is it because connection like above is not permitted?

[EDIT - Include route table]

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
99.99.99.254    *               255.255.255.255 UH    0      0        0 WAN
99.99.99.0      *               255.255.255.0   U     0      0        0 WAN
192.168.1.0     *               255.255.255.0   U     0      0        0 LAN
default         99.99.99.254    0.0.0.0         UG    0      0        0 WAN

• javascript
• network-programming
• udp
• webrtc
• nat

Share Improve this question Follow edited Jan 7, 2016 at 1:48 forestclown asked Jan 5, 2016 at 12:10 forestclownforestclown 1,60244 gold badges2626 silver badges4040 bronze badges 3

• The issue is that when both peers/clients remote IP (99.99.99.99) are on the same router (same LAN) it doesn't work. – forestclown Commented Jan 6, 2016 at 14:08
• Did you run the netstat mand on the NAT router? – Tahlil Commented Jan 9, 2016 at 15:16
• I didn't run the mand, the netstat output is returned from the router admin GUI – forestclown Commented Jan 9, 2016 at 16:36

Add a ment  | 

2 Answers 2

Sorted by: Reset to default 3

To redirect packets ing from internal IP to another internal IP is not supported by all NAT. This is called Hairpinning. Example from wiki which is pretty similar to your case,

Let us consider a private network with the following:

Gateway address: 192.168.0.1
Host 1: 192.168.0.5
Host 2: 192.168.0.7

The gateway has an external IP : 192.0.2.1
Host 1 runs a P2P application P1 on its port 12345 which is externally mapped to 4444.
Host 2 runs a P2P application P2 on its port 12345 which is externally mapped to 5555.

If the NAT device supports hairpinning, then P1 application can connect to the P2 application using the external endpoint 192.0.2.1:5555. If not, the munication will not work.

when both clients are in the same LAN they will almost always connect via "host candidates" (sometimes via relay candidates, not sure why)

This can only happen if one or both of the host has blocked the IP address of the other. Other than that there is no way for two devices under same LAN to not have host to host connection.

I was able to establish ice connection between two clients in same LAN using srvflx candidates only by VPN tunneling one client.

The connection would never succeed without using the VPN.

STUN servers I tested from the VPN tunneled client had no problem determining my local and mapped addresses.