1313384 - Ice candidate not being generated for VPN interface

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Networking, defect)

Description

[Balwant Bisht]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161024172922

Steps to reproduce:

I am trying to establish webrtc call with MCU server on our VPN. But Firefox not generating ice candidate for my VPN interface due to which ice connection with MCU is failing.


Actual results:

Firefox fail to establish ice connection with MCU. Firefox 51 not generating ice candidate for my VPN interface, but the same is working fine in Firefox 50.


Expected results:

Firefox to generate ice candidate for my VPN interface and ice connection should establish.

Comment 1

[Nils Ohlmeier [:drno]]

Do you have by any chance installed any of the extensions to not trickle private IP addresses or changed any user pref around that topic?
An easy way of double checking should be to try it with a fresh user profile on about:profiles.

Also of interest:
- what is the OS?
- do you have Multi-Process turned on (check for 'Multiprocess Windows' on about:support)?

Comment 2

[Byron Campen [:bwc]]

I suspect this is a result of the new IP protection code; unless camera/microphone access is granted, only the default route (not the VPN, probably) will be used.

Comment 3

[Balwant Bisht]

(In reply to Nils Ohlmeier [:drno] from comment #1)
> Do you have by any chance installed any of the extensions to not trickle
> private IP addresses or changed any user pref around that topic?
> An easy way of double checking should be to try it with a fresh user profile
> on about:profiles.
> 
> Also of interest:
> - what is the OS?
> - do you have Multi-Process turned on (check for 'Multiprocess Windows' on
> about:support)?

OS: Mac Os Sierra (10.12)
Multi-Process turned on: Yes enabled by default

Comment 4

[Balwant Bisht]

(In reply to Byron Campen [:bwc] from comment #2)
> I suspect this is a result of the new IP protection code; unless
> camera/microphone access is granted, only the default route (not the VPN,
> probably) will be used.

Byron Campen is correct. 

If I am joining with camera/microphone access then PeerConnection is getting established. But the problem is, we establish PeerConnection with MCU first and camera/microphone is only accessed when user press camera/microphone unmute button in UI. So this new IP protection change will break our use case.

Comment 5

[Byron Campen [:bwc]]

(In reply to Balwant Bisht from comment #4)
> (In reply to Byron Campen [:bwc] from comment #2)
> > I suspect this is a result of the new IP protection code; unless
> > camera/microphone access is granted, only the default route (not the VPN,
> > probably) will be used.
> 
> Byron Campen is correct. 
> 
> If I am joining with camera/microphone access then PeerConnection is getting
> established. But the problem is, we establish PeerConnection with MCU first
> and camera/microphone is only accessed when user press camera/microphone
> unmute button in UI. So this new IP protection change will break our use
> case.

I can see that. But this is what is in the spec right now (https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-02). I think it is a little flawed, personally, but the workaround is simple.

Comment 6

[Nils Ohlmeier [:drno]]

Nothing actionable here.