Troubleshooting

Host Status

If you cannot connect to a remote ACSC host, or if on an ACSC host its ACSC connection is not working, the first thing to do is to check the status of the host in the ACSC management UI. Follow these steps:

  1. Log into the ACSC management UI, and switch to the appropriate organization.
  2. Click the Hosts link in the page header. This will take you to the Hosts page.
  3. Click the name of the host. If you don’t see this host in the list, use the Filter by name… input at the top of the page to search for it by name. Clicking the name of the host will take you to the main page for the host.

Agent Status

On the main page for the host, check the ACSC agent’s status in the Agent panel.

Interface State

If the Status field in the Agent panel shows Good Ping, check the ACSC interface’s state in Interfaces panel.

Interface Down

Start Up

In the ACSC management UI, if the State field of an interface is shown as Down, try editing the interface to change its state as up. Follow these steps:

  1. Navigate to the main page for the interface (by clicking the name of the interface, usually “acsc0”).
  2. Click the Edit (pencil) icon in the Interface panel.
  3. Toggle the State toggle button to Up.
  4. Click the Update button.

This will queue a change to start up the interface. The next time the ACSC agent on the host pings the ACSC management server, the agent will attempt to start up the interface. This may take up to 1 minute; until that time, the state of the interface will usually be shown as Updating – although it may be shown as Down if the change has been applied, but interface is still in the process of starting up.

Restore to Point

If after a minute, the interface is still listed as Down, try restoring the interface to its last known good configuration. On the main page for the interface, follow these steps:

  1. Scroll down to the Config Changes panel.
  2. Click the Restore to Point (circle-with-arrow-and-dot) icon next to the last good change (often the change before the interface last shut down). This will open a Restore to Point In Time dialog.
  3. Select the Include all endpoint changes radio button.
  4. Click the Restore button.

This will queue several changes to reset the interface configuration, and start up the interface. The next time the ACSC agent on the host pings the ACSC management server, the agent will attempt to apply the reset configuration, and start up the interface. This may take up to 1 minute; until that time, the state of the interface will usually be shown as Updating – although it may be shown as Down if the changes have been applied, but interface is still in the process of starting up.

No Traffic

If the ACSC management UI shows the ACSC interface as up, try to connect outbound from the ACSC host to various other hosts by IP address. In particular, try to ping:

  1. The Anti-Cloud hub by its ACSC IP address (eg 10.12.34.1).
  2. A well-known Internet IP address that responds to ping, such as 1.1.1.1.
  3. If on an AD (Active Directory) domain, the ACSC IP address of a domain controller (eg 10.12.34.56).

No Traffic to Hub

If #1 (pinging the Anti-Cloud hub) does not work, the ACSC interface is non-functional. First check the Host Status.

Restart Interface

If the ACSC management UI shows the host’s agent status is Good Ping, and its interface state is Active or Available, try restarting the interface. On the main page for the interface, follow these steps:

  1. Click the Edit (pencil) icon in the Interface panel.
  2. Check the Restart checkbox.
  3. Click the Update button.

This will queue a change to restart the interface. The next time the ACSC agent on the host pings the ACSC management server, the agent will attempt to start up the interface. This may take up to 1 minute; until that time, the state of the interface will usually be shown as Updating – although it may be shown as Down if the change has been applied, but interface is still in the process of starting up.

Restore to Point

If after restarting the ACSC interface, you are not able to ping the Anti-Cloud hub from the host, try restoring the interface to its last known good configuration. On the main page for the interface, follow these steps:

  1. Scroll down to the Config Changes panel.
  2. Click the Restore to Point (circle-with-arrow-and-dot) icon next to the last good change (often the change before the interface last shut down). This will open a Restore to Point In Time dialog.
  3. Select the Include all endpoint changes radio button.
  4. Click the Restore button.

This will queue several changes to reset the interface configuration, and restart the interface. The next time the ACSC agent on the host pings the ACSC management server, the agent will attempt to apply the reset configuration, and restart the interface. This may take up to 1 minute; until that time, the state of the interface will usually be shown as Updating – although it may be shown as Down if the changes have been applied, but interface is still in the process of starting up.

