Opening the network path

What to set on a secure web gateway, a proxy or a firewall so that members' web, desktop and phone apps work behind it: the hosts to allow, the hosts to exempt from TLS inspection and from response buffering, where to apply the rules, and the checks to run from a member's device. Do this before you roll the desktop app out (see Deploying the desktop app across an organisation).

This page is about the hosted service. A home edition runs on your own hosts, so its addresses are the ones you gave it.

Hosts to allow

A member's web, desktop or phone app reaches these hosts and no others on the hosted service. The list is the one the apps themselves are built from, and a test fails if an app starts to reach a host that is not on it.

No host is generated per member or per computer: the computer's screen is one host with the computer named in the path, so it needs no nested wildcard. If your gateway takes wildcards, *.botseon.com covers every row but botseon.com itself, which you list on its own.

All traffic is HTTPS on port 443. app.botseon.com streams the live updates of every open conversation; screen.botseon.com and voice.botseon.com carry WebSocket connections that stay open for as long as a member watches a computer or talks to a bot.

Sign-in through your own identity provider goes to your provider's own hosts, which you already allow. Phone notifications reach the phone through Apple's and Google's push services, as every app's do.

Exempt the hosts from inspection and buffering

Exempt every host in the table from TLS inspection and from response buffering. Chat, the computer link and voice are streams: a gateway that decrypts them, or holds a response until it is complete before passing it on, delivers the live updates in one late burst or not at all, and cuts the computer and voice sockets.

If your policy says the gateway must inspect these hosts, it must still allow:

• Event streams without buffering. Responses of type text/event-stream passed through as each line arrives, never held until the response ends.
• WebSocket upgrades. Connection: Upgrade and Upgrade: websocket on screen.botseon.com and voice.botseon.com, kept as a WebSocket after the upgrade.
• Long-lived connections with no forced timeout. A stream or socket stays open for as long as the member uses it, which can be hours; an idle or total-duration timeout on these hosts drops it.

Apply the rules everywhere

Apply the same rules to every gateway location and every profile, including the roaming profile and the off-network profile a laptop uses when it is not on your corporate network. A rule set on one profile and not another shows up as one of three symptoms:

• Chat works but the computer never connects. app.botseon.com is allowed and screen.botseon.com is not, or WebSocket upgrades are refused.
• It works on a hotspot but not on the corporate network. The office gateway inspects or buffers and the phone's connection does not.
• It works in the office but not at home. The rules are on the office location and not on the roaming or off-network profile.

Check a member's device

Run these from the member's own device, on the network where the problem is. On Windows, run them in PowerShell with curl.exe in place of curl, or in Windows Subsystem for Linux.

Which certificate each host presents

for host in app.botseon.com screen.botseon.com voice.botseon.com botseon.com updates.botseon.com; do
  printf '%s: ' "$host"
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
    | openssl x509 -noout -issuer
done

The expected issuer is a public certificate authority — Let's Encrypt (O = Let's Encrypt) or Google Trust Services (O = Google Trust Services). If a line names your own organisation or your gateway's vendor instead, the gateway is inspecting that host: exempt it. If a line is empty, the device could not open a TLS connection to the host at all: it is blocked.

That the computer host resolves

nslookup screen.botseon.com

An answer with one or more addresses is right. NXDOMAIN, can't find or no answer means the device's DNS (often the gateway's own resolver) does not resolve the host: chat will work and the computer will never connect. An answer of 0.0.0.0 or an address inside your own network means a DNS filter is blocking it.

The streaming check

curl -N https://app.botseon.com/api/network-check/stream

The check sends ten numbered lines, one a second, and needs no sign-in. The lines must arrive one by one, a second apart. If nothing appears for ten seconds and then all ten arrive at once, something in the path buffers responses: exempt app.botseon.com from buffering. If the lines stop before the tenth, something in the path cuts long connections.

What this page does not cover