Bivious customer guide¶

Good fit¶

Bivious is a good candidate when all of the following are true:

• A Device cannot run the Tailscale client but can run or already supports OpenVPN.
• A partner or customer network exposes a certificate-based OpenVPN client profile, and you need selected Tailscale users to reach specific IPv4 subnets behind it.
• Your organization already uses Tailscale for private network access.
• The Device needs access to a defined set of services rather than unrestricted access to the entire tailnet.
• You can run a dedicated Bivious Appliance near the Device or on a network the Device can reach.
• Your network team can create Tailscale tags, authentication keys, and grants.

Typical candidates include older controllers, appliances, cameras, and embedded systems that still provide a supported OpenVPN client.

Not supported in the current release¶

• Zero-trust providers other than Tailscale.
• Legacy-side protocols other than OpenVPN.
• macOS, Windows, Docker Desktop, or rootless container hosts for the Bivious Appliance.
• A Device that cannot use OpenVPN.
• A Remote Network profile that requires interactive credentials, references external files, uses TAP/bridged mode, or depends on IPv6.
• Full-tunnel or exit-node behavior, overlapping remote subnets, or customer DNS integration through a Remote Network.
• Assigning one Device to multiple Connectors at the same time.
• Giving every Device a separate Tailscale identity. The Connector is the Tailscale identity and policy boundary.

If your environment falls outside this boundary, you can still describe it in the Early Access form. Those responses help shape future product support.

Bivious Appliance¶

The Bivious Appliance is the self-hosted system you administer. It provides the HTTPS administration UI, accepts OpenVPN connections from Devices, manages Device credentials, and maintains the Connectors that join your tailnet.

There is one Appliance in the current product. You manage it through Overview, Connectors, Devices, Remote Networks, and Settings.

Connector¶

A Connector is one persistent Tailscale identity and one policy boundary. Its Tailscale tag determines which resources and ports its assigned Devices may use.

One Connector can serve several Devices when those Devices need the same tailnet permissions. For example, three warehouse cameras could share a Connector tagged tag:bivious-warehouse.

Device¶

A Device represents one physical legacy endpoint. Every Device receives:

• its own OpenVPN profile;
• its own certificate;
• a stable VPN IP; and
• exactly one assigned Connector.

Devices assigned to the same Connector keep their individual OpenVPN identities and VPN IPs, but resources on the tailnet see the Connector's Tailscale IP as the traffic source.

Access remains policy-controlled¶

Bivious does not create a second access-control system. Tailscale grants decide what the Connector identity may reach. If a Connector is allowed to reach only TCP port 443 on a tagged service, its assigned Devices receive only that access.

Bivious routes the Tailscale IPv4 range through the OpenVPN connection. It does not replace the Device's normal default route or become its general Internet gateway.

For a Remote Network, Bivious forwards only specific, accepted IPv4 subnet routes through the imported OpenVPN connection. It does not use that connection as a full-tunnel exit node. The remote Connector has its own Tailscale identity and tag; access still depends on route approval and grants for the intended users.

Fail-closed behavior¶

If a Device identity, assigned VPN IP, Connector mapping, or security state does not match Bivious configuration, Bivious blocks the traffic. The administration UI reports Action required rather than allowing partial or ambiguous access.

Supported host¶

Install Bivious on a dedicated physical or virtual Linux host with:

The installer checks the operating system, architecture, TUN support, Python, and other prerequisites before changing the host. It installs or updates the required networking runtime and HTTPS service when necessary.

Network access¶

Allow these connections:

The OpenVPN port is configurable. If the Appliance is behind NAT, forward the selected UDP port from the address used by Devices to the Appliance. No inbound Tailscale port is required for a Connector.

You need either a DNS hostname or an IP address that every Device can reach. A public Internet endpoint is not required when the Devices have a private routed path to the Appliance.

Address planning¶

Bivious uses two private address ranges:

• VPN Device subnet: 10.90.0.0/24 by default.
• Connector transit pool: 172.30.0.0/16 by default.

Neither range may overlap the Appliance management network, Device-side networks, existing private routes, or each other. Automatic addressing is the recommended first-run choice. Select custom ranges only when either default overlaps your environment.

Before importing a Remote Network, also check that its subnets do not overlap the Appliance, tailnet routes, or another Remote Network. Bivious rejects conflicting routes instead of advertising ambiguous paths.

Information to gather¶

Before installation and onboarding, have the following ready:

• the management IP address assigned to the Appliance;
• the hostname or IP address Devices will use for OpenVPN;
• the UDP port, if you will not use 1194;
• the Tailscale permission groups you want to represent as Connectors;
• one Tailscale tag for each permission group;
• one authentication key for each Connector; and
• the destinations and ports each Connector should be able to reach;
• for each Remote Network, its name, a supported self-contained .ovpn profile, the IPv4 subnets to expose, and the Tailscale tag and user grants.

1. Choose a tag for each permission group¶

Create one Connector for each distinct set of permissions. Use descriptive tags such as:

• tag:bivious-warehouse for warehouse Devices that need a particular service;
• tag:bivious-metering for meters that need a different destination; or
• tag:bivious-lab for isolated evaluation Devices.

Authorize an appropriate tailnet administrator to assign each tag. Tailscale's policy file reference describes tagOwners, grants, and available selectors.

2. Grant only the required access¶

The following HuJSON example lets the warehouse Connector reach HTTPS on a resource tagged tag:warehouse-service:

{
  "tagOwners": {
    "tag:bivious-warehouse": ["autogroup:admin"],
    "tag:warehouse-service": ["autogroup:admin"],
  },

  "grants": [
    {
      "src": ["tag:bivious-warehouse"],
      "dst": ["tag:warehouse-service"],
      "ip": ["tcp:443"],
    },
  ],
}

Merge the rule into your existing tailnet policy rather than replacing that policy. Review the complete result with the tailnet administrator. Tailscale's grants syntax reference provides the current rule format.

3. Create one authentication key per Connector¶

Create a tagged authentication key for each Connector with these properties:

• tagged with the Connector's intended tag;
• single-use;
• non-ephemeral, so the identity survives restarts; and
• pre-authorized when your tailnet uses Device Approval and the administrator intends enrollment to complete without a separate approval step.

Do not reuse a single-use key for two Connectors. The key is needed only for the initial enrollment or an explicit identity recovery. Bivious does not retain it after enrollment.

See Tailscale's server provisioning guidance for the current authentication-key controls.

Self-install on a supported host¶

Sign in to the host with an account that can use sudo, then run:

curl -fsSL https://install.bivious.net | sudo bash

The installer:

1. checks the host operating system, architecture, TUN support, Python, and service manager;
2. installs or updates required runtime dependencies;
3. resolves and downloads the current Bivious package;
4. verifies the package SHA-256 checksum;
5. installs Bivious and starts its management service; and
6. configures HTTPS for the administration UI.

A successful new installation reports that the Bivious service is active, confirms the HTTPS service is active, and ends with :: done.

The command is safe to run again:

• If the installed release is current, it reports that nothing needs to be done and checks the surrounding services.
• If a newer release is available, it upgrades Bivious and restarts the service.
• It refuses to downgrade a host that already has a newer version.

Protect first-run setup with a bootstrap token¶

Bootstrap-token protection is optional. Without it, the first person who can reach the setup page can create the administrator account. Enable protection when people outside your trusted management network could reach the Appliance before setup is complete.

To have the installer generate a token, include this option in the install command. If you are using a preinstalled Appliance, run the command from its console or an authorized SSH session before opening the setup page:

curl -fsSL https://install.bivious.net |
  sudo bash -s -- --generate-bootstrap-token

The installer saves the token in a root-only file at /var/lib/bivious/bootstrap/token. Retrieve it from the Appliance using an authorized account with sudo:

sudo cat /var/lib/bivious/bootstrap/token

Keep the token private and enter it on the first-run setup page when prompted for the Appliance bootstrap token, then create the administrator password. After the administrator is created successfully, Bivious consumes the token and removes the generated token file.

For automated provisioning, you can provide a token through a protected file instead. It must contain exactly 64 lowercase hexadecimal characters; one trailing LF or CRLF newline is allowed. Keep the file accessible only to the installer and remove it through your provisioning system after setup; the installer leaves supplied input files in place:

curl -fsSL https://install.bivious.net |
  sudo bash -s -- --bootstrap-token-file /run/bivious-bootstrap-token

Do not put a token directly in the command line: command arguments may be visible in shell history or process listings. A normal installer rerun keeps existing token protection enabled.

Preinstalled Appliance¶

