Closed Bug 1313384 Opened 8 years ago Closed 7 years ago

Ice candidate not being generated for VPN interface

Categories

(Core :: WebRTC: Networking, defect)

51 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: balwant.bisht, Unassigned)

Details

(Whiteboard: [needinfo 2016/10/27 to reporter])

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.
Component: WebRTC → WebRTC: Networking
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)?
Flags: needinfo?(balwant.bisht)
Whiteboard: [needinfo 2016/10/27 to reporter]
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.
(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
(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.
(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.
Nothing actionable here.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Flags: needinfo?(balwant.bisht)
You need to log in before you can comment on or make changes to this bug.