Skip to main content

About Application Domain-Based Routing

Abstract

Understand how CloudConnexa routes application traffic using domain names instead of IP subnets, enabling secure access, flexible routing, and simplified network configuration.

Application Domain-Based Routing is a CloudConnexa feature that routes traffic for configured Applications based on domain names rather than IP subnets.

Instead of relying on network IP ranges, CloudConnexa can use application domain names to determine the correct destination network for traffic. This approach simplifies configuration and supports more flexible and secure access to applications across connected networks.

Note

CloudConnexa DNS Proxy setting needs to be ON for application domain-based routing to work. Refer to Set CloudConnexa DNS Proxy Off.

How Application domain-based routing works

Application domain-based routing performs two key functions:

  1. Steers traffic destined for an application's domain name to CloudConnexa.

  2. Routes that traffic to the correct connected network and destination IP address.

When a device connects to CloudConnexa:

  • A route to the WPC Domain Routing subnet is pushed to the device.

  • Traffic destined for this subnet is sent through the CloudConnexa tunnel.

CloudConnexa acts as a proxy DNS server for all DNS queries. When a user requests a configured application domain:

  • CloudConnexa returns an intermediary IP address from the WPC domain routing subnet (instead of the real destination IP).

  • The device routes traffic through the tunnel to CloudConnexa.

  • CloudConnexa maps the intermediary IP to:

    • The actual destination IP.

    • The associated connected network.

The traffic is then forwarded to the correct private network.

Advantages of Application domain-based routing

Application domain-based routing provides several benefits:

  • No need to turn off Split Tunnel — Public domain names can be configured as Applications. This allows traffic for specific domains to be routed through CloudConnexa while other traffic continues to use the local internet connection.

  • Cloaking — Users only see intermediary IP addresses. Internal network structures and application server IPs remain hidden.

  • Lateral movement prevention — Applications and network subnets aren't directly exposed, making scanning and unauthorized discovery more difficult.

  • Overlapping IP address ranges are supported — Multiple networks with overlapping IP ranges can be connected without conflicts because routing is domain-based, not subnet-based.

  • Create FQDN with embedded IP addresses — You can embed IP addresses in domain names without creating DNS records. This is useful for IoT networks. For example, ssh root@192-168-1-1.server.example.com can be used to SSH into the computer with a private IP address of 192.168.1.1 on the Network that has the domain name of server.example.com configured as an Application.

  • Exact match for subdomain routing control — By default, a domain-based Application also routes all subdomains through CloudConnexa. Enable Exact Match to restrict routing to the specified domain only, excluding subdomains. This is useful when subdomains require different routing behavior or access policies. For example, when app.example.com should be handled by a separate Application. The Exact Match toggle appears next to the domain field when adding or editing a Network Application.

  • Simplified setup — You only need to know the application server IP addresses, not the entire network subnets. Deploy a Connector, configure Applications, and create DNS records for private applications. Then, you can remotely access your applications using domain names.

In this section:
See also: