Networking & Security

Network Architecture

Astra operates on a self-contained local area network that requires no external internet connectivity. The current prototype uses a self-contained LAN. In a Gateway deployment, the system would connect to the station's internal network infrastructure. The design mirrors the operational reality of a space station, where computing infrastructure runs on an isolated internal network that is not directly accessible from the public internet.

Network Router LAN

The foundation of Astra's network is a GL.iNet network router running OpenWrt firmware. This device serves dual roles as both the central network switch and the WiFi access point.

Parameter	Value
LAN subnet	10.0.0.0/24
WiFi SSID	infra-net
WiFi security	WPA3-PSK (password protected)
DHCP range	10.0.0.100--200
Router admin panel	http://10.0.0.1

The network router's WAN port has been converted to a LAN port, providing three physical LAN ports. Each LAN port connects to one of the three PoE switches, which in turn connect to the computing devices in each power domain.

All 9 computing devices have static IP addresses on the 10.0.0.0/24 subnet, assigned via NetworkManager on each device:

Device Group	IP Range
Cluster 1 nodes	10.0.0.11, 10.0.0.12
Cluster 2 nodes	10.0.0.21, 10.0.0.22
Cluster 3 nodes	10.0.0.31, 10.0.0.32
AI servers	10.0.0.41, 10.0.0.42, 10.0.0.43
Keepalived VIP	10.0.0.50 (virtual, floats between node1s)

Network Topology

           WiFi Clients (demo attendees)
                        |
                   [infra-net WiFi]
                        |
               +--------+--------+
               |  Network Router  |
               |  10.0.0.1       |
               +--+-----+-----+-+
                  |     |     |
          +-------+  +--+--+  +-------+
          | PoE   |  | PoE |  | PoE   |
          | Sw. 1 |  | Sw.2|  | Sw. 3 |
          +--+--+-+  +-+--++  +-+--+--+
             |  |      |  |     |  |
           N1  N2    N1  N2   N1  N2
           AI1       AI2      AI3

Why a Self-Contained Network

The system must be demonstrable in any location -- classrooms, conference halls, NASA facilities -- without depending on existing network infrastructure. A compact network router provides a completely self-contained LAN and WiFi access point in a device small enough to fit inside the rack enclosure. Demo attendees connect their personal devices to the WiFi and access Astra immediately, with no coordination with facility IT departments required.

This also mirrors the space station use case: the system brings its own network infrastructure and does not depend on any external network services. In a Gateway deployment, the router would be replaced by the station's internal network switch, and the devices would connect directly to the station's LAN.

Remote Management Access

For ground-based development and testing, a secure mesh VPN provides remote management access to all devices. This allows operators to SSH into any device, monitor services, and troubleshoot issues from any network.

Remote management is not required for operation

Remote management access is strictly a ground-development tool. The demo itself -- including the web interface, AI inference, database replication, and failover -- runs entirely on the LAN (10.0.0.0/24). In a flight deployment where all devices are on the same physical network, remote management access would not be needed.

Air-Gapped Design Philosophy

Astra is designed to operate with zero internet connectivity. This is not merely a convenience feature -- it is a fundamental design requirement that mirrors the operational reality of deep-space missions.

Why Air-Gapped

On the International Space Station, computing systems operate on internal networks that are isolated from the public internet. On future deep-space missions (Moon, Mars), internet connectivity will be intermittent at best and nonexistent at worst. Communication delays of up to 24 minutes one way make real-time cloud services impractical.

Astra's air-gapped design ensures that every component of the system functions without any external network dependency:

Component	Offline Implementation
AI inference	Local Ollama servers with pre-loaded models on the LAN
Embedding models	Pre-cached at /opt/owui-cache/ (924 MB) on every node1
Container images	Pre-cached on every node -- no container registry pulls
Application code	Deployed via Helm chart with pre-pulled images
Database	Local PostgreSQL on each node1
Network	Self-contained network router LAN and WiFi
DNS	Not required -- all connections use IP addresses

Offline Operation Flags

Two environment variables enforce offline behavior in the application layer:

• HF_HUB_OFFLINE=1 -- Prevents the HuggingFace library from attempting to download models or configurations from the internet
• TRANSFORMERS_OFFLINE=1 -- Prevents the Transformers library from making any network requests

Without these flags, the libraries would attempt network downloads on every application startup, causing either indefinite hangs or crash failures in an offline environment.

Security Model

Authentication Layers

Astra implements authentication at multiple levels:

Application layer (Open WebUI):

• User authentication is enabled (WEBUI_AUTH=True)
• All users must log in with email and password
• Passwords are hashed using bcrypt before storage
• Session cookies are cryptographically signed with WEBUI_SECRET_KEY
• The secret key is shared across all clusters to maintain session validity during failover

Database layer (PostgreSQL):

• Database connections require username and password authentication
• Authentication method: md5 (configured in pg_hba.conf)
• Access is restricted to the openwebui database user and the replicator replication user
• pg_hba.conf explicitly defines which hosts and users can connect

Network layer (WiFi):

• The infra-net WiFi network uses WPA3-PSK encryption
• WPA3 provides Simultaneous Authentication of Equals (SAE), which is resistant to offline dictionary attacks
• Only devices with the WiFi password can access the LAN

Management layer (ground development):

• Remote management access requires VPN authentication (device-level cryptographic keys)
• SSH access requires a valid user account on the target device
• Management access is independent of the demo network and would not be present in a flight deployment

Physical Security

The DeskPi RackMate T1 enclosure provides physical containment for all computing hardware. In a space station deployment, the rack would be secured inside a stowage locker, limiting physical access to authorized crew members.

The network router and PoE switches are also contained within or adjacent to the rack, minimizing the physical attack surface.

Air-Gapped Security Boundary

The air-gapped design means the primary security boundary is physical network access. The only network access path is through the router's WiFi (WPA3-protected) or wired LAN ports. The physical hardware is contained in a rack that is either in a controlled environment or (in the space station scenario) inside a secured module. There is no internet connectivity and no inbound connections from the public internet.

No Public-Facing Services

All public-facing services have been deliberately disabled:

• Cloudflare tunnels (cloudflared) are stopped and disabled on all nodes
• Nginx reverse proxy is stopped and disabled on all nodes
• No ports are exposed to the public internet
• The system is accessible only via the LAN (for demo users) or the management VPN (for remote development)