If your Early Access package is a preinstalled virtual machine, import it into your hypervisor, assign at least 2 vCPU, 2 GB RAM, and one network interface, then boot it. The Appliance uses DHCP initially. Obtain its assigned management address from DHCP or the hypervisor console and continue below.

Open the administration UI¶

In a browser on the management network, open:

https://<appliance-address>/

Replace <appliance-address> with the Appliance IP address or configured hostname.

When the Appliance has a private IP address, the initial HTTPS certificate is locally generated and the browser may display a certificate trust warning. Confirm that the address is your Bivious Appliance before continuing. When you configure a DNS hostname that resolves to the Appliance, Bivious can obtain a trusted certificate automatically.

1. Create the administrator password¶

The local administrator username is admin. Create and confirm a unique passphrase of at least 12 characters.

The administrator account controls the Bivious Appliance. Do not reuse a personal password or a password used on another system.

2. Configure Appliance connectivity¶

Enter the public hostname or IP address that Devices will use to reach Bivious. Enter a hostname or IP only, without https://, a path, or a port.

OpenVPN uses UDP. Keep the default port 1194 unless your network plan requires another port between 1 and 65535. If the Appliance is behind NAT, confirm that the selected UDP port is forwarded to it.

The OpenVPN endpoint and the administration address have different purposes:

• The administration address is where an administrator opens the Bivious UI.
• The public OpenVPN endpoint is embedded in every generated Device profile and must be reachable by those Devices.

They may resolve to the same Appliance, but do not assume they are always the same address.

3. Choose network addressing¶

Select Automatic (Recommended) to use:

• VPN Device subnet 10.90.0.0/24; and
• Connector transit pool 172.30.0.0/16.

If either range overlaps your networks, select Custom / Advanced and enter two separate, canonical RFC 1918 IPv4 ranges. Bivious validates the ranges before applying them.

Bivious rejects range changes that would invalidate existing Device or Connector allocations. Choose custom ranges before creating allocations if you already know the defaults conflict with your environment.

Select Configure appliance after reviewing the values.

4. Create the first Connector¶

Enter:

• a descriptive Connector name, such as Warehouse cameras;
• the Tailscale authentication key created for this Connector; and
• its tag, such as tag:bivious-warehouse.

Select Connect to Tailscale. Bivious uses the key for enrollment and does not store it. Wait for the Connector to become Healthy before assigning Devices.

In the Tailscale administration console, confirm that the new node has the expected tag and identity. Do not broaden its policy merely to make an initial test pass; correct the tag or grant instead.

5. Create the first Device¶

Enter a descriptive Device name, such as Parking camera 01, and select the Connector whose Tailscale identity and permissions the Device should use.

Select Create Device. Bivious allocates the Device's certificate and stable VPN IP automatically. The Device begins in Waiting for connection.

6. Download and deliver the OpenVPN profile¶

Select Download OpenVPN profile. The .ovpn file contains the Device's private key and must be treated as a secret.

Transfer the profile only to the intended Device using an approved protected channel, such as SFTP, SCP, or your organization's secrets-transfer system. Do not attach it to ordinary email, paste it into a ticket, or reuse it for another Device.

Import the profile into the Device's OpenVPN client and start the connection. For a Linux test Device with OpenVPN installed, the equivalent command is:

sudo openvpn --config parking-camera-01.ovpn

The Device needs outbound UDP connectivity to the configured Bivious endpoint. It does not need the Tailscale client.

You may finish onboarding before the physical Device connects. Bivious keeps the Device in Waiting for connection and updates its status after the first accepted session.

1. Confirm the OpenVPN profile is supported¶

Ask the remote network administrator for a client .ovpn profile that:

• uses certificate-based, non-interactive authentication;
• includes its client certificate, matching private key, CA certificate, and any required TLS key inline, rather than referring to separate files;
• uses IPv4 TUN mode; and
• connects to the remote OpenVPN endpoint over the protocol and port shown in the profile.

Profiles that require a username or password, MFA/OTP, SAML, browser sign-in, or another interactive prompt cannot be imported. TAP/bridged mode, IPv6, full-tunnel/default-route behavior, and customer DNS integration are not supported. Bivious forwards specific accepted IPv4 subnets only. Check those subnets for overlap with the Appliance, tailnet routes, and other Remote Networks before you begin.

The Appliance makes an outbound connection to the OpenVPN endpoint in the profile. Allow that protocol and destination through the Appliance's outbound firewall. No inbound port is needed for this Remote Network connection.

2. Prepare Tailscale access¶

In the tailnet policy, authorize a dedicated tag for the Remote Network's Connector identity and define which users or groups may reach the specific remote subnet and ports. Prepare a tagged, single-use Tailscale authentication key for that tag. Make it non-ephemeral so the Connector identity persists. Keep route approval and user grants in the plan: they are separate controls.

3. Validate and import the profile¶

1. Sign in to the Appliance and open Remote Networks.
2. Select Add Remote Network, enter a descriptive name, and choose the .ovpn profile.
3. Select Validate profile and review the normalized findings. Correct an unsupported or invalid profile with the remote network administrator before continuing.
4. Enter the tagged authentication key and the authorized Tailscale tag, then select Import Remote Network.

The profile and embedded private key are sent to the authenticated Bridge Manager for import and are never shown again in the UI. The authentication key is used once to create the Connector identity and is not retained. The Remote Network is imported in a stopped state.

4. Connect and review routes¶

Open the Remote Network and select Connect. Wait for the connection and data path to report healthy. The details show its lifecycle, health, transport, Connector/Tailscale identity, forwarding, data path, and route state:

• Discovered lists subnets found through the OpenVPN connection.
• Advertised lists safe specific routes offered to Tailscale.
• Rejected lists routes Bivious did not offer, with a reason and any detected conflict.

A Tailscale administrator must approve the advertised subnet routes in the Tailscale admin console. The administrator must also configure grants for the intended users or groups and the required destination ports. Advertisement alone does not approve a route or give every tailnet user access. Test both an allowed destination and a destination that the grants should deny.

Understand status¶

An Offline Device is not automatically a security problem. Action required and Degraded identify conditions that need investigation.

Manage a Remote Network¶

Open Remote Networks and select the network to view its connection, recovery, and route details. Use Disconnect to stop its tunnel temporarily, Reconnect to restart it, or Connect to start a stopped network. If an import was interrupted, use Resume import and provide the same authorized tag used for the original import.

Deleting a Remote Network is permanent. Confirm the name when prompted. Bivious stops the connection and removes its local credentials, runtime, and route state. Then remove the remaining Connector node from the Tailscale admin console. Deleting the local record does not remove that node automatically.

Add a Device to an existing Connector¶

Use this path when the new Device should have the same Tailscale permissions as Devices already assigned to a Connector:

1. Open Devices and select Add Device, or open the Connector and select Add Device.
2. Enter the Device name.
3. Select the existing Connector.
4. Create the Device and download its OpenVPN profile.
5. Transfer the profile securely and verify the connection.

No new Tailscale authentication key or policy change is needed when the existing Connector already represents the correct permission group.

Add a different permission group¶

When a Device needs different destinations or ports:

1. Add a dedicated tag and least-privilege grant to the tailnet policy.
2. Create a new tagged, single-use, non-ephemeral authentication key.
3. Open Connectors, select Add Connector, and enroll it with that key.
4. Wait for the Connector to become Healthy.
5. Create the Device and assign it to the new Connector.

Do not create separate Connectors merely to give Devices different display names. A Connector should represent a meaningful policy boundary.

Download a Device profile¶

Profile download is available for a Device that is waiting, Online, or Offline with an active credential. It is unavailable while the Device is provisioning, when its configuration requires administrator action, or after revocation.

Downloading the profile again produces another copy of the same sensitive Device credential. Protect and remove unnecessary copies.

Change connectivity settings¶

Open Settings and use Connectivity to change the public OpenVPN hostname or IP and UDP port.

The endpoint and port are embedded in Device profiles. Bivious regenerates its retained copies for every active Device without changing their certificate, private key, VPN address, or Connector. If ingress is running, Bivious applies and verifies the listener update before showing success; a stopped ingress is left stopped for its normal next start.

Copies that you previously downloaded cannot be changed remotely. After an endpoint or port change, confirm DNS, NAT, and firewall rules, download a fresh profile for each affected active Device, and redistribute it through your approved protected channel. Do not distribute a refreshed profile for a revoked Device: its profile remains unavailable.

Change network ranges¶

Open Settings and use Network to review new private ranges. Bivious validates the change before writing configuration and rejects any range that overlaps or would invalidate existing Device or Connector allocations. It does not automatically migrate addresses.

Schedule a range change before creating allocations, or plan a controlled replacement of affected resources. Confirm the new ranges do not overlap the management network, Device networks, private routes, or each other.

Update Bivious¶

Run the installation command again on the Appliance:

curl -fsSL https://install.bivious.net | sudo bash

If a newer release is available, the installer verifies and applies it. If the installed release is current, the command completes without reinstalling it. Review Connector and Device health after an update.

Restart the Appliance¶

Use the normal operating-system or hypervisor restart procedure. Bivious keeps Connector identities and product state across ordinary restarts. After the host returns, open Overview and confirm that the Appliance and Connectors recover to Healthy.

If a create, retry, deletion, revocation, or connectivity update was running when the Appliance stopped, Bivious does not repeat it automatically. Its operation is recorded as interrupted and the affected resource is shown as Action required. Review the resource, then use its explicit retry or deletion action, or submit the configuration update again. If revocation was interrupted, profile download and traffic remain blocked; select Retry finishing revocation rather than trying to reprovision the Device. The manager verifies the data-plane block before accepting requests. If it cannot, the manager does not start: restore the runtime access block, then restart it.

Revoke a Device¶

Revocation is a permanent security action, not the same as taking a Device offline.

1. Open the Device detail page.
2. Select Revoke Device.
3. Review the listed consequences.
4. Type the Device name exactly to confirm.
5. Wait for the operation to finish.

Successful revocation:

• disconnects an active Device session;
• revokes the Device certificate;
• removes its network authorization;
• prevents its existing OpenVPN profile from reconnecting; and
• retains a Revoked Device record for audit and status history.

Other Devices, including Devices assigned to the same Connector, remain authorized. To replace the physical Device later, create a new Device with a clearly distinguishable name and a new profile.

If the UI reports that revocation needs attention, the profile download remains disabled and traffic remains blocked. Select Retry finishing revocation to complete and verify the cleanup.

Delete a Connector¶

A Connector cannot be deleted while active Devices are assigned to it. Revoke those Devices first and confirm their terminal state.

Deleting an eligible Connector removes its Tailscale identity from Bivious and cannot be undone. Bivious does not silently revoke Devices or perform cascading deletion.

Protect authentication keys¶

• Create a separate Tailscale authentication key for each Connector.
• Use a tagged, single-use, non-ephemeral key.
• Enter it only in the Bivious enrollment or recovery form.
• Never store it in documentation, tickets, scripts, or source control.
• Delete or revoke an unused key in Tailscale.

Bivious uses the key for enrollment and removes it from the long-lived Connector configuration afterward.

Protect OpenVPN profiles¶

Every .ovpn profile contains a private key. Anyone who obtains an active profile may attempt to connect as that Device.

• Transfer the profile through an approved protected channel.
• Store it with access limited to the intended Device and administrators who need it.
• Do not share a profile between Devices.
• Remove staging and download copies after delivery.
• Revoke the Device immediately if its profile may have been exposed.

A Remote Network's .ovpn profile also contains private-key material. Upload it only through the authenticated Appliance UI, where it is sent to Bridge Manager for import and is never shown again. Do not send the profile to support or place it in tickets, email, scripts, or source control. If its credentials may have been exposed, ask the remote network administrator to revoke or replace them, then import a replacement profile.

Protect internal Device identities¶

The certificate authority and OpenVPN server use the internal identifiers ca and bivious-server. Bivious reserves both identifiers so a Device can never overwrite or download those credentials. The administration UI retains a descriptive Device name while assigning a safe internal ID when needed. If you use the CLI directly, do not issue, revoke, render, or remove a Device named ca or bivious-server; those commands are rejected.

Do not edit PKI files to work around a reserved identifier. If an older state record uses one, leave its credentials untouched and contact support with the record and Appliance diagnostics for a recovery plan.

Certificate revocation list maintenance¶

The installed Bridge Manager checks the certificate revocation list (CRL) when it starts and hourly afterward. It renews a missing or soon-expiring CRL before it has seven days remaining and repairs a CRL that does not yet contain a revocation recorded by the certificate authority. It verifies the replacement and keeps the existing valid CRL if publication fails. Revoked Devices remain revoked during renewal.

For a CLI-only installation without Bridge Manager, run this during normal maintenance or after a warning about CRL expiry:

sudo bivious pki refresh

The command reports whether it renewed the CRL or found the current one still valid. Investigate a nonzero result; do not disable revocation checks or remove the current CRL as a workaround.

Apply least privilege¶

The Connector's Tailscale tag and grants define which destinations and protocols are reachable through that identity. Give each Device Connector only the access its group requires. For a Remote Network, approve only the specific subnet routes that are needed and grant access only to the intended users or groups and ports. Test a denied destination after every material policy change.

Because several Devices may share one Connector identity, use individual Bivious Device records and status information to distinguish them operationally. The destination service sees the Connector's Tailscale IP, not the Device's Bivious VPN IP.

Back up the complete Appliance¶

A usable recovery set must preserve both:

• Bivious product and credential state, including its local certificate authority, non-revoked Device profiles, and imported Remote Network credentials; and
• the persistent Tailscale identity for every Connector.

The recommended approach is an encrypted, access-controlled backup or snapshot of the complete Appliance, taken according to your hypervisor or host backup procedure. Treat the backup as a high-value secret because it contains signing and Device credential material.

Restoring only product configuration without the persistent Connector identities does not restore the same Tailscale nodes. A lost Connector identity requires a new authentication key and may leave an old offline node that a tailnet administrator must remove.

Losing a Device-side profile does not revoke it. If the Device record remains active and profile download is available, securely download another copy. If the profile may be in unauthorized hands, revoke the Device instead.

Installation stops during preflight¶

Correct the reported prerequisite, then run the installation command again. The installer performs its checks again and resumes from the host's current state.

The administration UI is unreachable¶

1. Confirm the Appliance is running and has the expected management IP.
2. Confirm TCP ports 80 and 443 are allowed from the management network.
3. Open https:// rather than http://.
4. If DNS is used, confirm it resolves to the Appliance address.
5. If the IP changed after DHCP renewal, use the new address and update the relevant DNS or reservation.

For a private IP address, a browser certificate warning can be expected during initial setup. Verify the Appliance address before accepting it. A connection timeout or refusal is not a certificate-warning issue; check reachability and firewall rules first.

Connector enrollment fails¶

Check that:

• the authentication key was copied completely and has not expired or already been consumed;
• the key is tagged for the intended Connector identity;
• the Appliance can reach Tailscale over the Internet;
• Device Approval requirements are satisfied; and
• the tailnet policy recognizes the advertised tag.

For a failed or Action required Connector, use the retry action and provide a new valid authentication key when prompted. Bivious keeps assigned Device traffic blocked until the Connector is usable.

The Device cannot establish OpenVPN¶

Check the path in this order:

1. The profile belongs to this Device and has not been revoked.
2. The profile contains the current Bivious hostname or IP and UDP port.
3. The Device can resolve the hostname, if one is used.
4. Outbound UDP is allowed from the Device network.
5. NAT and firewall rules deliver that UDP port to the Appliance.
6. The Device clock is reasonably accurate.
7. The assigned Connector is Healthy.

If the UI reports Connection rejected or Action required, Bivious has blocked an identity or assignment mismatch. Confirm the selected Connector and Device profile rather than attempting to bypass the state.

OpenVPN connects but the resource is unreachable¶

Confirm:

• the Device is Online in Bivious;
• the assigned Connector is Healthy;
• the Connector has the expected Tailscale tag and IP;
• the target is online and listening on the expected port;
• the Tailscale grant uses the Connector tag as its source and includes the correct destination and protocol; and
• the Device is trying to reach a Tailscale address rather than expecting Bivious to route arbitrary Internet traffic.

Test another known permitted service only if it uses the same intended policy. Do not temporarily grant the Connector unrestricted tailnet access.

A Remote Network profile is rejected or its connection fails¶

Review the normalized findings shown by Validate profile. Confirm the profile is self-contained, has a matching client certificate and private key, uses certificate-based non-interactive authentication and IPv4 TUN mode, and does not require external files, interactive login, or unsupported options. Ask the remote network administrator for a compatible profile if needed.

If import succeeds but the network does not connect, check the Appliance's outbound firewall path to the profile's OpenVPN endpoint, the endpoint and certificate configuration, and the Remote Network's transport health. Review any Rejected route and its conflict details. Do not add a default route or broaden the Tailscale policy as a workaround.