Match Addresses and Routing

If after restoring the ACSC interface to the last known good configuration, you are still not able to ping the Anti-Cloud hub from the host, check that the interface’s IP addresses matches the addresses that the Anti-Cloud hub is configured to route to it. On the main page for the interface, follow these steps:

  1. Write down the addresses listed in the Addresses field of the Interface panel. These are its ACSC addresses, which will be something like 10.12.34.78/24, fd01:a:b:c::4e/64 (ignore the netmask – the number after the slash – as it’s not relevant to this issue).
  2. Click the to Anti-Cloud Hub link in the Endpoints panel. This will take you to the main page for the endpoint which connects the host-being-troubleshot to the Anti-Cloud hub (the endpoint on the host-being-troubleshot’s own side of the connection).
  3. Scroll down to the Preshared Key panel, and click the name of the host-being-troubleshot (eg “to Alice’s Laptop”) in the Corresponding Endpoint field. This will take you to the main page for endpoint which connects the Anti-Cloud hub to the host-being-troubleshot (the endpoint on the Anti-Cloud side of the connection – ie the other side of the connection).
  4. Scroll down to the Routing panel, and verify that the IP addresses listed under the Allowed IPs field match the IPs you wrote down in step 1. In the above example, they should be 10.12.34.78/32, fd01:a:b:c::4e/128 (ignore the netmask – the number after the slash – as it’s not relevant to this issue).

If you’re using the host-being-troubleshot as a gateway to other sites or hubs, there may be additional addresses in the list from step 4 – but the list in step 4 must include the addresses from step 1. If not, either edit this endpoint to include them, or go back to the main page for the interface of the host-being-troubleshot, and edit the interface to change its addresses to match the routing on the Anti-Cloud hub’s endpoint.

No Traffic to Internet

If #1 (pinging the Anti-Cloud hub) works, but #2 (pinging a well-known Internet IP address) does not work, Internet routing on the host is not working correctly. This is most likely due to misconfigured “Allowed IPs” and “Disallowed IPs” settings on the host-being-troubleshot’s endpoint to the Anti-Cloud hub (these settings override the host’s own routing table when the ACSC interface is up and running on the host).

On the main page of for the interface, follow these steps:

  1. Click the to Anti-Cloud Hub link in the Endpoints panel. This will take you to the main page for the endpoint which connects the host-being-troubleshot to the Anti-Cloud hub.
  2. Scroll down to the Routing panel, and verify that the Allowed IPs field includes the entire IPv4 and IPv6 address space: 0.0.0.0/0, ::/0.
  3. Verify that the Disallowed IPs field does not include the Internet hosts that you tried to ping (like 1.1.1.1).
  4. Verify that no Allowed Apps field is listed.

If the Routing panel contains something other than described above, edit the endpoint to fix it. See the Edit Endpoint documentation for details.

No Traffic to Domain

If #1 (pinging the Anti-Cloud hub) and #2 (pinging a well-known Internet IP address) works, but #3 (pinging a domain controller ACSC address) does not work, the host may not be authenticated to the domain (or the domain controller may not be connected to the ACSC network).

First, check that the domain controller is in fact connected to the ACSC network. If it is, then check that the host-being-troubleshot is authenticated to the domain.

No DNS

If traffic is flowing as expected, but DNS is not working correctly, check these things:

  1. The host can connect to at least one if its configured DNS servers.
  2. If the host is on an AD domain, the DNS server used by the host is a DC (Domain Controller) for the same domain.
  3. The DNS server used by the host is answering its DNS queries with IP addresses that the host can reach.

Host DNS Settings

To check the host’s DNS configuration from the host’s main page in the ACSC management UI, follow these steps:

  1. Navigate to the main page for the interface (by clicking the name of the interface, usually “acsc0”).
  2. Scroll down to the Advanced panel, and check the DNS Servers field.

The DNS Servers field lists the DNS servers the host will try to use when connected to the ACSC network. If no DNS servers are listed, the host will use the same DNS servers when connected to ACSC as when not (this list can be configured via the host’s OS-level network settings, and is often updated dynamically by DHCP).

