Open
Bug 1083569
Opened 10 years ago
Updated 9 months ago
Firefix doesn't handle NRPT entries with proxy servers set
Categories
(Core :: Networking: Proxy, defect, P5)
Tracking
()
NEW
People
(Reporter: mark.graceffa, Unassigned)
References
Details
(Whiteboard: [necko-would-take][necko-triaged])
Attachments
(1 obsolete file)
User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3)
Steps to reproduce:
Specified a FQDN www.application7p.com (in the Firefox 33.0 browser) that is directed in the Microsoft DirectAccess tunnel to HP's intranet based on the Microsoft NRPT entry that has a proxy setting associated with the entry.
Actual results:
the URL would not open as Firefox doesn't honor the NRPT entry with a proxy setting as it should. Matter of fact it ignores the NRPT entry all together and sends the query and traffic externally as if the NRPT entry doesn't exist at all rather than inside the DirectAccess tunnel as the NRPT is configured.
Expected results:
the dns query and traffic for the URL would go internal in the Microsoft DirectAccess tunnel and use the proxy server to reach the URL as specified by the NRPT entry and the page for the URL would load.
Here is an NRPT entry with a proxy setting that Firefox is not supporting that should be going in the Microsoft DirectAccess tunnel and using the proxy server specified to reach the URL:
Settings for .application7p.com
----------------------------------------------------------------------
DirectAccess (Certification Authority) :
DirectAccess (IPsec) : disabled
DirectAccess (DNS Servers) : fd39:ec0d:499a:3333::1
DirectAccess (Proxy Settings) : proxy.houston.hp.com:8080
Here is a typical NRPT entry that Firefox is supporting fine (no proxy set) which allows the query and traffic to go internal using the Microsoft DirectAccess tunnel:
Settings for sp-plug-internal.www7.hp.com
----------------------------------------------------------------------
DirectAccess (Certification Authority) :
DirectAccess (IPsec) : disabled
DirectAccess (DNS Servers) : fd39:ec0d:499a:3333::1
DirectAccess (Proxy Settings) : Bypass proxy
Here is a NRPT exclusion that sends the query and traffic externally to the internet that is working fine with Firefox:
Settings for germany.remoteaccess.hp.com
----------------------------------------------------------------------
DirectAccess (Certification Authority) :
DirectAccess (IPsec) : disabled
DirectAccess (DNS Servers) :
DirectAccess (Proxy Settings) : Use default browser settings
Reporter | ||
Comment 1•10 years ago
|
||
Applies to Windows 7, Windows 8, Windows 8.1, and probably Windows 10.
If you need further information or network traces please let me know - mark.graceffa@hp.com
Severity: normal → critical
Updated•10 years ago
|
Group: network-core-security
Component: Untriaged → Networking
Product: Firefox → Core
Was this working prior to Firfox33?
Flags: needinfo?(mark.graceffa)
Updated•10 years ago
|
Severity: critical → normal
Reporter | ||
Comment 3•10 years ago
|
||
No, as far as I know it has never worked. I was running 31 or 32 and it didn't work and upgraded to 33 and it still didn't work. This has been a problem for a while now but I decided to bug it.
Flags: needinfo?(mark.graceffa)
Updated•10 years ago
|
Version: 33 Branch → unspecified
Updated•10 years ago
|
Whiteboard: [reporter-external]
a quick internet search shows this may not be just a Firefox issue, as this likely affects Chrome as well.
https://social.technet.microsoft.com/Forums/windowsserver/en-US/b9f5dff3-22b5-45b4-a108-c510ac02f56a/directaccess-2012-r2-force-tunnel-nonie-browsers
This could be a case of a Microsoft specific issue as this might only work with IE.
Reporter | ||
Comment 5•10 years ago
|
||
Chrome has a slightly different issue but end result is it doesn't work either when the Proxy setting is specified in the NRPT entry. Chrome still sends the query and traffic internal in the DirectAccess tunnel but doesn't use the proxy server as specified to get to the URL. Firefox ignores the NRPT entry all together when the Proxy setting is specified in the NRPT entry thus resulting in the query and traffic going external when it should go internal. IE works correctly.
I do not believe the proper APIs are being used or used correctly when the NRPT entry has a proxy setting set.
We are using WS12/WS12R2 DirectAccess and split-tunnel not a forced tunnel. The URL listed describes the problem with Firefox and Chrome not honoring NRPT entries with the Proxy setting configured but it not specifically our case since we are not using a forced tunnel.
We have a lot of Firefox use and really would like to have this fixed and supported. NRPT without proxy setting configured works great, but NRPT with a proxy setting configured is not working and forcing Firefox users to use IE for these cases.
Reporter | ||
Comment 6•10 years ago
|
||
Please open a case with Microsoft Dev support group to get the API level differences between the browsers in order to use the NRPT properly
this does not seem to be a "security" issue, so I am going to open this bug. It sounds like we may have a feature that needs implementing.
Group: network-core-security, core-security
Updated•10 years ago
|
Whiteboard: [reporter-external]
Comment 8•10 years ago
|
||
What are your Firefox proxy settings?
Reporter | ||
Comment 9•10 years ago
|
||
There are no proxy settings defined. This is a split tunnel enabled not a split tunnel disabled or forced tunnel. Traffic either goes to the internet or the intranet. If it goes to the intranet it generally doesn't need a proxy since the client is external and connected with a DirectAccess split tunnel. The exception is when a DirectAccess NRPT entry has a proxy setting then it would use the DirectAccess tunnel to go to the intranet and use the proxy specified in the NRPT entry. Problem is this doesn't work correctly with Firefox or Chrome but does work correctly with IE. We need Firefox fixed to support this.
Reporter | ||
Comment 10•10 years ago
|
||
Any update on having this issue fixed?
Updated•9 years ago
|
Whiteboard: [necko-would-take]
Comment 12•8 years ago
|
||
This is an issue that we are now feeling. we just installed our first entry for this feature. to explain why its important, the Direct Access tunnel with split dns allows us to first check internal dns for an entry, and if it exists, then the request is sent to that ipv6 address over the tunnel, and if not, it uses local machine dns to resolve and honor the request. (i know you all understand that, its just background).
THe point is that with some business websites, they use IPAuthentication. if a http request comes from our intranet, then that person is directed to the prepaid site. we are able to extend this to DA clients because they are all corp owned and domain joined PCs.
I would love to help get to the bottom of this if you need help. im sure it will come up more as more people get on the DA bandwagon. I now have to disable firefox as the default and move everyone back to Edge/IE, so that things "Just Work".
Comment 13•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Comment 14•6 years ago
|
||
Microsoft doesn't develop DirectAccess anymore.
They fall back to standard vpn solutions.
Features of DirectAccess are taken back to client settings in Windows 10.
Routing desicions (i.e. split tunenling) can be done at routing level but NRPT is still there to take those decisions on basis of the fqdn.
NRPT allows to redirect traffic to the tunnel and also to redirect to proxies.
Support of NRPT is still very intersting to enable a single configuraiton for most of the browsers.
While NRPT is limited to Microsoft Browsers, this "simple soltuion" cannot be applied and specific solution must be put in place.
Support of NRPT would realy help companies solution bases on either DirectAccess or on Allways ON VPN.
Comment 15•5 years ago
|
||
Taking and making P1 (for 71 cycle) at Nhi's request.
Assignee: nobody → honzab.moz
Priority: P5 → P1
Updated•5 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Updated•5 years ago
|
Status: ASSIGNED → NEW
Updated•5 years ago
|
Assignee: honzab.moz → nobody
Priority: P1 → P5
Whiteboard: [necko-would-take] → [necko-would-take][necko-triaged]
Updated•5 years ago
|
Attachment #8644907 -
Attachment is obsolete: true
Updated•2 years ago
|
Severity: normal → S3
Comment 16•9 months ago
|
||
Moving bug to Core/Networking: Proxy.
Component: Networking → Networking: Proxy
You need to log in
before you can comment on or make changes to this bug.
Description
•