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)

x86_64
Windows 8
defect

Tracking

()

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
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
Group: network-core-security
Component: Untriaged → Networking
Product: Firefox → Core
Was this working prior to Firfox33?
Flags: needinfo?(mark.graceffa)
Severity: critical → normal
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)
Version: 33 Branch → unspecified
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.
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.
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
Whiteboard: [reporter-external]
What are your Firefox proxy settings?
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.
Any update on having this issue fixed?
Whiteboard: [necko-would-take]
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".
Priority: -- → P5
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.

Taking and making P1 (for 71 cycle) at Nhi's request.

Assignee: nobody → honzab.moz
Priority: P5 → P1
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Status: ASSIGNED → NEW
Assignee: honzab.moz → nobody
Priority: P1 → P5
Whiteboard: [necko-would-take] → [necko-would-take][necko-triaged]
See Also: → 1565022
Attachment #8644907 - Attachment is obsolete: true
Severity: normal → S3

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.

Attachment

General

Creator:
Created:
Updated:
Size: