Overview
For customers considering or using Mesh Network, this article provides an overview of Mesh Network features, operating requirements, and usage restrictions.
Depending on your infrastructure environment and coexisting software, there may be cases where prior verification is required or where the service cannot be used for technical reasons.
Please be sure to review the contents of this article during the initial stage of consideration.
Table of Contents
- Coexistence with agent-based network products（SASE/VPN）
- Coexistence with agent-based security software（EPP/EDR）
- When using systems that require FQDN name resolution（Split DNS）
- Agent distribution through MDM（Mobile Device Management）
- TLS decryption in communication paths（Web proxies, load balancers, etc.）
1. Coexistence with agent-based network products（SASE/VPN）
When installing this service's agent and agents for other network products such as VPNs or SASE（Secure Access Service Edge）on the same device
Operational Restrictions
As a general rule, simultaneous startup of different network agents is prohibited.
This service uses an architecture that creates a virtual NIC（Network Interface Card）to control communications.
Since other network products also communicate through physical NICs via virtual NICs, starting them simultaneously may cause communication conflicts or unexpected communication issues.
Need for Verification
Operation involving switching between services is not guaranteed. If using this configuration, we recommend that customers verify in advance whether switching can be performed as expected.
2. Coexistence with agent-based security software（EPP/EDR）
When security agents such as EPP（Endpoint Protection Platform）or EDR（Endpoint Detection and Response）are installed on the device
Operational Restrictions
As of September 2026, the only EPP/EDR confirmed to have an operational track record when running concurrently with Mesh Network is WithSecure EPP/EDR, used in Endpoint & Managed Security. No particular issues have occurred when coexisting with WithSecure EPP/EDR in the same environment.
For security products other than those described above, verification is required because virtual NIC communications may conflict with security inspections and potentially be blocked.
Need for Verification
3. When using systems that require FQDN name resolution（Split DNS）
When using an “FQDN（example: internal.hennge.local）” as the connection destination when accessing Target resources such as internal Web servers, groupware, or Remote Desktop（RDP）
Operational Restrictions
Access in FQDN format requires configuration of “Split DNS” on the Mesh Network side. Without configuring “Split DNS,” internal domain name resolution cannot be performed, and access will not be possible.
The relationship between the name resolution mechanism and NIC settings is as follows.
When accessing by hostname: Name resolution is performed using this service's “WonderDNS,” and connections are made using a CGNAT（Carrier-Grade NAT）IP address.
When accessing by FQDN: Normally, the DNS settings configured on the device's physical NIC are used.
- When accessing by hostname from the internal network: Connect using CG-NAT（an IP address assigned by Mesh Network）through “WonderDNS.”
- When accessing by FQDN from the internal network: Refer to the internal DNS server configured on the NIC and connect through the internal network.
- When accessing by hostname from an external network: Since WonderDNS operates, access using CG-NAT（an IP address assigned by Mesh Network）is possible even without Split DNS configuration. If the destination is connected through a Subnet Linker, it cannot be accessed because it is not registered in WonderDNS.
- When accessing by FQDN from an external network: If the device's physical NIC is referring to an external Internet DNS server（such as one provided by the carrier）, connections in FQDN format will fail unless Split DNS is configured, because the system will attempt to refer to the external DNS associated with the NIC. Therefore, when accessing via an FQDN from an external connection, Split DNS must be configured and functioning correctly.
For details about Split DNS, please see the following article.
[Mesh Network] About DNS in Mesh Network
Need for Verification
If any of the following conditions apply, customers must verify in advance whether operation as expected is possible.
Please check in advance whether the internal DNS can be accessed correctly through the Subnet Linker※ and whether name resolution functions properly.
-
Cases where this service's agent cannot be installed on the customer's internal DNS server（due to restrictions of the server OS, etc.）.
-
Cases where a managed DNS service from a cloud service is used, or where DNS is delegated to another external cloud DNS service.
※For details about Subnet Linker, please see the following article.
[Mesh Network] What is Subnet Linker?
4. Agent distribution through MDM（Mobile Device Management）
When using an MDM tool such as Microsoft Intune to distribute and silently install this service's agent across managed devices
Operational Restrictions
We do not provide official verification or technical support for automated distribution in customer-specific MDM environments.
Need for Verification
Please verify the distribution operation via MDM and the operation after deployment yourself, and use the service only after confirming that there are no operational issues.
5. TLS decryption in communication paths（Web proxies, load balancers, etc.）
If a load balancer, web proxy, or similar device exists on the communication path of this service（such as at the boundary between internal and external networks）and a product that decrypts encrypted communications（TLS decryption/SSL inspection, header inspection, etc.）to inspect or control the content is involved.
Operational Limitations
This service transmits communications by independently encrypting them between agents (using Mesh Network keys). If TLS/SSL communications are decrypted or packet data is inspected (such as SSL communication inspection or header inspection) by third-party products on the communication path, communication errors may occur due to encryption key mismatches or similar issues, resulting in failure to establish the Mesh Network.
Therefore, configurations involving communication inspection or TLS decryption are not supported.
Verification Requirements
This service cannot be used if exclusion settings cannot be configured on the proxy or load balancer.
During the verification phase, be sure to confirm in advance whether a decryption inspection policy for encrypted communications is applied on the Mesh Network communication path, such as at internal security gateways and load balancers, or whether it is possible to configure this service to be excluded from the scope of such policies.
Translation Disclaimer
This article has been automatically translated from the original Japanese version for your convenience.
While we strive to ensure accuracy, we cannot guarantee its reliability or completeness.
In the event of any discrepancies or questions regarding the content, the official Japanese version shall prevail.