Ctrlk
SupportDashboard
For the complete documentation index, see llms.txt. This page is also available as Markdown.

FenixPyre On-Prem Deployment Guide

A clear, step‑by‑step guide designed for any client environment - Azure, AWS, GCP, or private datacenters. This guide not only explains how to set up the system, but also why each piece matter

1. Introduction

FenixPyre On‑Prem enables organizations to securely store, encrypt, and share sensitive files without exposing data to the cloud. This document explains:

  • What components are required

  • How the architecture works

  • Why certain security boundaries must exist

  • How to correctly set up networks, subnets, firewalls, and certificates

  • How the system communicates with the FenixPyre Cloud (control‑plane only)

This applies to all infrastructures-Azure, AWS, GCP, or private datacenters.

2. Core Architecture Concept

Every deployment must follow a segmented three‑zone security model, regardless of cloud provider or datacenter layout.

Internet
   ↓
DMZ Subnet (Reverse Proxy)
   ↓
Internal Subnet (On-Prem FP Server)
   ↓
Management Subnet (Admin Access)

Why this model is required

  • It prevents direct exposure of sensitive systems

  • DMZ isolates public traffic from private systems

  • Internal subnet hosts the protected FP server (no public IP)

  • Management subnet ensures SSH/admin access without exposing internal services

This segmentation is aligned with CMMC, NIST 800‑171, and Zero Trust principles.

3. Components and Their Purpose

Understanding each component helps teams deploy confidently.

1. Reverse Proxy (NGINX) - In DMZ

Acts as the public‑facing entry point.

  • Accepts HTTPS from users/agents

  • Validates TLS

  • Re-encrypts traffic to the on-prem backend

  • Shields internal systems from direct access

2. FenixPyre On-Prem Server - In Internal Subnet

The core application service.

  • Handles agent sharing/upload/download flows

  • Exposes APIs protected behind the proxy

  • Never exposed to the internet

3. Optional Management VM - In Management Subnet

Used for:

  • SSH access

  • Monitoring

  • Maintenance

  • Logging components (optional)

4. Network Setup (Vendor-Neutral)

This is the most critical section for correct deployment.

4.1 Create Three Subnets

Use any local IP ranges (RFC1918), e.g.:

Why three subnets?

  • DMZ is intentionally semi‑exposed (public IP allowed)

  • Internal subnet remains fully private

  • Management subnet allows secure administration without opening SSH to the world

5. Firewall Rules & Ports (All Clouds / Datacenters)

Below is a universal firewall rule set.

5.1 Inbound Traffic Rules

DMZ Subnet

Source
Dest
Port
Why

Internet

Reverse Proxy

443

Public HTTPS access

Admin IPs

Reverse Proxy

22

SSH (setup only)

Internal Subnet

Source
Dest
Port
Why

DMZ

On-Prem FP

443

Secure backend traffic

Mgmt

On-Prem FP

22

SSH admin access

Mgmt

On-Prem FP

8080

Private API (mTLS)

5.2 Outbound Rules

Component
Dest
Port
Reason

On-Prem FP

Internet

443

Package installs, FP cloud callbacks

Proxy

Internal Subnet

443

Backend re-encryption

6. TLS Requirements

Correct certificate setup is essential.

6.1 Special Note: Port 80 Required for Let's Encrypt

If the client plans to use Let’s Encrypt for issuing TLS certificates on the reverse proxy, they must open port 80 (HTTP) temporarily or permanently.

Why:

  • Let’s Encrypt uses HTTP-01 challenge to validate domain ownership.

  • This requires inbound access from Internet → Reverse Proxy on port 80.

  • After the certificate is issued, traffic can still be redirected to HTTPS, but port 80 must remain reachable for renewals.

Recommended configuration:

  • Allow Internet → Reverse Proxy on port 80, but

  • Immediately redirect all HTTP traffic to HTTPS inside NGINX.

6.2 Reverse Proxy Certificate (Public CA)

Required for browsers and agents.

  • Issue via Let's Encrypt or enterprise CA

  • Installed only on DMZ reverse proxy

6.3 Backend Certificate (Self-Signed Accepted)

Used between:

Reverse proxy must trust this certificate:

This ensures end-to-end TLS. Correct certificate setup is essential.

6.1 Reverse Proxy Certificate (Public CA)

Required for browsers and agents.

  • Issue via Let's Encrypt or enterprise CA

  • Installed only on DMZ reverse proxy

6.2 Backend Certificate (Self-Signed Accepted)

Used between:

Reverse proxy must trust this certificate:

This ensures end‑to‑end TLS.

7. Cloud-Specific Logic

This guide works for all providers. Differences are minor:

Azure

  • Use NSGs on subnets

  • Use Bastion for SSH access

  • Avoid NIC-level NSGs

AWS

  • Use Security Groups per tier

  • Use a public ALB/NLB if desired

GCP

  • Use VPC firewall rules

  • Assign static external IP only to the DMZ VM

Datacenter / Bare-Metal

  • Use physical firewalls (Fortigate, Palo Alto, Sophos)

  • Use separate VLANs for DMZ, Internal, Mgmt

8. Deployment Flow (Step by Step)

This section provides a universal setup flow, including scenarios where clients already have DMZ or reverse proxy infrastructure.

8A. Using an Existing Client DMZ or Reverse Proxy

Many enterprise clients already operate a DMZ or public reverse proxy. Yes, they can use their existing DMZ, as long as it meets the following requirements:

✔ The existing DMZ must allow:

  • Public inbound traffic on 443 (and 80 if using Let's Encrypt)

  • Outbound access to the internal subnet on port 443

  • TLS termination and re‑encryption capability

✔ The existing reverse proxy must:

  • Support strict TLS (TLS 1.2/1.3 only)

  • Enforce CMMC/NIST-compliant cipher suites

  • Support backend TLS verification (trusting FP On-Prem backend CA)

  • Support header forwarding (X-Forwarded-*)

  • Support upload streaming (no forced buffering for large files)

If the client already uses:

  • F5 Big-IP

  • NGINX or NGINX Plus

  • Apache HTTPD

  • Envoy

  • HAProxy

  • Azure Application Gateway / AWS ALB (with TLS pass-through)

They can use their existing DMZ, provided the backend routing logic matches the documented configuration.

8B. Deploying a New Reverse Proxy Using Our Automated Script

If the client chooses to deploy a new reverse proxy VM, we provide a fully automated installation script.

Our script handles:

  • Installing NGINX

  • Installing Certbot (Let's Encrypt)

  • Automatic certificate issuance + renewal (HTTP-01 validation)

  • Automatic HTTP → HTTPS redirect

  • Enforcing CMMC-compliant cipher suites

  • Setting up backend TLS verification

  • Configuring proxy rules for FP endpoints

  • Setting secure headers

Requirements for the script to work:

  • A VM in the DMZ subnet

  • Public IP attached

  • Inbound 80 (for Let's Encrypt) and 443 allowed

  • Outbound 443 to the internal subnet

  • Ability to install apt/yum packages depending on OS

Clients simply run:

And the reverse proxy becomes ready within minutes.

8C. If Client Manages Their Own Reverse Proxy

Some clients prefer to use their existing reverse proxy stack or corporate standard tooling.

In such cases, they must apply industry and CMMC/NIST-compliant configurations, including:

✔ TLS Requirements (CMMC-Compliant)

  • Allowed: TLS 1.2 and TLS 1.3

  • Disallowed: TLS 1.0, 1.1, SSLv3

Allowed Ciphers

✔ Mandatory Security Headers

  • X-Frame-Options: SAMEORIGIN

  • X-Content-Type-Options: nosniff

  • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

✔ Backend Security Requirements

Reverse proxy → On-Prem Server must:

  • Re‑encrypt traffic over HTTPS

  • Validate backend certificate (proxy_ssl_verify on or equivalent)

  • Trust the provided backend CA

  • Send the correct SNI (Server Name Indication)

✔ Upload/Download Handling

  • Must support streaming uploads (proxy_request_buffering off)

  • Must support large payloads (client_max_body_size configured appropriately)

✔ Routing Requirements

Reverse proxy must forward:

  • X-Forwarded-For

  • X-Forwarded-Proto

  • X-Forwarded-Host

  • Host

These ensure the FP On-Prem server receives the correct original client context.

8D. Full Deployment Overview

Step 1 - Create three subnets

DMZ → Reverse Proxy

Internal → On-Prem

FP ServerManagement → Admin VM

Step 2 - Deploy or integrate Reverse Proxy

  • Use existing corporate reverse proxy (if compliant), or

  • Deploy new reverse proxy using FenixPyre’s automated script

Step 3 - Deploy On-Prem FP Server

The On-Prem VM setup is fully automated. Clients must run the provided setup script on the VM.

The script will:

  • Install required dependencies

  • Generate backend self‑signed TLS certificates

  • Install Docker / Podman

  • Pull and run the FenixPyre On-Prem containers

  • Add integration on the fenixpyre through API call

  • Get mTLS server certificate from Fenixpyre

  • Register CA and backend certificates for reverse proxy trust

This ensures every customer deployment is consistent, secure, and CMMC-compliant.

9. FenixPyre Cloud Connectivity

The On-Prem server does not send data to the cloud. Only metadata/references for authentication and link creation.

Required outbound:

No CUI ever flows through FenixPyre Cloud.

10. Troubleshooting

Issue: Proxy can't reach backend

  • Certificate mismatch

  • NSG blocks DMZ → Internal

  • Wrong backend IP in proxy_pass

Issue: "Empty reply from server"

  • HTTP → HTTPS redirect missing

  • Backend SSL verification failed

Issue: Uploads failing

  • Increase client_max_body_size

  • Use proxy_request_buffering off

11. Security Best Practices

  • Never assign public IP to On-Prem FP server

  • Avoid NIC-level security groups

  • Lock SSH access to admin IP only

  • Rotate backend certificates yearly

  • Use TLS 1.2/1.3 only

  • Monitor logs continuously

12. Appendix: Simplified Diagram

Last updated

Was this helpful?