The simplest (and traditional) way of defining hosts when creating an Action is to use IP addresses or hostnames.
Using IP addresses
IP addresses can be used directly.
Supported formats
Host definition | Use for |
|---|---|
1.0.0.26 | Single entries |
1.0.0.26, 1.0.0.30 | Multiple entries |
1.0.0.0/28 | Subnets |
1.0.0.0/28, 1.0.0.128/28 | Multiple subnets |
Hostnames (DNS)
Hostnames can be used directly or with specific prefixes which dictate exactly how they will be handled by the Appgate SDP system. These will be resolved by some internal DNS server(s) via the Gateways which are normally configured on the Site where the internal DNS server(s) resides. Typically Clients will use the same DNS server(s) as the Gateways. Even though shortnames might work (because of the way Windows handles DNS domains), you should not use shortnames when defining hosts.
Clients have their DNS configured in one of 3 ways and in the following order:
by a specific DNS Policy assigned to the user.
automagically from within the DNS resolver using a hidden Policy.
by the Identity Provider that the user authenticates against (old way).
NOTE
In the last two cases, remember to include an Entitlement to allow the Client access to the specified DNS server(s).
Hostnames are resolved in one of two ways - using the DNS resolver or the DNS Forwarder depending on the prefix used.
The DNS Forwarder:
Does not support overlapping domains so any domains belonging to one Site must have the same depth. For example, a configuration with https://application.web.my.co and https://web.my.co is not supported, but https://application.web.my.co and https://binary.web.my.co is supported.
Different domains resolving to same IPs (shared hosting, CDNs etc) are treated as same. In this case *.domain based cannot provide separation based on the hostname as they work based on the resolved IPs.
Supported syntax
host definition | Resolved by | Result |
|---|---|---|
myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com |
myserver1.my_co.com, | DNS Resolver | Resolves the IP addresses of myserver1.my_co.com and |
dns://myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com |
dns://myserver1.my_co.com, | DNS Resolver | Resolves the IP addresses of myserver1.my_co.com and |
http://myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com - see URL access below |
https://myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com - see URL access below |
*.my_co.com [*.domain.commy_co.com] | DNS Forwarder | Resolves the IP addresses of myserver1.my_co.com, |
*.my_co1.com [*.my_co1.com], *.my_co2.com [domain://my_co2.com] | DNS Forwarder | Resolves the IP addresses of myserver1.my_co1.com, |
* You should always use dns:// if you can - especially in the case of a single host. It is possible to create security issues using *.domain as it will return (and allow access to) all subnets/hosts within the defined domain.
When trying to configure access to a SaaS provider, DNS synchronization issues can occur if you use the DNS resolver. This can be avoided if instead you use the DNS forwarder.