Sometimes, IWSaaS 3.0 users connect to a data center which is not what they would expect since it is located in a different region from the one where they are.
Most cases reflect the following scenarios:
- The diagnose page shows that the client connects to a data center which is not as expected.
- When using IWSaaS, the web page language is not as expected.
- When using IWSaaS, some applications cannot be used because they only can be used in a specific region.
- The global FQDN “proxy.iws-hybrid.trendmicro.com” uses the AWS Geo Location policy, which is determined by the client's resolver IP rather than the client's IP.
- Using the client's resolver IP to determine the location can sometimes be problematic since the client might use a DNS resolver which is located far away from the actual client's location.
- Additionally, AWS Route 53 service supports the EDNS client subnet function; in this extension, DNS queries will carry the client's IP subnet information. If your end users' DNS resolvers support this extension, then the Route 53 service would be able to determine the client's location more accurately.
- This is potentially one reason for which, when using Google DNS, the Route 53 geo-location policy can re-direct the customer to the correct location. You can refer to this Amazon Route 53 Forum Announcement for more details on EDNS-client-subnet
To confirm this behavior, we will need customers to run the following commands at the same time with a sleep time of 1 minute:
For Linux systems:
To get the current DNS' resolver IP
dig +short resolver-identity.cloudfront.net
To resolve our service FQDN proxy.iws-hybrid.trendmicro.com by the current DNS resolver
dig +short +identify proxy.iws-hybrid.trendmicro.com
To check whether the current DNS resolver supports EDNS
dig edns-client-sub.net TXT +short
For Windows systems:
- nslookup resolver-identity.cloudfront.net
- nslookup proxy.iws-hybrid.trendmicro.com
- nslookup -type=txt edns-client-sub.net
In the following image, the client uses DNS 18.104.22.168. Since this IP address is in London, the proxy address is resolved to 22.214.171.124, which is the scanner instance in the London Data Center (DC).
However, in the following image, the client uses DNS 126.96.36.199. This IP is in India, so the proxy address is resolved to 188.8.131.52, which is the scanner instance in the India Data Center (DC).
This is why the customer sometimes goes to the London DC and sometimes to the India DC.
The IWSaaS team provides a Tool containing two scripts, to confirm the root cause:
- For Windows systems: DNS_Resolver_Windows.bat
- For Linux systems: DNS_Resolver_Linux.sh
Both scripts provide the same check functions:
- Get the current DNS' resolver IP (Because the customer DNS' resolver IP may change).
- Resolve our service's FQDN proxy.iws-hybrid.trendmicro.com by the current DNS resolver.
- Check whether the current DNS resolver supports EDNS.
The scripts automatically get the above items 100 times and the interval is 1 minute, so it will last for about 100 minutes. If you do not want it to run for that long, you can stop it manually by pressing Ctrl + C.
Run the scripts when you find that the client connects to a region which is not expected; after running the scripts, you can collect the output files and send them over to Trend Micro for analysis.
Use the IWSaaS regional FQDN.
For example, if the customer is in India, they can use the FQDN “proxyst-as1.iws-hybrid.trendmicro.com”
- Use the DNS server which is in the same country as the user.
- Let the DNS Server support EDNS.
Use the known recursive DNS providers who include ECS information in the DNS queries:
- Google Public DNS