Addressing each of the points:

1. This is definitely confusing. I notice that after receiving the binding success response, Chrome keeps re-transmitting the request (and with the same transaction ID). So Wireshark sees the response, but for some reason Chrome doesn't.

2. Chrome doesn't send the requests from a srflx candidate intentionally; it's just sending from the port on the Wi-Fi interface, and the NAT translates the address.

However, what does appear wrong is that Freeswitch chooses a candidate pair it received a binding request on, but no binding response. The purpose of the two-way connectivity checks is to ensure that packets can be both sent and received over a path. In this case, it looks like Chrome can send packets over the Wi-Fi interface but can't receive them.

3. If Chrome isn't seeing the packets on the Wi-Fi interface, that would explain this.

So I see two problems. One, that Chrome isn't receiving packets on the Wi-Fi interface, which may be a problem with Chrome or the OS/network configuration. And second, that Freeswitch selects a candidate pair that has not yet been validated.

Can you look into whether or not your Wi-Fi interface is functioning properly with Chrome? Maybe disable your Ethernet interface and try testing with AppRTC.

First of all thank you for the diving into this problem. I will try to make some clarifications on the last two items in issue list:

2. Chrome sends binding requests from WiFi interface and receives binding success responses from the same interface. You can use this query in wirheshark on a client dump (52.202.171.116 is an address of Freeswitch):
stun && ip.src == 52.202.171.116 && ip.dst == 192.168.41.185
But when Freeswitch tries to send binding requests back to Chrome on the WiFi interface Chrome ignores it. This query shows that WiFi interface never sends binding success response back to Freeswitch:
stun && ip.dst == 52.202.171.116 && ip.src == 192.168.41.185

3. This is still an issue (may be provoked by the second item) because as I see in wireshark dump Chrome has all necessary information to start DTLS handshake.

Seems like WiFi interface works properly with Chrome. AppRTC is not the same case because it's p2p call, not conference. But anyway it works with my WiFi interface.

Could you attach a native Chrome log? https://webrtc.org/native-code/logging/

That may help determine why we don't seem to be processing any packets received on the Wi-Fi interface.

Also, does the issue still occur if you take the VM out of the equation?

I disabled VM network interface but the issue still occurs. Logs for success and failure case are in attachments for this comment.

Deleted: chrome.failure.log 703 KB

chrome.failure.log 703 KB View Download

Deleted: chrome.success.log 101 KB

chrome.success.log 101 KB View Download

I don't see anything out of the ordinary in the failure log, unfortunately. It's just as if the packets were never received.

I did notice something on closer inspection of the packet capture, though. The STUN packets sent from the 192.168.22.57 and 192.168.41.185 addresses both have same "Linux cooked capture" source address. Meaning they're probably both sent from the Ethernet interface? I don't understand how this could happen, since the Ethernet subnet is 192.168.22.X/24. But it seems likely this is related.

honghaiz@, do you have any ideas?

Thank you for providing more feedback. Adding requester "deadbeef@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The log in #6 only showed that no STUN request/response packets were received. 
If you could provide complete logs for one session, including both freeswitch logs, Chrome logs and the pcap at the client, that will be more helpful for debugging.

Thanks.  

Contrary to everything I assumed, I recently learned that on Linux, calling bind() with an IP address doesn't actually force packets to be sent on the network interface associated with that address. To ensure that packets are sent from the network interface we intend, we may need to use sendmsg() with IP_PKTINFO.

I'm changing the bug title to represent the issue Chrome is to blame for (as far as I can tell).

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

Removing owner and setting status to Available, since the issue isn't currently being worked on.