Known Issues

The following are the known issues in this release.

PAC file updates do not immediately take effect.

Because of the PAC file cache on browsers, updates to the content of the TMWS PAC file do not immediately take effect on end user browsers and it is unknown how much time it takes before the updates finally take effect. In some cases, the issue remains even after users clear the Internet Explorer cache or restart their browsers.

To test the updates, open Google Chrome on a computer that forwards traffic to TMWS and perform the following steps:


The Chrome process terminates when you perform these steps. Before starting, complete any pending tasks on Chrome.

  1. Run command prompt cmd.exe with administrator privileges.

  2. Run the following command (for use under Windows):

    taskkill /F /IM chrome.exe
  3. Open Chrome and check if the PAC file updates have taken effect.

Transparent authentication does not work.

Transparent authentication does not work properly in any of the following scenarios:

  • Port forwarding is used as the traffic forwarding mechanism in use.

  • A user configures a browser to bypass the TMWS proxy for the authentication server. For example, a user might add the authentication server to either the proxy exception list or the skiphost list in a PAC file.

    In this case, authentication requests go through the authentication server directly. Since transparent authentication is based on standard HTTP proxy protocol, the browser will not respond to requests from the authentication server without proxy.

    Note that for the Active Directory direct authentication method, the authentication server is For the AD FS and agent methods, the authentication server is the AD FS server or the Authentication Agent server.

When a website is set to 'DIRECT' in the PAC file in order to bypass the proxy, the website may display abnormally in Internet Explorer.

When using a Proxy Auto-Configuration (PAC) file and specifying a website as 'DIRECT', Internet Explorer treats this site as part of the 'Local Intranet' zone. As a result, some embedded objects belonging to domains other than the main page of the website, display incorrectly. This is because Internet Explorer treats other domains as part of the 'Internet' zone, which cannot share the TMWS logon cookie with the main page due to Internet Explorer's security restriction.

To resolve this issue:

  1. Go to Tools > Internet Options > Security and enable Protected Mode for all zones.

  2. Go to Tools > Internet Options > General. From the Browsing history area, delete temporary Internet files, history, cookies, saved passwords, and web form information.

  3. Restart Internet Explorer.

Some non-browser applications may fail to log on through the TMWS proxy.

For both gateway and Mobile VPN users, non-browser applications are not fully compatible with the HTTP protocol, so they cannot pass authentication credentials back to TMWS.

To resolve this issue, use a browser to access any HTTP site and then use the non-browser application to try again. If you can log on to a non-browser application directly but still fail through TMWS, please contact Trend Micro for technical support.

A client browser cannot access a website normally.

A client browser cannot access a website normally if the client system time is off by more than two hours.

To resolve this, correct the client system time.

TMWS may be blocked by legitimate websites.

Some web servers may dynamically block the connection for a specific IP addresses. Therefore, if you can access a website directly and access to this website through TMWS fails, the website may not be permitting connections from TMWS. Please contact Trend Micro for technical support.

TMWS does not recognize multi-byte encoded characters in 'Keyword' match mode if they are in the path part of a URL.

If the match mode for Approved/Blocked URLs and Customized URL Categories is set to 'Keyword', TMWS does not recognize multi-byte encoded characters if they are not in the domain name part but in the path part of a URL. For example, サービス matches www.サービス.com but will not matchサービス.

The default TMWS root CA certificate is used when a roaming user's first web traffic request is for an HTTPS URL.

An organization has its own CA certificate and has cross-signed it with the Certificate Signing Request (CSR) file provided by Trend Micro.

In this case, when a roaming user initiates an HTTPS request for the first time and the user never sends an HTTP request before, the default TMWS root CA certificate, rather than the cross-signed CA certificate, is used because the organization that the user belongs to can be identified only after the HTTPS traffic is successfully decrypted. After this, the cross-signed CA certificate of the organization will be used in the user's subsequent HTTPS requests.

TMWS only supports IPv4 in this version.

TMWS in this version only supports IPv4, and does not support IPv6.

The configurations of the NIC not selected during deployment wizard is cleared after the process is completed.

If there are two NICs available for an on-premises gateway, and one is selected and configured for data transmission in the deployment wizard process. The configurations of the other NIC will be cleared when the process is completed. To re-configure the NIC, go to Network > Interfaces.

The last-modified IPv4 gateway address always takes effect on an on-premises gateway.

If an on-premises gateway is configured with two NICs, the IPv4 gateway address that is the last modified always takes effect.

Bandwidth control applies only on the first configured NIC

If there are more than one NIC available for an on-premises gateway, bandwidth control rules apply only on the NIC that was first configured under /etc/sysconfig/network-scripts, with the name ifcfg-*. * is the NIC name, for example, eth0 or eth0.5.

Authentication will fail if Active Directory (AD) users in a Microsoft AD Global Catalog (GC) have the same sAMAccountName.

In any of the three supported authentication methods, when a Microsoft AD GC is added and selected as the default domain for transparent authentication on the management console, TMWS cannot distinguish AD users if they have the same sAMAccountName. Therefore, authentication will fail.

Perform either of the following:

  • Request the user to type the User Principal Name (UPN) on the user authentication page.

  • Follow the steps under Directory Services to separately add and configure each AD domain that has this limitation.

The URL category of a website is marked as "UNKOWN" when a timeout occurs in Web Reputation Services (WRS) queries.

When WRS fails to query the URL category of a website due to an internal error, TMWS will mark the category of this website as an "UNKNOWN" type, which may lead to improper handling of this website during policy enforcement in the following case:

The customer sets the action of the default cloud access rule to block all traffic types and also creates a new rule to allow only the traffic of certain URL categories, for example, banking websites. When a banking website fails to be queried by WRS, it will be marked as "UNKNOWN" in TMWS, which means that it will not match the configured cloud access rule but fall into the default rule. Based on the action of the default rule, this website will be blocked, which is against the customer expectation.

To solve this, DO NOT set Traffic Types to All. Instead, click Selected application categories and URL categories and then select all categories under URL Categories. This will exclude the "UNKNOWN" type from the default cloud access rule and make the traffic from this website accessible as expected.

TMWS does not send suspicious object related detection logs back to Apex Central

In this version, after TMWS successfully integrates with Apex Central, it uses the suspicious objects synchronized from Apex Central to detect threats, but does not send the corresponding detection logs back to Apex Central.