When multiple DNS servers are configured for a host, the host will query each DNS server in the order listed, waiting 1 second for an answer before trying the next server, and using the first answer it receives. If no DNS server responds, the host will not be able to resolve DNS names.

To update the host’s DNS configuration, follow these steps:

  1. Scroll back up to the Interface panel, and click the Edit (pencil) icon. This will bring up the Edit Interface page.
  2. Click the Advanced Properties toggle. This will reveal a number of additional fields.
  3. Edit the DNS Servers field. Separate each each DNS server IP address with whitespace or commas.
  4. Scroll to the bottom of the page and click the Update button.

This will queue a change to the interface configuration, and restart the interface. The next time the ACSC agent on the host pings the ACSC management server, the agent will attempt to apply the new configuration, and restart the interface. This may take up to 1 minute.

DNS on Domain

When on an AD (Active Directory) domain, in order for AD to work, the host needs to use a DNS server that is a DC (Domain Controller) for the same domain.

For a host that can connect to a domain controller over its LAN (Local Area Network), and never leaves the LAN, set the host’s ACSC DNS Servers field to blank (or alternatively, make sure that the host’s ACSC DNS Servers field includes a DC on the LAN as its first entry). Instead of using a different DNS configuration for the host when on the ACSC network, configure the host’s own OS DNS settings to use a DC on the LAN.

For a host that sometimes can connect to a domain controller over its LAN, and sometimes not (like a laptop that is sometimes used in office and sometimes at home), set the host’s ACSC DNS Servers field to a list that includes the DC’s LAN IP addresses first, and ACSC IP address second.

For example, for an AD domain with two DCs, where the first DC’s LAN address is 192.168.50.11 and ACSC address is 10.12.34.11, and the second DC’s LAN address is 192.168.50.12 and ACSC address is 10.12.34.12, set the host’s ACSC DNS Servers field to 192.168.50.11, 192.168.50.12, 10.12.34.11, 10.12.34.12.

This will ensure that the host will first try to contact the DCs via their LAN addresses, and then fallback to their ACSC addresses if the LAN addresses don’t work.

For a host that never can connect to a domain controller over its LAN (like a server hosted at a remote location), set the host’s ACSC DNS Servers field to list that includes the ACSC IP address of the DCs (with the ACSC IP address listed before any other IPs addresses which the host can access).

DNS Server Settings

DNS for the host will not work correctly unless the DNS server used by the host answers queries with IP addresses that the host can actually reach.

For example, say the host in question is a laptop that sometimes is used on an office LAN, and sometimes used at home. The host’s LAN IP address is 192.168.50.33, and its ACSC IP address is 10.12.34.33. You want the host to be able to access a fileshare by its DNS name of fileshare.mydomain.corp; the fileshare has a LAN IP address of 192.168.50.22, and an ACSC IP address of 10.12.34.22. The host will resolve DNS via a domain controller with an LAN IP address of 192.168.50.11, and an ACSC IP address of 10.12.34.11.

First of all, you would configure the host’s ACSC DNS Servers field to 192.168.50.11, 10.12.34.11, so that when making DNS queries, the host would try the DC’s LAN IP first (which would succeed when on the office LAN), and the DC’s ACSC IP second (which should succeed elsewhere).

When queried from the host’s LAN IP address to resolve the IP address of the fileshare, the DC should respond with the fileshare’s LAN IP (192.168.50.22); and when queried from the host’s ACSC IP address, the DC should respond with the fileshare’s ACSC IP (10.12.34.22).

To troubleshoot this scenario, run a DNS-query utility like nslookup on the host. When the host is on the office LAN, and you query the DNS server via its LAN IP, the DNS server should respond with the fileshare’s LAN IP first:

> nslookup fileshare.mydomain.corp 192.168.50.11
Server:  dc01.mydomain.corp
Address: 192.168.50.11

Name:      fileshare.mydomain.corp
Addresses: 192.168.50.22
           10.12.34.22

And when you query the DNS server via its ACSC IP, it should respond with the fileshare’s ACSC IP first:

