TAK Server Federation: Connecting Multiple TAK Networks Across Units and Commands

By Corvus Intelligence Engineering Team · About the team →

May 29, 2026 13 min read

A recurring friction point in joint and coalition operations is the disconnected TAK island: Unit Alpha has its own TAK Server running in the forward area, Unit Bravo has a separate server two echelons up, and neither can see the other's tracks on the map. TAK Server federation is the protocol designed to solve this — it links two or more independent TAK Server instances so that CoT event streams flow bidirectionally across the boundary, giving every operator a unified common operating picture (COP) without collapsing the separate servers into a single point of failure. This guide covers the full federation path: architecture decisions, CloudTAK REST API configuration, legacy TAK Server XML configuration, group and CoT type filters, mutual TLS security, and a systematic testing procedure for verifying that tracks propagate correctly.

What is TAK server federation and why it matters

Federation is a server-to-server protocol that runs over TCP port 9000 with mutual TLS. When two TAK servers are federated, each establishes an outbound TCP/TLS connection to the other's federation port and begins forwarding selected CoT events received from its own clients. The result is that a soldier with ATAK connected to Server A sees, in near real time, the tracks of units whose ATAK clients are connected to Server B — and vice versa. No client-side configuration change is required: federation is entirely a server administrative function.

The operational cases that require federation rather than a single unified server include:

Multi-echelon deployments — forward company server and rear battalion server need shared awareness without all company traffic flowing to the rear.
Coalition operations — partnered forces operate on separate servers under separate administrative authorities; federation shares selected tracks without granting full administrative access to either party's server.
Resilience by design — two independent servers each serve a subset of clients; if one fails, the other continues operating for its clients, and federation restores automatically when connectivity returns.
Bandwidth management — filters on the federation link allow only operationally relevant CoT types to cross the boundary, reducing traffic on constrained tactical links.

Federation architecture: peer-to-peer vs hub-and-spoke

Before configuring a single link, plan the federation topology. The choice between peer-to-peer and hub-and-spoke has significant operational and technical consequences.

Peer-to-peer federation

In a peer-to-peer topology, every TAK server maintains a direct federation link to every other server in the network. With two servers this is trivially one link. With five servers it is ten links (n × (n−1) / 2), each requiring certificate exchange, firewall rules, and independent monitoring. The advantage is that a track travels in a single federation hop from source to destination: latency is minimized and the loss of any one server affects only the clients directly connected to it. The disadvantage is administrative complexity — adding a sixth server requires configuring five new links, exchanging certificates with five existing administrators, and updating five sets of firewall rules.

Hub-and-spoke federation

In a hub-and-spoke topology, a central hub server maintains federation links to all spoke servers; spoke servers connect only to the hub. A track originating on Spoke A travels to the Hub, which forwards it to Spoke B. This adds one federation hop and therefore increases end-to-end latency (typically 50–150ms for a well-connected hub) but dramatically reduces configuration burden. Adding a seventh spoke requires only one new link, one certificate exchange, and one firewall rule — all at the hub. The hub becomes the network's single point of federation failure: if it goes offline, all cross-spoke track sharing stops. Mitigate this with a redundant hub pair, or accept the risk if the hub sits in a hardened, high-availability location.

For two-server deployments, both topologies are identical. For three or more servers, hub-and-spoke is generally preferred in operational environments because it reduces configuration surface and simplifies troubleshooting. Use peer-to-peer only when latency requirements cannot tolerate the hub hop, or when you need cross-spoke communication to survive hub failure.

CloudTAK federation configuration

CloudTAK exposes federation management entirely through its REST API. There is no XML configuration file to edit — all federation links are stored in the CloudTAK database and managed through authenticated API calls. The CloudTAK admin UI also exposes a federation management panel, but the API is preferred for automation and reproducible infrastructure-as-code deployments.

Configuring an outbound federation link

First, place the remote server's CA certificate on your CloudTAK host at a path accessible to the container (e.g. /opt/cloudtak/ssl/remote-ca.pem). Then register the federation link:

# Obtain an admin token first
export ADMIN_TOKEN=$(curl -s -X POST https://tak.yourdomain.com:8443/api/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"YOUR_ADMIN_PASSWORD"}' | jq -r '.token')

# Register the federation link
curl -s -X POST https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "BN-TAK-Server",
    "address": "tak.battalion.mil",
    "port": 9000,
    "protocol": "tls",
    "ca_cert": "/ssl/remote-ca.pem",
    "bidirectional": true,
    "enabled": true
  }'

Check the link status after a few seconds:

curl -s https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.[].status'
# Expected: "connected"

Using federation.json for infrastructure-as-code

CloudTAK also supports a federation.json file mounted into the container, which defines federation links declaratively. This is useful for Terraform or Ansible-managed deployments where the API token is not available at provisioning time:

{
  "version": 1,
  "peers": [
    {
      "name": "BN-TAK-Server",
      "address": "tak.battalion.mil",
      "port": 9000,
      "ca_cert": "/ssl/remote-ca.pem",
      "bidirectional": true,
      "filters": {
        "cot_types": ["a-f-", "a-n-", "t-x-m-c"],
        "groups": ["Blue Force", "Command"]
      }
    }
  ]
}

Mount the file into the container by adding a volume entry to your Docker Compose service definition: ./federation.json:/app/config/federation.json:ro. CloudTAK reads this file at startup and creates the configured links if they do not already exist in the database.

Legacy TAK Server federation configuration

Legacy TAK Server (the official TAK.gov Java distribution) configures federation through two XML files: CoreConfig.xml and federation-server.xml, both located in /opt/tak/.

Enabling the federation server in CoreConfig.xml

Locate the <network> section and enable the federation listener:

<!-- CoreConfig.xml: enable federation listener -->
<network>
  ...
  <federation port="9000" v1Enabled="true" v2Enabled="true"
              useV1="false" useV2="true"
              allowMissionPackageUpload="false"
              missionPackageSizeLimit="157286400"
              missionPackageStartPort="8444"
              missionPackageStopPort="8448"/>
</network>

The v2Enabled="true" and useV2="true" settings enable the Federation v2 protocol, which is required for interoperability with CloudTAK. Federation v1 is legacy and should be disabled in new deployments.

Configuring federation peers in federation-server.xml

<?xml version="1.0" encoding="UTF-8"?>
<FederationServer>
  <Federation>
    <!-- Outbound connection to CloudTAK or another TAK Server -->
    <FederationOutgoing
      id="company-cloudtak"
      host="tak.company.mil"
      port="9000"
      reconnectInterval="5"
      maxRetries="10"
      fallback="false"
      enabled="true">
      <filtergroup direction="in" groupFilterName="BlueForce"/>
      <filtergroup direction="out" groupFilterName="BlueForce"/>
    </FederationOutgoing>
  </Federation>
</FederationServer>

Certificate enrollment for legacy TAK Server federation

Legacy TAK Server uses a Java KeyStore (JKS) for its federation trust anchors. Import the remote server's CA certificate before attempting the connection:

# Import the remote CA into the TAK Server federation truststore
keytool -import \
  -trustcacerts \
  -alias cloudtak-ca \
  -file /opt/tak/ssl/cloudtak-ca.pem \
  -keystore /opt/tak/certs/files/fed-truststore.jks \
  -storepass atakatak

# Restart TAK Server to apply changes
systemctl restart takserver

The default TAK Server keystore password is atakatak — change this in any operational deployment by updating the keystorePass value in CoreConfig.xml and re-importing all certificates into the new keystore.

Filtering: controlling what crosses the federation boundary

By default, all CoT events received by a TAK server from its clients are eligible to be forwarded to federation peers. In most operational deployments, this is too permissive. Filters allow administrators to pass only specific CoT types, groups, or callsign patterns across the federation boundary, reducing bandwidth consumption on constrained tactical links and preventing inadvertent information sharing.

CoT type filters

CoT types follow a hierarchical dot-notation scheme. Common operational types to allow across federation:

CoT Type Prefix	Description	Typical Federation Use
`a-f-`	Atom friendly	Always allow — friendly force tracks
`a-n-`	Atom neutral	Allow if shared COP includes neutral tracks
`a-h-`	Atom hostile	Allow only if classification permits sharing
`t-x-m-c`	Chat message	Allow for cross-unit ATAK chat
`b-`	Bits (sensor/data feeds)	Block by default — high volume, often sensitive

Group filters

ATAK clients are assigned to groups (teams) within the TAK Server — Blue, Red, Green, Maroon, Yellow, etc. Group filters on the federation link control which groups' events are forwarded. For CloudTAK, specify allowed groups in the federation API call:

curl -s -X PATCH https://tak.yourdomain.com:8443/api/federation/BN-TAK-Server \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "cot_types": ["a-f-", "a-n-", "t-x-m-c"],
      "groups": ["Blue", "Command", "Medevac"],
      "direction": "both"
    }
  }'

Events from groups not listed in the filter (e.g. a Red team that is internal to one unit) will not cross the federation boundary. This is the primary mechanism for information control in coalition or multi-unit federated networks.

Security: mutual TLS, certificate pinning, and revocation

Federation links carry tactical track data over adversarial networks. The security model must prevent both passive interception and active impersonation of a federation endpoint.

Security baseline: Every operational federation link must use mutual TLS. A one-way TLS link (server authenticates to client, but not vice versa) allows any host that can reach port 9000 to inject CoT events into your tactical picture by impersonating the federation peer. Never deploy federation with self-signed certificates unless the network path is physically isolated.

Mutual TLS between federation endpoints

Mutual TLS (mTLS) requires that both the connecting server and the accepting server present certificates during the TLS handshake, and that each trusts the other's certificate authority. The configuration steps differ between CloudTAK and legacy TAK Server:

For CloudTAK, mutual TLS on the federation port is enabled by default when a ca_cert is specified in the federation API call. CloudTAK presents its own server certificate (the same cert used for client connections) and validates the remote server's certificate against the specified CA. No additional configuration flag is required.

For legacy TAK Server, mutual TLS on port 9000 is controlled by the clientAuth attribute in CoreConfig.xml. Set clientAuth="need" on the federation connector to require client certificate presentation. The connecting server's certificate must be signed by a CA present in the federation truststore.

Certificate pinning

Certificate pinning goes beyond standard mTLS validation by constraining the accepted certificate to a specific certificate or CA fingerprint, rather than any certificate signed by a trusted CA. For federation links between known, fixed endpoints, pin the remote server's CA fingerprint in your federation configuration. In CloudTAK, this is done by specifying "ca_pin": "SHA256:<fingerprint>" in the federation peer definition. Compute the fingerprint with:

openssl x509 -in remote-ca.pem -noout -fingerprint -sha256 \
  | sed 's/://g' | awk -F= '{print $2}'

Certificate revocation

When a federation endpoint's certificate must be revoked — due to server compromise, decommissioning, or CA rotation — the process differs by implementation. For CloudTAK, delete the federation peer via DELETE /api/federation/{name} and remove the remote CA from the filesystem; the link will immediately close and cannot be re-established. For legacy TAK Server, remove the CA from the federation truststore using keytool -delete and restart the service. If the issuing CA supports CRL distribution points or OCSP, configure these in the Java security policy for online revocation checking — though this is impractical in disconnected environments.

Testing federation: CoT injection, track propagation, and latency

Never assume a federation link is working because the status endpoint reports connected. A connected status means the TCP/TLS session is established — it does not mean events are actually flowing and appearing on client maps. The only reliable test is end-to-end track injection and verification.

Injecting a test CoT event

Use a CoT injection script or the tak-inject utility to send a synthetic friendly ground unit track to Server A:

<?xml version="1.0" standalone="yes"?>
<event version="2.0"
  uid="FED-TEST-$(date +%s)"
  type="a-f-G-U-C"
  time="2026-05-29T12:00:00Z"
  start="2026-05-29T12:00:00Z"
  stale="2026-05-29T12:10:00Z"
  how="h-g-i-g-o">
  <point lat="48.1234" lon="24.5678" hae="200.0" ce="10.0" le="999999.0"/>
  <detail>
    <contact callsign="FED-TEST-ALPHA"/>
    <group name="Blue" role="Team Member"/>
  </detail>
</event>

Inject this CoT XML to Server A via TCP port 8089 (or via the CloudTAK REST API at POST /api/events). Then confirm the FED-TEST-ALPHA callsign appears on an ATAK client connected to Server B within 2–3 seconds.

Verifying track propagation via the admin API

Check the federation link's event counters on Server A to confirm events are being forwarded:

curl -s https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.[] | {name, status, events_forwarded, events_received}'

A healthy bidirectional link should show non-zero values in both events_forwarded (events sent to the peer) and events_received (events received from the peer) after the test injection.

Latency measurement

Federation latency is the time from CoT event ingestion on the source server to the event appearing on a client connected to the destination server. Measure it by timestamping the injection and recording when the track appears using an automated ATAK WebSocket listener or the CloudTAK events WebSocket at wss://tak.battalion.mil:8443/api/events. Expected latency breakdown:

Server A ingestion and DB write: 5–20ms
Federation TCP delivery to Server B: network RTT / 2
Server B processing and broadcast to clients: 5–30ms
Total (LAN/VPN): typically 30–100ms
Total (satellite/HF): 500ms–2s depending on link

If latency significantly exceeds the expected range, check for database write contention on Server B (monitor with pg_stat_activity), clock skew between servers, and TCP retransmission on the federation link path.

Common issues: certificate mismatch, NAT, clock skew, and firewalls

Federation link status shows "connecting" indefinitely. The TCP connection to port 9000 on the remote server is not succeeding. Verify the port is open: openssl s_client -connect remote-server:9000. If it times out, the firewall is blocking the connection. If it returns an SSL error, the port is reachable but certificate validation is failing — proceed to certificate troubleshooting.

TLS handshake failure: "certificate verify failed". The remote server's certificate is not signed by a CA in your trust store. Confirm you installed the correct CA (not the server certificate itself) and that the CA certificate has not expired. For CloudTAK: openssl verify -CAfile /ssl/remote-ca.pem <(openssl s_client -connect remote-server:9000 2>/dev/null | openssl x509). This should return stdin: OK.

Link shows "connected" but no tracks appear from the remote server. The most common cause is clock skew. Check the system time on both servers: date -u. If they differ by more than 5 minutes, CoT events from the server with the earlier clock will arrive already stale at the receiving server and be discarded. Configure NTP on both hosts and allow a few minutes for the clocks to converge before retesting.

Tracks visible on Server B but not on ATAK clients connected to Server B. This is a filter issue, not a federation issue — events are arriving at Server B but being filtered before reaching clients. Check the ATAK client's group assignment: if the incoming federated tracks are in group "Blue" but the receiving client is set to see only group "Red", the tracks will not appear. Also check that the client's ATAK version supports the CoT type of the incoming events.

NAT between federation peers causes intermittent disconnections. Stateful NAT devices drop TCP sessions that are idle for more than the NAT timeout (commonly 30–300 seconds). Federation links that carry low CoT event volumes may go idle long enough to hit this timeout. Configure TCP keepalive on the federation connection: for CloudTAK, set "keepalive_seconds": 60 in the federation peer definition. For legacy TAK Server, add -Dsun.net.client.defaultConnectTimeout=60000 to the JVM startup flags in setenv.sh.

Federation between CloudTAK and legacy TAK Server fails with "protocol version mismatch". Ensure legacy TAK Server is configured for Federation v2 (v2Enabled="true", useV2="true" in CoreConfig.xml). CloudTAK does not support the deprecated Federation v1 protocol. Legacy TAK Server versions older than 4.8 may not support Federation v2 — upgrade to at least 4.8 before attempting CloudTAK interoperability.

Connect Your TAK Networks Across Commands

We design and configure TAK Server federation topologies for defense and government organizations — including CloudTAK deployments, legacy TAK Server integration, and TAKpilot AI copilot for federated tactical pictures.

TAKpilot AI Copilot → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical software for defense and government organizations. Learn about our team →

Frequently Asked Questions

What is TAK server federation?

TAK server federation is the protocol that allows two or more separate TAK Server instances to exchange Cursor-on-Target (CoT) event streams in real time. When federation is enabled, units connected to Server A appear on the map of clients connected to Server B, and vice versa — creating a shared common operating picture (COP) across organizational or geographic boundaries without merging the servers into a single instance.

What port does TAK Server federation use?

TAK Server federation uses TCP port 9000 by default on both legacy TAK Server and CloudTAK. Both endpoints must have port 9000 open in their firewalls and reachable from the peer server's IP address. If a NAT or firewall sits between federation peers, the outbound connection is initiated by the configured primary peer; ensure the TCP session can be established through any stateful firewall in the path.

What is the difference between peer-to-peer and hub-and-spoke TAK federation?

In peer-to-peer federation, every TAK server maintains a direct federation link to every other server — O(n²) connections as the network grows. In hub-and-spoke federation, all servers connect to a single central hub server; each spoke only needs one federation link. Hub-and-spoke is operationally simpler and more resilient to spoke failures, but introduces the hub as a single point of failure and adds one hop of latency for cross-spoke CoT delivery.

Can CloudTAK federate with legacy TAK Server?

Yes. CloudTAK implements the TAK Server federation protocol and is interoperable with legacy TAK Server (both the official TAK.gov distribution and FreeTAKServer). The federation link is configured on the CloudTAK side via the REST API or federation.json file, pointing to the legacy TAK Server's federation port (default 9000). Mutual TLS certificates must be exchanged between the two deployments before the link can be established.

How do group filters work in TAK federation?

Group filters allow administrators to control which CoT events cross a federation boundary. In legacy TAK Server, filters are defined in federation-server.xml using CoT type prefixes (e.g., allow only 'a-f-' friendly force tracks, block 'b-' sensor events). In CloudTAK, filters are configured per federation link via the REST API as an array of allowed CoT types or callsign patterns. Events that do not match the filter are not forwarded to the federated server, reducing bandwidth and preventing inadvertent data sharing.

What certificates are required for TAK federation?

TAK federation uses mutual TLS: each server must present a certificate to the other, and each must trust the other's certificate authority. In practice, this means: (1) each server has a server TLS certificate signed by its deployment CA; (2) the CA certificate from each deployment must be added to the trust store of the other deployment. For CloudTAK, add the remote CA cert path in the federation API call. For legacy TAK Server, import the remote CA into the federation Java keystore using keytool.

How do I verify that TAK federation is working?

Inject a test CoT event directly into one server using a CoT injection tool or netcat, then verify the event appears on a client connected to the federated server. Use the CoT type 'a-f-G-U-C' (friendly ground unit) with a unique callsign so it is easy to identify. Check federation link status via the admin API (GET /api/federation on CloudTAK) — a healthy link shows status: 'connected' with a non-zero events_forwarded counter.

What causes clock skew to break TAK federation?

CoT events carry a 'stale' timestamp. If the receiving server's clock is more than 300 seconds (5 minutes) ahead of the sending server, it discards incoming events as already stale. In federated environments, this typically manifests as a healthy link status (TCP connected) but zero tracks appearing from the remote server. Fix by ensuring both federation endpoints synchronize to the same NTP source — ideally a GPS-disciplined NTP server in operational deployments.

How do I troubleshoot NAT traversal in TAK federation?

Federation connections are outbound TCP from the initiating server to the remote server's port 9000. If a NAT sits in the path, the outbound TCP session traverses the NAT and the response traffic returns on the same session — standard stateful NAT handles this. Problems arise with symmetric NAT or firewall rules that block the session by destination port. Verify connectivity with: openssl s_client -connect remote-server:9000. If the TLS handshake fails, the issue is firewall or certificate; if the connection is refused, the port is not open on the remote side.

Can TAK federation filter data packages and files, or only CoT events?

By default, TAK Server federation forwards CoT event streams only — tracks, chat messages, and CoT-encoded sensor feeds. Data packages (map tiles, shapefiles, DTED) and mission packages are not automatically replicated across federation links. To share data packages between federated servers, use the TAK Server Mission Sync feature or manually distribute packages to each server. CloudTAK's REST API provides a /api/package/sync endpoint that can push packages to a configured list of federation peers.