1

I have been using the following code to detect the LAN IP address of a client running some proprietary software (please no "you shouldn't do this", I didn't write the code).

function ip_local()
{
 var ip = false;
 window.RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection || false;

 if (window.RTCPeerConnection)
 {
  ip = [];
  var pc = new RTCPeerConnection({iceServers:[]}), noop = function(){};
  pc.createDataChannel('');
  pc.createOffer(pc.setLocalDescription.bind(pc), noop);

  pc.onicecandidate = function(event)
  {
   if (event && event.candidate && event.candidate.candidate)
   {
    var s = event.candidate.candidate.split('\n');
    ip.push(s[0].split(' ')[4]);
   }
  }
 }

 return ip;
}
ip_local();

Which is from another StackOverflow post, the code has been working fine for a year and a half up until this afternoon.

Where as my local ip seems to be detected as 153b3a68-e3fb-4451-9717-d9b3bc2b5c60.local instead of the usual 192.168.0.11.

Edit: If anyone cares, this issue is NOT bypassable and has to be done via a server side language, in my case I ended up using PHP as a temporary "bandaid" over the problem.

This is a problem for my app as it detects whether a local server is running on the host.. Which it cannot do if it cannot detect the LAN IP address.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Barrie Reader
  • 10,647
  • 11
  • 71
  • 139
  • Why don't you post a comment in the other SO question, asking why it's not working any more? – Barmar Jun 22 '19 at 00:04
  • Because this seems limited to my experience. It's not an "across the board" kinda deal. I wondered if anyone else has any experience with this. – Barrie Reader Jun 22 '19 at 00:06
  • I just tried it and it worked. – Barmar Jun 22 '19 at 00:07
  • This is my point, I was wondering if anyone else has had my experience, as my per question. – Barrie Reader Jun 22 '19 at 00:08
  • It looks like you have a local DNS server that's performing a reverse DNS translation of the IP to a name. – Barmar Jun 22 '19 at 00:13
  • See https://en.wikipedia.org/wiki/.local – Barmar Jun 22 '19 at 00:16
  • this is currently an experiment but rolling out in Chrome 75. You are using WebRTC for a purpose that its not designed for and that is often abused. If you think you haver a legitimate use-case, acquiring camera permissions with getUserMedia will give you IP addresses. – Philipp Hancke Jun 22 '19 at 10:46
  • @PhilippHancke - Ahh a possible fix! I'm definitely using it as it was supposed to be used. That is to detect the IP to connect to a newly run server on the localhost. But perhaps this getUserMedia will work :/ What a nightmare.... – Barrie Reader Jun 22 '19 at 10:51
  • I wouldn't bank on that working for very long. It's incredibly short sighted, in my opinion, of browser developers to assume that people are only using WebRTC for voice and video chat. I suspect this mistake will be fixed. – Brad Jun 22 '19 at 15:13
  • I ended up using a server side language as per my edit. @Brad – Barrie Reader Jun 22 '19 at 18:16
  • 1
    Use this method if you have mac: https://stackoverflow.com/questions/56543917/unable-to-fetch-ip-v4-address-from-rtcpeerconnection-chrome – Gautam Krishna R Sep 02 '19 at 10:45

1 Answers1

1

This is part of a new security standard, to prevent leakage of private IP addresses.

See also: https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-02

Summary:

As detailed in [IPHandling], exposing client private IP addresses by default maximizes the probability of successfully creating direct peer-to-peer connection between two clients, but creates a significant surface for user fingerprinting. [IPHandling] recognizes this issue, but also admits that there is no current solution to this problem; implementations that choose to use Mode 3 to address the privacy concerns often suffer from failing or suboptimal connections in WebRTC applications. This is particularly an issue on unmanaged networks, typically homes or small offices, where NAT loopback may not be supported.

This document proposes an overall solution to this problem by registering ephemeral mDNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates. WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application.

Community
  • 1
  • 1
Brad
  • 159,648
  • 54
  • 349
  • 530
  • Ouch, so there is no way around it? This is part of Windows now? – Barrie Reader Jun 22 '19 at 00:26
  • @BarrieReader No, there's no way around it, and nor should there be. If this is capability you need, use a browser extension. This is part of Chrome (and probably other browsers), not Windows. – Brad Jun 22 '19 at 00:42
  • A browser extension isn't possible as the app runs in Chrome's AppMode... And it runs locally... So trusting individual users to install the extension is a no-go :( – Barrie Reader Jun 22 '19 at 10:50