Several websites inaccessible through HTTPS proxy using IPv6
M300, 12.5.8
I've noticed several websites over the last few months are not accessible through the HTTPS proxy. Just today a user mentioned that a sharepoint.com link sent from a client wouldn't open. I tested and confirmed the behavior. Later I came across this link as well...
https://help.sonicwall.com/help/sw/eng/7110/26/2/4/content/Firewall_Managing_QoS.088.3.html
These are just a couple of examples but I've noticed probably a dozen or so. About the same time this started I enabled IPv6 on the network. After some more testing with the two problematic links above from a different Watchguard site without IPv6, it seems IPv6 may be the culprit. Or rather, the HTTPS proxy isn't fully compatible with IPv6.
The workaround is to use an HTTPS packet filter instead however it appears that some work needs to be done to improve the current HTTPS proxy.
Comments
Hi @pacificadmin
-On the HTTPS proxy, are you using content inspection?
-Does the HTTPS proxy display any error message (either to the user, or in logs in traffic monitor?)
IPv6 compatibility is an ongoing enhancement -- if this is an issue you've been running into I'd suggest opening a support case so we can get more data/logs and potentially get a bug opened to correct whatever issue you're running into here.
Thank you,
-James Carson
WatchGuard Customer Support
Content inspection was not being used for these sites. No error message displayed to users, browser just spins. There's eventually a timeout error of some sort in the traffic monitor but nothing to useful. I actually opened a case for similar behavior a couple of months ago and the workaround was to select Enable only when ICMP network issues are detected in Global Settings > Networking > TCP Settings > TCP MTU Probing. That worked for the problem site(s) at the time but it appears to be having no effect for these new problem sites.
I'm finding that IPv6 is problematic in may ways. I implemented it to start familiarizing with it and work out any kinks, and there certainly have been some, not all WatchGuard/firewall related.
The latest issue is trying to manage DropBox traffic. I set out to use Application Control to limit DropBox traffic. DropBox uses HTTPS. Application Control requires content inspection to be used for a HTTPS proxy policy. The problem there is that DropBox is listed on the Content Inspection Exceptions list as it is apparently incompatible with Watchguard content inspection. BTW, the Content Inspection Exceptions list includes nearly every app that I'd want to use it for (Teams, Zoom) so it doesn't seem to be overly useful.
The fallback plan then was to use a HTTPS packet filter and manage traffic based on the known DropBox FQDN URLs, which is a manageable list (https://help.dropbox.com/accounts-billing/security/official-domains). Come to find out though that FQDN lookups in Fireware OS only support IPv4 addresses (https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/fqdn_about_c.html)
That leaves me wondering how to effectively manage traffic to these sites using a WatchGuard device on an IPv6 network.
What do you mean by "limit DropBox traffic"?
Prevent access ?
You can block access on the HTTPS proxy without using Inspect.
All you need is the SNIs which are used by the site to which you want to deny access.
While one can use the the CN, in many cases it is blank, so I always use the SNI.
The SNIs that I see being used to access Dropbox are:
cfl.dropboxstatic.com
dropbox.com
It is not clear that all of the domains that are listed in the Predefined Content Inspection Exceptions list don't work with Inspect. At least that was the uptake from the early days related to discussions of this list on the previous long gone Forum.
I can log in to Dropbox just fine with Inspect enabled and the dropbox entry unselected on the Predefined Content Inspection Exceptions list.
And prior to doing the unselect, I saw plenty of Inspect lines for the dropbox site in Traffic Monitor.
I need to throttle DropBox traffic. The issue is with the desktop client, not the web interface. The client runs as a service and syncs data between DropBox servers and the local system over HTTPS. With content inspection enabled it is not working. I'm using the default Proxy Authority cert for testing, which the client is set up to trust. Browser access works, client does not. Here's some debug info...
2021-11-19 09:03:57 https-proxy 0x1068c870-7213 42: 192.168.9.161:51670 -> 162.125.2.13:443 [A t] {B} | 43: 98.191.253.55:51670 -> 162.125.2.13:443 [B t] {N}[]: Continue DPI connection Debug 2021-11-19 09:03:57 Allow 192.168.9.161 162.125.2.13 https/tcp 51671 443 INT EXT-Cox ProxyInspect: HTTPS domain name match (HTTPS-proxy-inspect-test-00) HTTPS-Client-custom proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client-custom" rule_name="dropbox.com" sni="client.dropbox.com" cn="" ipaddress="" geo_dst="USA" Traffic 2021-11-19 09:03:57 https-proxy 0x1089d660-4245 42: 192.168.9.161:51671 -> 162.125.2.13:443 [A t] {B} | 43: 98.191.253.55:51671 -> 162.125.2.13:443 [B t] {N}[]: Continue DPI connection Debug 2021-11-19 09:03:57 pxy 0x1068c870-7213 42: 192.168.9.161:51670 -> 162.125.2.13:443 [A t] {B}: Accept SSL Error [ret 0 | SSL err 0 | Peer closed the channel] Domain: client.dropbox.com PFS: ALLOWED | ALLOWED Debug 2021-11-19 09:03:57 https-proxy 0x1068c870-7213 275302512:7213: nondata event 'SSL_FAILED: 42: 192.168.9.161:51670 -> 162.125.2.13:443 [A t] {B}' Debug 2021-11-19 09:03:57 https-proxy 0x1068c870-7213 42: 192.168.9.161:51670 -> 162.125.2.13:443 [A t] {B} | 43: 98.191.253.55:51670 -> 162.125.2.13:443 [B t] {X}[]: Connection closing on SSL failure (Domain: client.dropbox.com) Debug 2021-11-19 09:03:57 https-proxy 0x1068c870-7213 275302512:7213: nondata event 'ABORT: -1: 192.168.9.161:51670 -> 162.125.2.13:443 [~!A ra] {B}' Debug 2021-11-19 09:03:57 https-proxy 0x1068c870-7213 CLEANUP for conn 0x1068c870 :-1: 192.168.9.161:51670 -> 162.125.2.13:443 [~!A ra] {B} | -1: 98.191.253.55:51670 -> 162.125.2.13:443 [~!B sha] {X}[C] DebugYou could use Traffic Management to limit traffic to/from DropBox.
The DropBox subnet is 162.125.0.0/16
Create Traffic Mgt action with the transfer limit that you want
Create a HTTPS packet filter To: 162.125.0.0/16, and apply the Traffic Mgt action to that policy.
FYI - you posted your public IP addr in those logs
That may have been the DropBox subnet for that particular connection but they publish 17 different domains that traffic originates from (see link in original post). So filtering on a single IP subnet isn't really a reliable option.
I'm not too concerned with posting a public IP. After all the network is protected with a Watchguard device
Here is a list of their subnets.
162.125.0.0/16
45.58.64.0/20
108.160.160.0/20
185.45.8.0/22
199.47.216.0/22
https://www.dropboxforum.com/t5/Dropbox-files-folders/Subnets-IPs-of-dropbox-com/td-p/30789
I verified them via the DropBox AS number - AS19679
Well, except the goal here is to get this working with IPv6.
Look up the ASN, and you can see what looks to me as IPv6 numbers.
The IPv4 list that I found included many subnets within a supernet, so that may be the case here too.
I have no IPv6 experience, and so far I don't need it ... sometimes the future takes a long time to get here.
Here is an IPv4 to Iv6 conversion tool, which seems to handle subnets:
https://www.subnetonline.com/pages/subnet-calculators/ipv4-to-ipv6-converter.php
It seems that filtering traffic by IP address (IPv4 or IPv6) is the only option here. I was trying to avoid that for multiple reasons.
I mentioned DropBox specifically but there are several other sites that I need to configure traffic management for. For example, if I wanted to direct traffic for Apple device updates to a specific external interface using SD-WAN, filtering by IP address is not possible I believe as Apple only publishes domain names. There's no way to target just their update servers.
https://support.apple.com/en-us/HT210060
An IPv6 aware FQDN lookup in Fireware would solve those issues but it's not there currently. I contacted support on this topic and they submitted a feature request for IPv6 FQDN lookup. In any event, I think I can make do for now by using IP addresses for most of the traffic management rules I'm looking to implement.
This issue still exists 2 years later...
Can't do any HTTPS Proxy with V6 traffic.
Urgh... Maybe time to find a different vendor?
Hi @ChrisB multiple enhancements have been made to IPv6 support on Fireware. If you haven't already done so, I'd suggest opening a support case so that your issue can be addressed specifically.
-James Carson
WatchGuard Customer Support
I just ran into the same proxy issue. I could not download anything from sourceforge in Edge but Brave and Firebox worked fine. I found that this site would not load at all in Edge https://downloads.sourceforge.net until I selected "Enable only when ICMP network issues are detected".
I tested this on three different Fireboxes on Fireware 12.10.3 at various locations. Same issue with that website at all three locations. Anyone else have a problem with that website?
Hi @phanaaekIT
If you're receiving traffic back over ICMP, it likely means that you're using UDP to access that traffic. Try turning QUIC off in your browser, and try again.
The tickbox that you're checking would only be relevant if the firebox's proxy is in use - and the ICMP message would usually be to reduce packet size. If you're seeing this quite a bit, your external network's MTU may be set too small, or something else may be using up space.
-James Carson
WatchGuard Customer Support
I turned off QUIC in Edge but it didn't help. I created a new https proxy on the firebox with all extra features disabled i.e. no web filter, no content inspection, etc. and the site still doesn't load. Even a proxy exception for the site doesn't help. So far, the only way I've gotten the site to load in Edge is to not use a proxy or select "Enable only when ICMP network issues are detected".
This is the only site that I know of with this issue so far but it could have been an issue and we may have had to bypass the proxy in the past. MTU is currently set at 1500