# FenixPyre On-Prem Deployment Guide

***

<figure><img src="/files/STWvvpmJLFF9hnMfJfEe" alt=""><figcaption></figcaption></figure>

## 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.:

```
DMZ:        10.0.10.0/24
Internal:   10.0.20.0/24
Management: 10.0.30.0/24
```

#### 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 → On-Prem FP Server
```

Reverse proxy must trust this certificate:

```
proxy_ssl_trusted_certificate /etc/nginx/ssl/onprem-ca.crt;
proxy_ssl_verify on;
```

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 → On-Prem FP Server
```

Reverse proxy must trust this certificate:

```
proxy_ssl_trusted_certificate /etc/nginx/ssl/onprem-ca.crt;
proxy_ssl_verify on;
```

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:

```
sudo bash fenixpyre-nginx-setup.sh
```

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

```
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
```

### ✔ 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&#x20;

Internal → On-Prem&#x20;

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:

```
443 → *.fenixpyre.com
443 → *.datanchor.net
```

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

```
           Internet
               |
       [ Reverse Proxy ]  ← Public IP
               |
        TLS (Internal)
               |
     [ On-Prem FP Server ]
               |
         mgmt-only access
               |
        [ Admin / Jump VM ]
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.fenixpyre.com/fenixpyre-for-admins/cloud-integrations/on-prem-secure-sharing-solution/fenixpyre-on-prem-deployment-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.