If an advertised route is not reachable from a Tailscale client, confirm a Tailscale administrator approved that route and that grants allow the client user or group to reach the destination and port.

A Connector is Degraded¶

Open the Connector detail page and read the plain-language health breakdown. Assigned Devices may be unable to reach the tailnet while the Connector is Degraded. Confirm Appliance Internet connectivity and use Retry connection when offered.

Bivious reports Action required¶

Open the affected Connector or Device from the Overview callout. Bivious explains the impact and recommended action outside Advanced diagnostics. Follow that action first. Traffic remains blocked until the identity and configuration are consistent.

Revocation needs attention¶

The Device credential or network authorization may already be disabled even if the full cleanup could not be verified. Profile download remains unavailable. Use Retry finishing revocation until the Device reaches Revoked. Do not create replacement access for the same Device name while reconciliation is incomplete.

Information to provide to Early Access support¶

It is safe and useful to provide:

• Bivious version;
• host operating system and architecture;
• Appliance, Connector, and Device display names;
• the status and user-facing error message;
• the time the problem occurred;
• the configured hostname or public IP and port, if they are not sensitive in your environment;
• the expected target and protocol; and
• whether the same action succeeds after retrying.

Do not send:

• a Tailscale authentication key;
• an .ovpn profile;
• certificate or private-key material;
• administrator passwords;
• an Appliance backup; or
• unreviewed diagnostic exports that may contain secrets.

Does the legacy Device need Tailscale?¶

No. The Device uses OpenVPN to reach the Bivious Appliance. The assigned Connector is the Tailscale node.

Does Bivious replace Tailscale policy?¶

No. Tailscale grants remain the authority for which resources and ports a Connector may reach.

Can several Devices share one Connector?¶

Yes. This is the expected model when those Devices need the same permissions. Each Device still has its own OpenVPN profile, certificate, VPN IP, and status.

Does every Device appear separately in Tailscale?¶

No. Tailscale and destination services see the Connector identity. Bivious keeps the individual Device identities on the OpenVPN side.

Does Bivious send all Device traffic through Tailscale?¶

No. Bivious routes the Tailscale IPv4 range through the OpenVPN connection. It does not replace the Device's normal Internet default route.

Can Tailscale users reach a network behind an OpenVPN endpoint?¶

Yes. In 0.4.0, create a Remote Network with a supported certificate-based OpenVPN client profile. Bivious advertises specific IPv4 subnet routes through a dedicated Connector identity. A Tailscale administrator must approve the routes and configure grants for the intended users.

Does route advertisement mean every Tailscale user has access?¶

No. A Tailscale administrator must approve advertised routes and set grants that authorize the right users or groups and destination ports.

Can a Remote Network use an interactive VPN login or a full tunnel?¶

No. Remote Network profiles must be self-contained, certificate-based, and non-interactive. Bivious supports specific IPv4 subnets over TUN; it does not support username/password or MFA prompts, TAP/bridged mode, IPv6, customer DNS integration, or full-tunnel/exit-node routes.

Can a Device use two Connectors?¶

No. A Device is assigned to exactly one Connector. Create permission groups that reflect the access the Device actually needs.

Can I move an existing Device to another Connector?¶

The current release does not provide an in-place reassignment workflow. Revoke the existing Device when its access should end, then create a new Device with a clearly distinguishable name and assign it to the correct Connector.

Can a revoked Device be restored?¶

No. Revocation is permanent. Create a new Device and securely deliver its new profile.

Does Bivious support WireGuard or another legacy-side protocol?¶

No. Legacy Devices connect to the Appliance with OpenVPN over UDP. Remote Networks support certificate-based OpenVPN client profiles using their configured IPv4 TCP or UDP transport. Tailscale continues to use its own WireGuard-based network internally; the legacy Device does not need to support that protocol.

Does Bivious support other zero-trust providers?¶

Not in the current release. Tailscale is the supported zero-trust integration. You can describe demand for another provider in the Early Access form.

Is Bivious a cloud service?¶

No. The Bivious Appliance is self-hosted in your environment. It uses the external services required for software installation, HTTPS certificates, and Tailscale coordination.

What happens after a restart?¶

Bivious retains product state and Connector identities across an ordinary host restart. Check Overview afterward and allow Connectors time to return to Healthy.