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

  • james.carsonjames.carson Moderator, WatchGuard Representative

    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]    Debug
    
  • You 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.

  • edited November 19

    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.

  • edited November 19

    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

Sign In or Register to comment.