Skip to content

Host Connectivity

Symptoms covered on this page

  • The deployment never leaves Not Set Up, or flips to Offline shortly after installation.
  • The installer reports This system appears to be connected to the internet, but cannot reach the BreachLock platform.
  • The installer reports Could not download bootstrapper. Are you connected to the internet, or could your firewall/antivirus software be interfering?
  • The foothold log shows connection timeouts or TLS certificate errors when contacting the platform.

The foothold only ever makes outbound connections. You do not need to open any inbound firewall ports, and you do not need to give the host a public address. What you do need is an unfiltered outbound path to a small set of hostnames.

1. Confirm what the host can actually reach

Run these on the host machine itself. Running them from your laptop proves nothing — the laptop is usually on a different VLAN with a different egress policy.

# Does DNS resolve the platform?
nslookup aev.breachlocklabs.com

# Does the host reach the platform over HTTPS?
curl -I https://aev.breachlocklabs.com

# Does the host have general internet access at all?
curl -I https://example.com

POV (proof-of-value) customers should substitute aev-demo.breachlocklabs.com for aev.breachlocklabs.com in these and every other command on this page.

Read the results like this:

Result What it tells you
Any HTTP status back from aev.breachlocklabs.com — 200, 401, 403, anything The host reached us. The problem is not connectivity; go to Deployment Health.
example.com works, aev.breachlocklabs.com times out Egress filtering. Go to section 2.
Both time out The host has no internet access, or all egress is blocked. Check the default route and the gateway.
DNS does not resolve DNS filtering or an internal resolver with no forwarder. Go to section 3.
A certificate error Something is intercepting TLS. Go to section 4.

A note on ping. The installer uses ping to establish whether a network connection exists at all, but many environments drop ICMP while allowing HTTPS perfectly well. A failed ping on its own does not mean the host cannot reach us — always confirm with curl over port 443 before concluding anything.

2. Check the outbound allowlist

Every hostname the foothold needs is listed in the Foothold Setup Guide, and you can download the whole list as a plain text file for import into firewall or proxy tooling.

The ones that most often get missed:

  • aev.breachlocklabs.com (or aev-demo.breachlocklabs.com for POV customers) — required by every deployment, on every path. Nothing works without it.
  • The Ubuntu, Kali and Docker package mirrors — required only by dropper-based installs, which install tooling onto the host operating system. If the installer gets partway through and then fails while installing nmap, tshark or Docker, this is why.
  • The container registry (sapiens-container-server-prod.*.azurecontainerapps.io) — required only by Docker container deployments, which pull the agent image from it.

Allowlist by hostname, not by IP address

The platform is hosted behind infrastructure whose addresses change without notice. A firewall rule pinned to an IP address will work on the day it is written and fail silently some weeks later, which presents as a deployment that was healthy for a month and then went Offline for no visible reason.

3. Check for DNS filtering

DNS filtering is the most common cause of a host that has internet access and still cannot reach us, because the failure does not look like a firewall block — the connection is simply never attempted.

# What does the host resolve the platform to?
nslookup aev.breachlocklabs.com

# Compare against a public resolver, if your policy allows it.
nslookup aev.breachlocklabs.com 8.8.8.8

Two results are worth recognising:

  • NXDOMAIN, or no answer — an internal resolver with no forwarder for external names, or a filtering service that has categorised the domain.
  • An answer that points at an internal address — a DNS filter or sinkhole is redirecting the lookup. The host will then try to connect to something that is not us, and fail in a way that looks like a timeout.

Security-categorisation products routinely classify penetration-testing infrastructure as malicious. If you use one, the Breach360 hostnames need an explicit allow entry; being on the firewall allowlist does not exempt them from DNS-level categorisation.

4. Check for TLS interception and proxies

TLS inspection

Symptoms are certificate or SSL errors in the foothold log, and a curl that reports a certificate problem while a browser on the same network appears to work fine — the browser trusts the inspection appliance's certificate authority, and the host's command-line tooling may not.

The foothold tries three certificate authority bundles in order before giving up, and it says in its log which one it fell back to:

  1. The bundle packaged with its HTTP library, which carries the public roots.
  2. The host's system CA bundle — the one your operating system's trust store maintains.
  3. A certificate authority bundle packaged with the foothold itself.

That second step is the one that matters here. If your proxy re-signs TLS with an internal certificate authority, install that authority's certificate into the host's system trust store and the foothold will accept the intercepted connection on the fallback:

# Debian and Ubuntu
sudo cp your-internal-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Then restart the foothold so it retries with a fresh trust store — see Restarting the foothold.

Bypassing inspection for the Breach360 hostnames entirely works too, and avoids the problem rather than accommodating it. Prefer that where your policy allows it.

Explicit proxies

The foothold honours the conventional HTTPS_PROXY, HTTP_PROXY and NO_PROXY environment variables. What catches people out is that it runs as a service, so it does not inherit the variables set in your interactive shell — proving the proxy works with curl at a prompt tells you nothing about what the service sees.

Set them on the service instead. On Linux, with the foothold installed as root:

sudo systemctl edit frontier

Add the following, then save:

[Service]
Environment="HTTPS_PROXY=http://proxy.example.internal:3128"
Environment="NO_PROXY=localhost,127.0.0.1"

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart frontier

5. Check routing and network segmentation

If DNS resolves correctly and the allowlist is right, the remaining possibility is that the host has no route out at all.

# Does the host have a default route, and is the gateway the one you expect?
ip route

# Which interface and address is the host actually using?
ip addr

# Can the host reach its own gateway?
ping -c 3 <gateway-address>

Things to confirm:

  • The host is on the VLAN you think it is. A foothold placed on a management or quarantine VLAN frequently has no external egress at all, by design.
  • VLAN tagging is correct. A tagged interface on an untagged port produces exactly this symptom.
  • The interface has an address. On a network with no DHCP, a host will sit with a link-local address and appear connected while reaching nothing.

For the OVA appliance specifically, network settings are configured during the guided setup. See Fixing network settings on the OVA.

6. Re-test without the installer's connectivity checks

Once you believe the path is open, re-run the installer. If you are confident the network is correct and the installer's own pre-flight checks are what is blocking you — for example, because ICMP is blocked and ping cannot establish a connection — you can skip them:

./fdrop-linux-x64 --no-connectivity-check

This only skips the checks. It does not change what the foothold needs once it is running, so if the outbound path is genuinely blocked, the deployment will install and then sit at Not Set Up.

Need help? If the host still cannot reach the platform after these checks, send us the output of the three curl commands in section 1 along with the details listed in What to send us. Reach out to your BreachLock representative or email support@breachlock.com.