> nslookup fileshare.mydomain.corp 10.12.34.11
Server:  dc01.mydomain.corp
Address: 10.12.34.11

Name:      fileshare.mydomain.corp
Addresses: 10.12.34.22
           192.168.50.22

If the order of answers is wrong, you need to enable Netmask Ordering (aka Subnet Prioritization) on the DNS server.

If the answer only includes the LAN IP address, you may need to set up a Reverse Lookup Zone for your ACSC network addresses. This example should have a 34.12.10.in-addr.arpa zone for the 10.12.34.0/24 ACSC network address. Additionally, make sure that DNS Registration is enabled on your client machines (or, alternatively, if you don’t use automatic DNS registration, make sure you add both a LAN and an ACSC IP address to each DNS record you’ve manually set up for each ACSC host).

No Inbound Traffic

If traffic (like ping) outbound to other hosts is working, but traffic inbound from other hosts is not, this is likely due to the firewall rules on the host. Other hosts on the same ACSC network will have inbound access to the host (using the server’s ACSC IP address) according to the Windows firewall rules configured for the ACSC interface’s firewall profile.

Run the following PowerShell command on the host to check the firewall profile setting for its ACSC interface:

PS> Get-NetConnectionProfile -InterfaceAlias acsc0

Name                     : ws01.mydomain.corp
InterfaceAlias           : acsc0
InterfaceIndex           : 32
NetworkCategory          : DomainAuthenticated
DomainAuthenticationKind : Ldap
IPv4Connectivity         : Internet
IPv6Connectivity         : LocalNetwork

The NetworkCategory field shows the firewall profile (in this example, DomainAuthenticated, aka Domain).

The firewall profile of the ACSC interface should be Domain (or DomainAuthenticated) if the host is on an AD domain. Otherwise, the firewall profile of an ACSC interface can changed between Public and Private. The ACSC management UI can be used to set the firewall profile of a Windows host, via the ACSC Firewall Zone field.

To set the firewall profile from the host’s main page in the ACSC management UI, follow these steps:

  1. Navigate to the main page for the interface (by clicking the name of the interface, usually “acsc0”).
  2. Click the Edit (pencil) icon in the Interface panel.
  3. Click the Advanced Properties toggle. This will reveal a number of additional fields.
  4. Use the Firewall Zone field to select either Public or Private.
  5. Scroll to the bottom of the page and click the Update button.

This will queue a change to the interface configuration, and restart the interface. The next time the ACSC agent on the host pings the ACSC management server, the agent will attempt to apply the new configuration, and restart the interface. This may take up to 1 minute.

You can use the standard Windows Firewall tools to adjust the firewall settings for the firewall profile to which the ACSC interface belongs.

Other Issues

Cannot Join Domain

If you cannot join an ACSC host to an AD domain, check these things:

  1. What is the host status?
  2. Is the ACSC interface down?
  3. Is the host able to send traffic?
  4. Is the host able to resolve DNS properly?

Also check the DNS and port requirements from the AD Troubleshooting Guide.

Cannot Login as Domain User

If you cannot login into ACSC host as an AD user (or if login is very slow), check these things:

  1. What is the host status?
  2. Is the ACSC interface down?
  3. Is the host able to send traffic?
  4. Is the host able to resolve DNS properly?

Network Path Not Found

If you cannot access an SMB share over ACSC, check these things:

  1. What is the host status?
  2. Is the ACSC interface down?
  3. Is the host able to send traffic?
  4. Is the host able to resolve DNS properly?

Firewall Profile Not Applied

If a host is joined to an AD domain, the firewall profile of its ACSC interface will always be Domain, and it cannot be changed to a different profile.

If a host has not joined an AD domain, its firewall profile can be toggled between Public and Private. If you have configured an ACSC interface in the ACSC management UI with a Firewall Zone setting, ACSC will attempt to apply this setting to the firewall profile of the interface via PowerShell script. If the PowerShell execution policy of the host is Restricted, this script will be blocked.

To allow the script to run, change the host’s PowerShell execution policy to RemoteSigned (or AllSigned):

PS> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned