Security in modern infrastructure requires a defense-in-depth approach, blending perimeter defenses with strong identity verification and network segmentation. The RemoteRails architecture is designed with these principles at its core, ensuring that services remain secure, private, and resilient against unauthorized access.
This article breaks down the RemoteRails authentication and authorization model for the hyper-converged sovereign communications appliance incorporating Nextcloud, Office, Matrix, Vault, & Mail from the outermost network layer down to internal service segmentation.
1. Perimeter Defense: Network & DDoS Protection
The first line of defense in the RemoteRails model operates at the edge, mitigating volumetric and sophisticated attacks before they ever reach the application infrastructure.
- Network Level Firewall (Layer 3 & 4): Strict firewall rules drop all unexpected traffic at the network and transport layers. Only explicitly required ports are open, ensuring that internal services remain hidden from public internet scans.
- DDoS Protection (Layer 3, 4, & 7): Comprehensive DDoS mitigation absorbs volumetric attacks (like UDP reflections or SYN floods) at L3/L4, while L7 protection inspects HTTP/HTTPS traffic to block malicious requests, botnets, and application-layer floods.
2. Identity & Access Management (IAM) with Defguard
At the heart of the RemoteRails security model is Defguard, an enterprise-grade Identity Provider (IdP) and WireGuard VPN manager. Defguard acts as the central gatekeeper for all administrative and internal access.
Defguard Core & SSO Identity
Defguard Core handles identity management, providing Single Sign-On (SSO) capabilities (via OIDC/SAML) for all internal applications. This means users have a single, unified identity to access Nextcloud, Matrix, Vault, and other internal services, streamlining both access and auditing.
Strong Authentication (TOTP & Biometrics)
A username and password are no longer sufficient. Defguard enforces strict Multi-Factor Authentication (MFA). Accessing the VPN or logging into the SSO portal requires:
- TOTP (Time-based One-Time Passwords): Standard authenticator app support.
- Biometric / WebAuthn: Support for hardware security keys (YubiKey) or device-level biometrics (TouchID, Windows Hello) for phishing-resistant 2FA.
WireGuard Profiles & Defguard Gateway
To access the internal network, users must connect through the Defguard Gateway using WireGuard. Defguard automatically provisions and manages WireGuard profiles (keys and configurations) for authorized users. If a user is revoked in Defguard Core, their WireGuard access is instantly terminated, cutting off their access to the internal network.
3. Network Segmentation: Internal vs. External Access
RemoteRails employs strict network segmentation, dividing services into a private, zero-trust internal network and a heavily restricted external perimeter.
The Internal VPN Network (Secure Enclave)
These services are not exposed to the public internet. They are only accessible to authenticated users who have successfully established a WireGuard VPN connection through the Defguard Gateway.
- Nextcloud: The main web interface for files, calendars, and contacts.
- Office: Collaborative document editing (e.g., Collabora/OnlyOffice).
- Matrix: Internal chat and communication interfaces.
- Vault: Password and secret management (e.g., Vaultwarden/Bitwarden).
- Mail Administration: Admin dashboards and self-service portals for the mail server.
By placing these services behind the VPN, RemoteRails drastically reduces the attack surface, protecting vulnerable admin panels and sensitive data from zero-day exploits and brute-force attacks.
Externally Accessible Services
Certain services must communicate with the outside world to function properly. RemoteRails exposes only the absolute minimum required endpoints, heavily guarded by the edge protections mentioned in Section 1.
- Nextcloud Share Links: Publicly shared files and folders (e.g., sending a file to a client) are accessible externally, while the main login portal remains protected.
- Matrix Federation: If federation is enabled, the specific endpoints required to communicate with other Matrix servers are exposed, allowing cross-server chat without exposing the local web client.
- LiveKit & Coturn (NAT Traversal): Required for WebRTC (audio/video calls). These services handle STUN/TURN traffic to allow users to connect to calls regardless of their local network restrictions.
- Inbound Mail Exchange (SMTP): We expose only the absolute minimum required for email routing: port 25. This allows the server to receive inbound emails from external providers (like Gmail or Outlook) over the public internet. All client-facing protocols (IMAP, JMAP, and secure SMTP submission) are strictly airgapped and require an active VPN connection to access.
Ultimately, this zero-trust architecture ensures that while essential public services remain accessible, the core of the infrastructure—including administration panels and sensitive internal data—stays completely hidden. By layering network perimeter defenses with Defguard’s centralized IAM and strict WireGuard segmentation, RemoteRails provides a highly resilient and secure environment for self-hosted deployments.