I couldn't establish ice connection between two clients in same LAN using srvflx candidate

Question

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.org 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

Answer 1

To redirect packets coming 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 communication 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.

Answer 2

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.