MediawikiCIT - User contributions [en]

Main Page

2026-08-02T06:05:55Z

Justinaquino: Add New Articles feed (10 most recent, pruned) + auto Newest Pages section, per the hub-and-spoke publishing protocol

__NOTOC__
<div style="background:#f8f9fa; border:1px solid #ddd; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
Welcome to the '''Comfac IT Knowledge Base'''. Use the sections below to find guides, SOPs, and references organized by topic.
</div>

== New Articles ==

Recent additions to this wiki, newest first — each is also filed in its permanent topic section below. '''Keep this list to the 10 most recent''' and prune as new pages are added; nothing is deleted, entries just roll off the feed.

* 2026-08-02 — '''[[Hugging Face Practical Guide 260802]]''' — Spaces, local app builds, the Model Hub / dataset viewer, and the enterprise compute tier; the route from stock models to tailored ones and to training on our own data — ''Filed under: AI & Machine Learning''
* 2026-08-01 — '''[[Audio Learning]]''' — Converting research and study material into scripts written to be listened to rather than read; shared Comfac tool — ''Filed under: Tools & Productivity''
* 2026-07-31 — '''[[Resume CV Renamer Pipeline]]''' — CV intake → OCR / vision-OCR → AI field extraction → date-stamped rename + VCF export — ''Filed under: Tools & Productivity''
* 2026-07-15 — '''[[De-Risk: Sovereign Training Data v0.1]]''' — Frontier-Token Quarantine and the ToS-clean path to owned model weights, prompted by the June 2026 Fable 5 export-control suspension — ''Filed under: AI & Machine Learning''
* 2026-07-15 — '''[[Directed Execution: Token-Efficient Agent Development Process]]''' — Director/Executor/Checker loop and skill distillation for token-efficient agent development — ''Filed under: AI & Machine Learning''
* 2026-07-11 — '''[[Tutorial: Exposing a Dockerized Web App via NPM Direct DB Config]]''' — Expose a Dockerized web app by editing Nginx Proxy Manager's database directly — ''Filed under: System Administration & Self-Hosting''
* 2026-05-02 — '''[[Organizing Coder Terminals]]''' — Tmux + dynamic titles for managing multiple AI agent terminals — ''Filed under: System Administration & Self-Hosting''
* 2026-04-28 — '''[[Forgejo Pages]]'''
* 2026-04-24 — '''[[Buzz Transcription]]''' — Offline audio/meeting transcription via Whisper (whisper.cpp), Flatpak + Vulkan GPU acceleration — ''Filed under: Tools & Productivity''
* 2026-04-23 — '''[[Training: Setting Up a Firewall for Yourself]]'''

== Newest Pages (auto) ==

The 10 most recently created pages — maintains itself.

{{Special:NewPages/10}}

== ERPNext / Frappe ==
<div style="column-count:2; column-gap:2em;">
* [[Frappe HRMS]] — '''HR & Payroll''' (with Philippine Localization)
* [[Frappe ERPNext/Webshop]] — '''E-Commerce Webshop''' (setup, architecture, chapters)
* [[Manufacturing v16 260125]]
* [[ERpnext Asset Management Procedure 260113]]
* [[ERPNext HR Module Outline]]
* [[ERPNEXT Payroll POC 251212]]
* [[Comfac ERPNext Strategy Canvas (Expanded)]]
* [[PAD-Driven ERPNext Strategy 260303]] — PAD/AI-agentic implementation strategy for Frappe ERPNext
* [[ERPNext v15 Docker Setup Guide]] — Local Docker setup for evaluation, testing, and student use
* [[Frappe Links and References]]
* [[Using Frappe Wiki]]
* [https://docs.frappe.io/cloud/guidelines-for-contributing-regional-compliance-app Guidelines for Contributing Regional Compliance App]
* [https://docs.frappe.io/cloud/what-are-benches-and-bench-groups What are Benches?]
</div>

== System Administration & Self-Hosting ==
<div style="column-count:2; column-gap:2em;">
* [[Networking PfSense Index]] — Consolidated index of all networking, pfSense, DNS, and infrastructure guides
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]]
* [[Controller Systems 251213-01]]
* [[Power Distribution Tree 251213]]
* [[Introduction: Why Self-Host Your Email?]]
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]]
* [[Mailcow SOGo: Creating Filters for Events, Approvals, and Organizational Emails]]
* [[Spoof Timezone Extension – Setup Guide for Comfac Staff]]
* [[Viber Focus-Stealing]]
* [[🌐 WordPress Website — *You Own Everything, Learn Everything*]]
* [[Portainer to Docker Compose Migration Guide]]
* [[Organizing Coder Terminals]] — Tmux + dynamic titles for managing multiple AI agent terminals
* [[Editing Mastodon Docker Deployment Guide 260402]]
</div>

== Storage & Hardware ==
<div style="column-count:2; column-gap:2em;">
* [[TrueNAS Configuration Options & Scale Options 251130]]
* [[TrueNAS Business Plan: Project 251212]]
* [[Comparison: TrueNAS Mini X+ vs Dell Precision 3680 Tower (2025)]]
* [[Backblaze Drive Stats for Server and Storage Qualification]]
* [[Industrial Controllers and Water Utilities 251011]]
</div>

== AI & Machine Learning ==
<div style="column-count:2; column-gap:2em;">
* [[OpenWebUI - 251128-justin]]
* [[Comfac GPU Scaling and AI Research Goals]]
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]
* [[Ollama GNOME System Tray Panel 260401]] — GNOME system tray toggle to start/stop Ollama and reclaim VRAM
* [[Proceedural Agentic Development Methodology 260304]] — Methodology for systematic agent use
* [[Project OpenCoder: AI Independence Initiative]] — Strategic roadmap for manufacturing intelligence
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 Modelfile fix for tool calling in OpenCode; thinking mode suppression; HDD vs SSD findings
* [[OpenCode Multi-Provider Configuration Guide 260401]] — Dual-mode AI coding setup with Kimi cloud + Ollama local models via Distrobox
* [[PAD-Driven ERPNext Strategy 260303]] — Procedural Agentic Development for Frappe/ERPNext configuration and deployment
* [[Directed Execution: Token-Efficient Agent Development Process]] — Director/Executor/Checker loop and skill distillation for token-efficient agent development (v0.1, 2026-07-15)
* [[De-Risk: Sovereign Training Data v0.1]] — Frontier-Token Quarantine and the ToS-clean path to owned model weights, prompted by the June 2026 Fable 5 export-control suspension (v0.1, 2026-07-15)
* [[Hugging Face Practical Guide 260802]] — Spaces, local app builds, the Model Hub / dataset viewer, and the enterprise compute tier; the route from stock models to tailored ones and to training on our own data (2026-08-02)
</div>

== Job Descriptions ==
<div style="column-count:2; column-gap:2em;">
* [[Job Descriptions]] — Index of all official job descriptions (IT, Engineering, Sales)
* [[JD IT Project Staff]] — IT Project Staff
* [[JD Security Compliance Assistant 260224]] — Security and Compliance Assistant (SCA)
* [[JD Engineering Designer 260108]] — Engineering Designer
* [[JD Engineering Supervisor 260109]] — Engineering Supervisor
* [[JD Technical Sales 260112]] — Technical Sales Engineer
* [[JD Marketing Assistant 251119]] — Marketing Assistant
</div>

== IT Operations & SOPs ==
<div style="column-count:2; column-gap:2em;">
* [[SCA Program Plan 260320]] — Security & Compliance Assistant Program Plan v3 (ISO 9001/27001, PDCA, distributed audit model)
* [[SOP: Inter-Company Ordering and Production Process 260203]] — Ordering and production workflow between Sister Companies and the Cabuyao Plant
* [[Memo: Team Roles & Reporting Process Clarification 260320]] — Role boundaries, data ownership, and the new ERPNext-driven reporting paradigm
* [[Standard Operating Procedure: Distributed Minute Taking & Task Ownership 251208]]
* [[Business Continuity]]
* [[Procedure: CC-Blast Data Breach Prevention]]
* [[8D (Eight Discipline) Problem Solving Procedure]]
* [[Offline Malware Remediation & Data Recovery]]
* [[Troubleshooting: Access & Permission Issues]]
* [[Steps to Repair and OCR a Scanned or Corrupted PDF in Ubuntu]]
* [[IT IMPORTS PROCESSES]]
* [[IT Purchase Requests 241126]]
* [[IT REQUEST (OP-ERP-ITR) - EDITED 250801]]
</div>

== Sales & Business ==
<div style="column-count:2; column-gap:2em;">
* [[Comfac Sales Knowledge Base]]
* [[Comfac CRM – Customer Qualification & Conversion Process]]
* [[Partner Reseller Pricing 251109]]
* [[Biz Analysis Methodology 251109]]
* [[2026 MIS IT KRA KPI Biz Plan]]
* [[SALES INVOICE TAX OUTPUT 250829]]
* [[Projects in Process Report 251023]]
</div>

== Tools & Productivity ==
<div style="column-count:2; column-gap:2em;">
* [[Excel Description Filler Tool 📝]]
* [[Resume CV Renamer Pipeline|Resume / CV Renamer Pipeline]] — CV intake → OCR / vision-OCR → AI field extraction → date-stamped rename + VCF export
* [https://github.com/Comfac-Global-Group/comfac-studies Comfac Studies - Spaced Repetiton Active Recall]
* [[LibreOffice / Nextcloud Office – "Due Tasks" Conditional Formatting]]
* [[Google Drive and Shared Drive Training]]
* [[260108 CGG- GitHub Administration Guide]]
</div>

== Wiki & Documentation ==
<div style="column-count:2; column-gap:2em;">
* [[Mediawiki Setting Up Guide]]
* [[Contributing to Only Office 260307]]
* [[Mediawiki Additional Configuration]]
* [[Mediawiki Docker Migration Guide]]
* [[Home]]
</div>

== Tutorials ==
<div style="column-count:2; column-gap:2em;">
* [[Claude Code Isolation and Burner Workflow 260211]] — Secure AI development environment setup
* [[Opencode isolation and burner workflow 260216]] — OpenCode CLI isolation procedures
* [[LibreOffice Calc NumToWords Extension Complete Guide]] — Extension development
* [[ERPNext v15 Docker Setup Guide]] — ERPNext v15 local Docker setup (students, evaluators, thin-client demos)
* [[Erpnextv15-SSH-setup-241111]] — ERPNext v15 SSH/Portainer production setup
* [[Git-Mediawiki Local Editing 260223]] — Wiki editing with Git
* [[Understanding & Fixing Kernel Panics 260212]] — System debugging
* [[OpenCode in Android Termux 260303]] — OpenCode in Android
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 agentic setup: Modelfile, tool calling fix, storage impact
* [[Lora Basics 260304]] — LORA research
* [https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210 Opencode Copy-paste Clipboard doesnt Work - Solution] https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210
</div>

== Research ==
<div style="column-count:2; column-gap:2em;">
* [[Ladybird Browser]] — Browser engine development
* [[Computing Architecture]] — System design principles
* [[Backblaze Drive Stats for Server and Storage Qualification 260219]] — Drive reliability analysis
</div>

----

== For Users Only ==
* [[Private:Private Ngani]]
* [[Private:Private Nganipart2]]

== CIT-OJT Project Documentations ==
* [[OJTDocs: For OJTs only]]

== Need Help? ==
<div style="column-count:2; column-gap:2em;">
* [[Troubleshooting: Access & Permission Issues]]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents MediaWiki User's Guide]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
</div>

Main Page

2026-08-02T05:03:29Z

Justinaquino: File Hugging Face Practical Guide 260802 in the index

__NOTOC__
<div style="background:#f8f9fa; border:1px solid #ddd; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
Welcome to the '''Comfac IT Knowledge Base'''. Use the sections below to find guides, SOPs, and references organized by topic.
</div>

== ERPNext / Frappe ==
<div style="column-count:2; column-gap:2em;">
* [[Frappe HRMS]] — '''HR & Payroll''' (with Philippine Localization)
* [[Frappe ERPNext/Webshop]] — '''E-Commerce Webshop''' (setup, architecture, chapters)
* [[Manufacturing v16 260125]]
* [[ERpnext Asset Management Procedure 260113]]
* [[ERPNext HR Module Outline]]
* [[ERPNEXT Payroll POC 251212]]
* [[Comfac ERPNext Strategy Canvas (Expanded)]]
* [[PAD-Driven ERPNext Strategy 260303]] — PAD/AI-agentic implementation strategy for Frappe ERPNext
* [[ERPNext v15 Docker Setup Guide]] — Local Docker setup for evaluation, testing, and student use
* [[Frappe Links and References]]
* [[Using Frappe Wiki]]
* [https://docs.frappe.io/cloud/guidelines-for-contributing-regional-compliance-app Guidelines for Contributing Regional Compliance App]
* [https://docs.frappe.io/cloud/what-are-benches-and-bench-groups What are Benches?]
</div>

== System Administration & Self-Hosting ==
<div style="column-count:2; column-gap:2em;">
* [[Networking PfSense Index]] — Consolidated index of all networking, pfSense, DNS, and infrastructure guides
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]]
* [[Controller Systems 251213-01]]
* [[Power Distribution Tree 251213]]
* [[Introduction: Why Self-Host Your Email?]]
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]]
* [[Mailcow SOGo: Creating Filters for Events, Approvals, and Organizational Emails]]
* [[Spoof Timezone Extension – Setup Guide for Comfac Staff]]
* [[Viber Focus-Stealing]]
* [[🌐 WordPress Website — *You Own Everything, Learn Everything*]]
* [[Portainer to Docker Compose Migration Guide]]
* [[Organizing Coder Terminals]] — Tmux + dynamic titles for managing multiple AI agent terminals
* [[Editing Mastodon Docker Deployment Guide 260402]]
</div>

== Storage & Hardware ==
<div style="column-count:2; column-gap:2em;">
* [[TrueNAS Configuration Options & Scale Options 251130]]
* [[TrueNAS Business Plan: Project 251212]]
* [[Comparison: TrueNAS Mini X+ vs Dell Precision 3680 Tower (2025)]]
* [[Backblaze Drive Stats for Server and Storage Qualification]]
* [[Industrial Controllers and Water Utilities 251011]]
</div>

== AI & Machine Learning ==
<div style="column-count:2; column-gap:2em;">
* [[OpenWebUI - 251128-justin]]
* [[Comfac GPU Scaling and AI Research Goals]]
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]
* [[Ollama GNOME System Tray Panel 260401]] — GNOME system tray toggle to start/stop Ollama and reclaim VRAM
* [[Proceedural Agentic Development Methodology 260304]] — Methodology for systematic agent use
* [[Project OpenCoder: AI Independence Initiative]] — Strategic roadmap for manufacturing intelligence
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 Modelfile fix for tool calling in OpenCode; thinking mode suppression; HDD vs SSD findings
* [[OpenCode Multi-Provider Configuration Guide 260401]] — Dual-mode AI coding setup with Kimi cloud + Ollama local models via Distrobox
* [[PAD-Driven ERPNext Strategy 260303]] — Procedural Agentic Development for Frappe/ERPNext configuration and deployment
* [[Directed Execution: Token-Efficient Agent Development Process]] — Director/Executor/Checker loop and skill distillation for token-efficient agent development (v0.1, 2026-07-15)
* [[De-Risk: Sovereign Training Data v0.1]] — Frontier-Token Quarantine and the ToS-clean path to owned model weights, prompted by the June 2026 Fable 5 export-control suspension (v0.1, 2026-07-15)
* [[Hugging Face Practical Guide 260802]] — Spaces, local app builds, the Model Hub / dataset viewer, and the enterprise compute tier; the route from stock models to tailored ones and to training on our own data (2026-08-02)
</div>

== Job Descriptions ==
<div style="column-count:2; column-gap:2em;">
* [[Job Descriptions]] — Index of all official job descriptions (IT, Engineering, Sales)
* [[JD IT Project Staff]] — IT Project Staff
* [[JD Security Compliance Assistant 260224]] — Security and Compliance Assistant (SCA)
* [[JD Engineering Designer 260108]] — Engineering Designer
* [[JD Engineering Supervisor 260109]] — Engineering Supervisor
* [[JD Technical Sales 260112]] — Technical Sales Engineer
* [[JD Marketing Assistant 251119]] — Marketing Assistant
</div>

== IT Operations & SOPs ==
<div style="column-count:2; column-gap:2em;">
* [[SCA Program Plan 260320]] — Security & Compliance Assistant Program Plan v3 (ISO 9001/27001, PDCA, distributed audit model)
* [[SOP: Inter-Company Ordering and Production Process 260203]] — Ordering and production workflow between Sister Companies and the Cabuyao Plant
* [[Memo: Team Roles & Reporting Process Clarification 260320]] — Role boundaries, data ownership, and the new ERPNext-driven reporting paradigm
* [[Standard Operating Procedure: Distributed Minute Taking & Task Ownership 251208]]
* [[Business Continuity]]
* [[Procedure: CC-Blast Data Breach Prevention]]
* [[8D (Eight Discipline) Problem Solving Procedure]]
* [[Offline Malware Remediation & Data Recovery]]
* [[Troubleshooting: Access & Permission Issues]]
* [[Steps to Repair and OCR a Scanned or Corrupted PDF in Ubuntu]]
* [[IT IMPORTS PROCESSES]]
* [[IT Purchase Requests 241126]]
* [[IT REQUEST (OP-ERP-ITR) - EDITED 250801]]
</div>

== Sales & Business ==
<div style="column-count:2; column-gap:2em;">
* [[Comfac Sales Knowledge Base]]
* [[Comfac CRM – Customer Qualification & Conversion Process]]
* [[Partner Reseller Pricing 251109]]
* [[Biz Analysis Methodology 251109]]
* [[2026 MIS IT KRA KPI Biz Plan]]
* [[SALES INVOICE TAX OUTPUT 250829]]
* [[Projects in Process Report 251023]]
</div>

== Tools & Productivity ==
<div style="column-count:2; column-gap:2em;">
* [[Excel Description Filler Tool 📝]]
* [[Resume CV Renamer Pipeline|Resume / CV Renamer Pipeline]] — CV intake → OCR / vision-OCR → AI field extraction → date-stamped rename + VCF export
* [https://github.com/Comfac-Global-Group/comfac-studies Comfac Studies - Spaced Repetiton Active Recall]
* [[LibreOffice / Nextcloud Office – "Due Tasks" Conditional Formatting]]
* [[Google Drive and Shared Drive Training]]
* [[260108 CGG- GitHub Administration Guide]]
</div>

== Wiki & Documentation ==
<div style="column-count:2; column-gap:2em;">
* [[Mediawiki Setting Up Guide]]
* [[Contributing to Only Office 260307]]
* [[Mediawiki Additional Configuration]]
* [[Mediawiki Docker Migration Guide]]
* [[Home]]
</div>

== Tutorials ==
<div style="column-count:2; column-gap:2em;">
* [[Claude Code Isolation and Burner Workflow 260211]] — Secure AI development environment setup
* [[Opencode isolation and burner workflow 260216]] — OpenCode CLI isolation procedures
* [[LibreOffice Calc NumToWords Extension Complete Guide]] — Extension development
* [[ERPNext v15 Docker Setup Guide]] — ERPNext v15 local Docker setup (students, evaluators, thin-client demos)
* [[Erpnextv15-SSH-setup-241111]] — ERPNext v15 SSH/Portainer production setup
* [[Git-Mediawiki Local Editing 260223]] — Wiki editing with Git
* [[Understanding & Fixing Kernel Panics 260212]] — System debugging
* [[OpenCode in Android Termux 260303]] — OpenCode in Android
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 agentic setup: Modelfile, tool calling fix, storage impact
* [[Lora Basics 260304]] — LORA research
* [https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210 Opencode Copy-paste Clipboard doesnt Work - Solution] https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210
</div>

== Research ==
<div style="column-count:2; column-gap:2em;">
* [[Ladybird Browser]] — Browser engine development
* [[Computing Architecture]] — System design principles
* [[Backblaze Drive Stats for Server and Storage Qualification 260219]] — Drive reliability analysis
</div>

----

== For Users Only ==
* [[Private:Private Ngani]]
* [[Private:Private Nganipart2]]

== CIT-OJT Project Documentations ==
* [[OJTDocs: For OJTs only]]

== Need Help? ==
<div style="column-count:2; column-gap:2em;">
* [[Troubleshooting: Access & Permission Issues]]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents MediaWiki User's Guide]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
</div>

Hugging Face Practical Guide 260802

2026-08-02T05:03:29Z

Justinaquino: New article: Hugging Face practical guide (Spaces, local builds, Model Hub/datasets, enterprise + hf jobs) - lae/HF backlog

= Hugging Face — Practical Guide =

<blockquote>'''Compiled:''' 2026-08-02 · '''Status:''' Living page — open for deeper research</blockquote>
<blockquote>'''Why it is here:''' Hugging Face is currently used at Comfac as a download endpoint for stock model files. It is four things, and the other three are the ones we under-use.</blockquote>

The goal behind this page: access to free open-source models that are '''better than the stock ones''' and more tailored to a specific job, the '''harnesses''' built around them, and the '''training resources''' that take a corpus of a few hundred owned data points and work it up toward thousands.

That last one is the unclosed loop in [[De-Risk: Sovereign Training Data v0.1]] — we have clean, owned process knowledge and no mechanism yet for turning it into '''weights we own'''.

Each section below ends with '''search keywords''' for going deeper on that one bucket.

== Source videos ==

<blockquote>'''Note:''' this wiki does not have the <code>EmbedVideo</code> extension installed (verified 2026-08-02 via <code>api.php ... siprop=extensions</code>), so videos are listed as preview cards rather than embedded players. The [https://wiki.gi7b.org/index.php/Hugging_Face_Practical_Guide_260802 gwiki copy of this page] has EmbedVideo and shows them inline. Installing the extension here is an administrator action.</blockquote>

{| class="wikitable" style="width:100%;"
! style="width:34%;" | Video !! What it covers !! Use it for
|-
| '''[https://www.youtube.com/watch?v=3kRB2TXewus What Is Hugging Face and How To Use It]'''
| The general tour — Spaces, the Model Hub, the Datasets section, and how they relate.
| Sections 1–3 below. Start here if Hugging Face has only ever been a download link.
|-
| '''[https://www.youtube.com/watch?v=wUzfRBi9wZ0 The Hugging Face Hub for Enterprise & Academia]'''
| Private workspaces, SSO, access control, separated compute/storage billing, SSH onto Spaces hardware, and remote training with <code>hf jobs</code>.
| Section 4. This is the one that matters for training on our own data.
|}

----

== 1. Exploring and using pre-built AI (Spaces) ==

'''Spaces''' are ready-to-use, browser-based applications built by the AI community — image and video generators, voice synthesis, transcription, live demos of new papers. All runnable without writing code.

If a Space is useful, click '''Duplicate Space'''. That forks it into your own account as your own copy, public or private, on hardware you select.

Two things worth internalising:

* A Space is a '''real repository''', not a demo sandbox. Duplicating gives you the source.
* Most Spaces are '''Gradio''' apps. Learn Gradio once and the whole catalogue becomes editable.

'''Search keywords:''' ''"Hugging Face Spaces tutorial"'' · ''"How to build and deploy Gradio apps on Hugging Face"'' · ''"Duplicating Hugging Face Spaces"''

== 2. Building custom apps locally ==

Because Spaces are open source, the code comes to your machine. Clone the repository, open it in an AI-assisted IDE, run it locally, and connect your own API keys instead of the demo's. From there the IDE can help you change colours, fonts, or actual behaviour.

This is the cheapest route to '''a harness we control''' — instead of writing scaffolding from scratch, start from a working app and cut it down.

Practical notes:
* Expect the first local run to fail on dependencies or a missing key. That failure, written down, is the reusable knowledge — not the happy path.
* Check the licence before adapting anything. '''Open-source and permissively-licensed are not the same thing''', and licence direction is one-way once code is borrowed.

'''Search keywords:''' ''"Clone Hugging Face Space locally"'' · ''"Build AI apps with Cursor and Hugging Face"'' · ''"Integrate LLM API keys in Hugging Face local apps"''

== 3. Finding models and datasets ==

The '''Model Hub''' is the core: over 1.5 million open-source models categorised '''by task''' — computer vision, NLP, audio, robotics. The '''Datasets''' section holds the data that trained them.

'''Navigate by task tag, not by keyword.''' Searching an acronym returns papers; filtering by task returns weights:

: <code>https://huggingface.co/models?pipeline_tag=robotics</code>
: <code>https://huggingface.co/api/models?pipeline_tag=robotics</code> ''(API form, for scripting)''

The advanced feature almost nobody touches is the '''dataset viewer''': chat with a dataset through an AI agent and '''run SQL queries in the browser''' to analyse it ''before'' downloading a single gigabyte. For evaluating training data this is the highest-value habit on the page.

'''Our standing admission rule applies here:''' a model card is a '''claim, not a measurement'''. Nothing enters the local model roster on a card alone — it enters on a real API call, the same gate used for the Synopsis model-selection slate. See [[Comfac GPU Scaling and AI Research Goals]] §Applied Model Evaluation and [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]].

'''Search keywords:''' ''"How to choose and run Hugging Face models"'' · ''"Hugging Face dataset viewer SQL tutorial"'' · ''"Fine-tuning open source models Hugging Face"''

== 4. Scaling for teams and enterprise ==

For organisations and academic teams the paid tiers add private workspaces, single sign-on (SSO), and granular access control.

The structural benefit is that '''compute and storage are billed separately''' — no paying for idle hardware. Two working modes follow:

* '''SSH directly onto Spaces hardware''' and develop there, as if it were a remote box.
* '''<code>hf jobs</code>''' — fire a heavy training workload at remote hardware and collect the result.

The second is what makes a fine-tune possible without owning the GPU it would need.

'''Search keywords:''' ''"Hugging Face Enterprise setup guide"'' · ''"Running hf jobs on zero GPU Hugging Face"'' · ''"Hugging Face private workspaces and security"''

----

== Open problem — where this is going ==

Three goals, none closed. Tracked in <code>work/comfac-operations/BACKLOG-huggingface-model-sourcing-and-training.md</code>.

# '''Better than stock.''' The models we run locally today are stock bases. Tuned community models in the same size band may follow instructions better for a specific task, at no cost — but only a run against a gate written '''beforehand''' counts as evidence.
# '''Harnesses instead of rebuilds.''' Identify the Spaces that overlap tooling we would otherwise write ourselves.
# '''Training on owned data.''' Start at a few hundred data points and work toward thousands.

=== The constraint on goal 3 ===

'''Frontier-Token Quarantine is binding.''' Per [[De-Risk: Sovereign Training Data v0.1]], distilling commercial frontier-model outputs into our own weights trades a regulatory dependency for a '''contractual liability''' — in writing, with discoverable provenance logs. Any training corpus must be '''clean by construction'''. Tooling cannot launder provenance; that was named as the weakest claim in the source report.

=== Hardware reality check ===

Anything meant to run on a normal workstation has to fit the VRAM actually available, '''alongside whatever else is already resident''' — a vision model kept loaded for a document pipeline is not free. Size band and quantisation are a filter applied '''first''', not a compromise made afterwards. A related finding already measured here: 4-bit quantisation degrades digit reading, so anything touching numbers on a form runs at 8-bit.

== See also ==

* [[De-Risk: Sovereign Training Data v0.1]] — why owned weights matter and what may not go in the corpus
* [[Comfac GPU Scaling and AI Research Goals]] — GPU capacity and the applied model-evaluation method
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]
* [[Project OpenCoder: AI Independence Initiative]]
* [[Directed Execution: Token-Efficient Agent Development Process]]

[[Category:AI]]
[[Category:Research]]
[[Category:Open Source]]
[[Category:Comfac]]

Audio Learning

2026-08-01T06:15:16Z

Justinaquino: Created: Audio Learning research-to-TTS tool article with link to citfj repo

{{New article banner|date=2026-08-01}}
'''Audio Learning''' is the practice of converting research, articles, notes, and study material into scripts written to be '''listened to''' rather than read. It is a shared Comfac tool maintained as a private Forgejo repository and designed for staff who consume technical material hands-free — commuting, walking, between machines on the plant floor.

== What it is ==

Written prose and spoken prose are different mediums. A reader can re-read a sentence, skim a heading, and hold structure visually. A listener gets one linear pass with no backtracking. Audio Learning provides the discipline to re-compose research for the ear.

The repository contains a '''skill for AI agents''' ('''research-to-tts''') that converts knowledge into one of two house formats:

; Lecture format (Great Courses style)
: For technical study — networking, protocols, CISM/CISSP, security architecture, governance frameworks, systems engineering, ISO standards. The listener walks away understanding a mechanism they did not understand before. Useful for Comfac training material: Network+ basics, pfSense operations, BIR compliance, ERPNext workflows.

; Analyst format (thesis-and-evidence style)
: For contested material — energy markets, housing policy, supply-chain economics, regulatory analysis, industry studies. The listener walks away able to make or defend a decision. Useful for bid analysis, feasibility studies, vendor evaluations, and competitive intelligence.

== What it contains ==

* Concrete prose mechanics — how to speak numbers, acronyms, symbols, citations, code, and homographs so a text-to-speech engine renders them correctly
* Format templates — cold-open structures, spine metaphors, prerequisite ordering, decision frames, thesis stacking, approach ladders, and tripwire indicators
* Visual description protocols — a two-pass method for turning charts, diagrams, tables, and maps into something a listener can build a mental model of
* A pre-delivery audit — ten checks every script must pass before it is spoken

== Where it lives ==

The source repository is private on the Comfac Forgejo:

[https://git.comfac-it.net/cgg/audio-learning cgg/audio-learning]

== How to use it ==

An AI agent loads the skill, reads the reference files, picks a format, plans an outline from the source material, drafts a script with spoken prose only (no markdown, no symbols, no parentheticals), and audits the result before delivering it. The output is a plain-text script with a non-spoken production header and a clean spoken body — ready to be fed into any text-to-speech engine.

== Related ==

* [[GPU Scaling and AI Research|GPU Scaling and AI Research Goals]] — Comfac's model-evaluation infrastructure
* [[Open Source Software Analysis]] — tool evaluation methodology
* [[Resume / CV Renamer Pipeline]] — OCR-to-searchable pipeline (same ingestion-to-structured-output pattern)

[[Category:Tools]]
[[Category:AI Agents]]
[[Category:Training]]

Main Page

2026-07-31T14:25:42Z

Justinaquino: Tools & Productivity: add Resume / CV Renamer Pipeline

__NOTOC__
<div style="background:#f8f9fa; border:1px solid #ddd; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
Welcome to the '''Comfac IT Knowledge Base'''. Use the sections below to find guides, SOPs, and references organized by topic.
</div>

== ERPNext / Frappe ==
<div style="column-count:2; column-gap:2em;">
* [[Frappe HRMS]] — '''HR & Payroll''' (with Philippine Localization)
* [[Frappe ERPNext/Webshop]] — '''E-Commerce Webshop''' (setup, architecture, chapters)
* [[Manufacturing v16 260125]]
* [[ERpnext Asset Management Procedure 260113]]
* [[ERPNext HR Module Outline]]
* [[ERPNEXT Payroll POC 251212]]
* [[Comfac ERPNext Strategy Canvas (Expanded)]]
* [[PAD-Driven ERPNext Strategy 260303]] — PAD/AI-agentic implementation strategy for Frappe ERPNext
* [[ERPNext v15 Docker Setup Guide]] — Local Docker setup for evaluation, testing, and student use
* [[Frappe Links and References]]
* [[Using Frappe Wiki]]
* [https://docs.frappe.io/cloud/guidelines-for-contributing-regional-compliance-app Guidelines for Contributing Regional Compliance App]
* [https://docs.frappe.io/cloud/what-are-benches-and-bench-groups What are Benches?]
</div>

== System Administration & Self-Hosting ==
<div style="column-count:2; column-gap:2em;">
* [[Networking PfSense Index]] — Consolidated index of all networking, pfSense, DNS, and infrastructure guides
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]]
* [[Controller Systems 251213-01]]
* [[Power Distribution Tree 251213]]
* [[Introduction: Why Self-Host Your Email?]]
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]]
* [[Mailcow SOGo: Creating Filters for Events, Approvals, and Organizational Emails]]
* [[Spoof Timezone Extension – Setup Guide for Comfac Staff]]
* [[Viber Focus-Stealing]]
* [[🌐 WordPress Website — *You Own Everything, Learn Everything*]]
* [[Portainer to Docker Compose Migration Guide]]
* [[Organizing Coder Terminals]] — Tmux + dynamic titles for managing multiple AI agent terminals
* [[Editing Mastodon Docker Deployment Guide 260402]]
</div>

== Storage & Hardware ==
<div style="column-count:2; column-gap:2em;">
* [[TrueNAS Configuration Options & Scale Options 251130]]
* [[TrueNAS Business Plan: Project 251212]]
* [[Comparison: TrueNAS Mini X+ vs Dell Precision 3680 Tower (2025)]]
* [[Backblaze Drive Stats for Server and Storage Qualification]]
* [[Industrial Controllers and Water Utilities 251011]]
</div>

== AI & Machine Learning ==
<div style="column-count:2; column-gap:2em;">
* [[OpenWebUI - 251128-justin]]
* [[Comfac GPU Scaling and AI Research Goals]]
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]
* [[Ollama GNOME System Tray Panel 260401]] — GNOME system tray toggle to start/stop Ollama and reclaim VRAM
* [[Proceedural Agentic Development Methodology 260304]] — Methodology for systematic agent use
* [[Project OpenCoder: AI Independence Initiative]] — Strategic roadmap for manufacturing intelligence
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 Modelfile fix for tool calling in OpenCode; thinking mode suppression; HDD vs SSD findings
* [[OpenCode Multi-Provider Configuration Guide 260401]] — Dual-mode AI coding setup with Kimi cloud + Ollama local models via Distrobox
* [[PAD-Driven ERPNext Strategy 260303]] — Procedural Agentic Development for Frappe/ERPNext configuration and deployment
* [[Directed Execution: Token-Efficient Agent Development Process]] — Director/Executor/Checker loop and skill distillation for token-efficient agent development (v0.1, 2026-07-15)
* [[De-Risk: Sovereign Training Data v0.1]] — Frontier-Token Quarantine and the ToS-clean path to owned model weights, prompted by the June 2026 Fable 5 export-control suspension (v0.1, 2026-07-15)
</div>

== Job Descriptions ==
<div style="column-count:2; column-gap:2em;">
* [[Job Descriptions]] — Index of all official job descriptions (IT, Engineering, Sales)
* [[JD IT Project Staff]] — IT Project Staff
* [[JD Security Compliance Assistant 260224]] — Security and Compliance Assistant (SCA)
* [[JD Engineering Designer 260108]] — Engineering Designer
* [[JD Engineering Supervisor 260109]] — Engineering Supervisor
* [[JD Technical Sales 260112]] — Technical Sales Engineer
* [[JD Marketing Assistant 251119]] — Marketing Assistant
</div>

== IT Operations & SOPs ==
<div style="column-count:2; column-gap:2em;">
* [[SCA Program Plan 260320]] — Security & Compliance Assistant Program Plan v3 (ISO 9001/27001, PDCA, distributed audit model)
* [[SOP: Inter-Company Ordering and Production Process 260203]] — Ordering and production workflow between Sister Companies and the Cabuyao Plant
* [[Memo: Team Roles & Reporting Process Clarification 260320]] — Role boundaries, data ownership, and the new ERPNext-driven reporting paradigm
* [[Standard Operating Procedure: Distributed Minute Taking & Task Ownership 251208]]
* [[Business Continuity]]
* [[Procedure: CC-Blast Data Breach Prevention]]
* [[8D (Eight Discipline) Problem Solving Procedure]]
* [[Offline Malware Remediation & Data Recovery]]
* [[Troubleshooting: Access & Permission Issues]]
* [[Steps to Repair and OCR a Scanned or Corrupted PDF in Ubuntu]]
* [[IT IMPORTS PROCESSES]]
* [[IT Purchase Requests 241126]]
* [[IT REQUEST (OP-ERP-ITR) - EDITED 250801]]
</div>

== Sales & Business ==
<div style="column-count:2; column-gap:2em;">
* [[Comfac Sales Knowledge Base]]
* [[Comfac CRM – Customer Qualification & Conversion Process]]
* [[Partner Reseller Pricing 251109]]
* [[Biz Analysis Methodology 251109]]
* [[2026 MIS IT KRA KPI Biz Plan]]
* [[SALES INVOICE TAX OUTPUT 250829]]
* [[Projects in Process Report 251023]]
</div>

== Tools & Productivity ==
<div style="column-count:2; column-gap:2em;">
* [[Excel Description Filler Tool 📝]]
* [[Resume CV Renamer Pipeline|Resume / CV Renamer Pipeline]] — CV intake → OCR / vision-OCR → AI field extraction → date-stamped rename + VCF export
* [https://github.com/Comfac-Global-Group/comfac-studies Comfac Studies - Spaced Repetiton Active Recall]
* [[LibreOffice / Nextcloud Office – "Due Tasks" Conditional Formatting]]
* [[Google Drive and Shared Drive Training]]
* [[260108 CGG- GitHub Administration Guide]]
</div>

== Wiki & Documentation ==
<div style="column-count:2; column-gap:2em;">
* [[Mediawiki Setting Up Guide]]
* [[Contributing to Only Office 260307]]
* [[Mediawiki Additional Configuration]]
* [[Mediawiki Docker Migration Guide]]
* [[Home]]
</div>

== Tutorials ==
<div style="column-count:2; column-gap:2em;">
* [[Claude Code Isolation and Burner Workflow 260211]] — Secure AI development environment setup
* [[Opencode isolation and burner workflow 260216]] — OpenCode CLI isolation procedures
* [[LibreOffice Calc NumToWords Extension Complete Guide]] — Extension development
* [[ERPNext v15 Docker Setup Guide]] — ERPNext v15 local Docker setup (students, evaluators, thin-client demos)
* [[Erpnextv15-SSH-setup-241111]] — ERPNext v15 SSH/Portainer production setup
* [[Git-Mediawiki Local Editing 260223]] — Wiki editing with Git
* [[Understanding & Fixing Kernel Panics 260212]] — System debugging
* [[OpenCode in Android Termux 260303]] — OpenCode in Android
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 agentic setup: Modelfile, tool calling fix, storage impact
* [[Lora Basics 260304]] — LORA research
* [https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210 Opencode Copy-paste Clipboard doesnt Work - Solution] https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210
</div>

== Research ==
<div style="column-count:2; column-gap:2em;">
* [[Ladybird Browser]] — Browser engine development
* [[Computing Architecture]] — System design principles
* [[Backblaze Drive Stats for Server and Storage Qualification 260219]] — Drive reliability analysis
</div>

----

== For Users Only ==
* [[Private:Private Ngani]]
* [[Private:Private Nganipart2]]

== CIT-OJT Project Documentations ==
* [[OJTDocs: For OJTs only]]

== Need Help? ==
<div style="column-count:2; column-gap:2em;">
* [[Troubleshooting: Access & Permission Issues]]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents MediaWiki User's Guide]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
</div>

Resume CV Renamer Pipeline

2026-07-31T14:25:40Z

Justinaquino: Add Resume / CV Renamer Pipeline tool article (intake, OCR/vision-OCR, AI extraction, rename, VCF export)

= Resume / CV Renamer Pipeline =

<div style="background:#f8f9fa; border:1px solid #ddd; border-radius:4px; padding:10px 16px; margin-bottom:16px;">
Automated resume ingestion, OCR, AI extraction, file renaming, and VCF contact export for recruitment workflows.
</div>

'''Location:''' <code>/path/to/resume-renamer/</code> (configure to your local HR/resume folder)

'''Upstream docs:''' [[Frappe HRMS - Ch01 Recruitment]]

----

== What It Does ==

# Drop a resume file (PDF, DOCX, JPG, PNG) into the folder.
# The scanner detects the new file and extracts text with <code>pdftotext</code>.
# Image files or image-based PDFs are converted with <code>img2pdf</code> and OCR'd with <code>ocrmypdf</code> if available.
# If OCR fails or is unavailable, the scanner falls back to '''vision OCR''' using a local VLM (e.g. <code>glm-ocr:bf16</code>).
# A local LLM extracts structured candidate data.
# The file is renamed to: <code>YYMMDD Full Name Degree.pdf</code>
# A <code>YYMMDD-HHMMSS_Bulk_Import.vcf</code> file is generated for contact import.

The single source of truth is the SQLite database <code>resumes.db</code>.

----

== Supported Inputs ==

{| class="wikitable"
! Format !! Handling
|-
| PDF with text || Direct extraction
|-
| Image-based PDF || <code>ocrmypdf</code> → vision OCR fallback
|-
| JPG / PNG || <code>img2pdf</code> → vision OCR fallback
|-
| DOCX || Detected; convert to PDF manually if needed
|}

----

== Quick Start ==

=== Run once manually ===

<syntaxhighlight lang="bash">
cd /path/to/resume-renamer
source ./venv/bin/activate
python cv_auto_scanner.py --once
</syntaxhighlight>

=== Dry-run preview ===

<syntaxhighlight lang="bash">
python cv_auto_scanner.py --once --dry-run
</syntaxhighlight>

=== Daemon mode ===

<syntaxhighlight lang="bash">
python cv_auto_scanner.py --daemon --interval 900 # 15 minutes
</syntaxhighlight>

=== Force a full re-scan ===

<syntaxhighlight lang="bash">
rm -f .scanner_state.json
python cv_auto_scanner.py --once
</syntaxhighlight>

----

== Common Issues ==

=== Degree shows "General" or is empty ===

The scanner now explicitly accepts diplomas and certificates in the <code>degree</code> field. If an older file still shows "General", reset it and reprocess:

<syntaxhighlight lang="bash">
source ./venv/bin/activate
python3 -c "
import resume_db
resume_db.init_db()
resume_db.upsert_candidate('ORIGINAL_FILENAME.pdf', status='pending', retry_count=0, last_error=None)
"
rm -f .scanner_state.json
python cv_auto_scanner.py --once
</syntaxhighlight>

=== "Text too short / unreadable" ===

The scanner automatically tries OCR and vision OCR. If it still fails:

<syntaxhighlight lang="bash">
source ./venv/bin/activate
python /path/to/rpdf-skills/vision_ocr.py FAILED_FILE.pdf --model glm-ocr:bf16 --format text -o extracted.txt
</syntaxhighlight>

Then rebuild a searchable PDF and re-run the scanner.

=== venv broken after Python upgrade ===

<syntaxhighlight lang="bash">
sudo apt install python3.14-venv python3-pip
cd /path/to/resume-renamer
rm -rf venv
python3.14 -m venv venv
source ./venv/bin/activate
pip install --upgrade pip
pip install img2pdf requests pdfplumber psycopg2-binary fpdf2
</syntaxhighlight>

----

== VCF Import ==

New <code>*_Bulk_Import.vcf</code> files are generated automatically. Import them into your contacts app:

* '''Google Contacts:''' contacts.google.com → Import → Select VCF
* '''Android:''' Copy VCF to phone → Contacts → Settings → Import
* '''Thunderbird:''' <code>thunderbird -compose "to=hr@example.com,subject=Contact Card,attachment=/path/to/YYMMDD-HHMMSS_Bulk_Import.vcf"</code>

The VCF uses a non-standard layout for multi-part names:

{| class="wikitable"
! vCard Field !! Value
|-
| <code>N</code> (Last Name) || Role context, e.g. <code>Electrical Applicant 260616</code>
|-
| <code>N</code> (First Name) || Candidate's full name
|-
| <code>FN</code> || <code>{Full Name} - {Context}</code>
|}

To specify the context for a batch:

<syntaxhighlight lang="bash">
python cv_auto_scanner.py --vcf-context "Electrical Applicant 260616"
</syntaxhighlight>

----

== Related Pages ==

* [[Frappe HRMS]]
* [[Frappe HRMS - Ch01 Recruitment]]
* [[Steps to Repair and OCR a Scanned or Corrupted PDF in Ubuntu]]
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]

[[Category:HR]]
[[Category:Recruitment]]
[[Category:Automation]]
[[Category:Comfac]]
[[Category:IT Operations]]

Comfac GPU Scaling and AI Research Goals

2026-07-31T13:02:32Z

Justinaquino: Add Applied Model Evaluation - Synopsis mail-agent model-selection test (2026-07-31)

= Comfac GPU Scaling and AI Research Goals =

== Objective ==

To develop and scale a high-performance AMD-based AI compute cluster, capable of running large-scale models (e.g., Qwen 2.5 235B) and supporting educational and R&D initiatives through open collaboration with partner schools.

----

== Goals and Steps ==

=== 1. Platform and Motherboard Selection ===
* Identify and procure a motherboard or server platform that supports extensive GPU scaling and PCIe bifurcation (similar to the setup demonstrated by PewDiePie).
* Ensure compatibility with ROCm and vLLM for distributed inference and multi-GPU coordination.

=== 2. Initial Scaling (Pilot Models) ===
* Begin with '''well-known, stable models''' to validate infrastructure performance and reliability.
* '''Pilot hardware:''' AMD '''Radeon PRO R9700 AI''' or equivalent AI-focused GPU.
* Validate thermal performance, power delivery, and driver stability for continuous inference workloads.

=== 3. Progressive Hardware Replication ===
* Once stable results are achieved with R9700 PRO, replicate the same environment using '''RX 7900 XTX''' and other AMD GPUs to benchmark performance scaling.
* Document compatibility issues, driver updates, and quantization performance metrics.

=== 4. Cluster and Swarm Development ===
* Establish a '''Cluster System''' for large-model distributed inference and training.
* Build a '''Swarm System''' capable of parallelizing smaller AI instances (e.g., 7700 and lower-end GPU nodes) for local and academic deployment.
* Optimize inter-node communication, synchronization, and monitoring tools for mixed hardware setups.

=== 5. Funding and Laboratory Deployment ===
* Fund the creation of a '''dedicated AI Lab''' focused on testing, documentation, and educational use.
* Provide access to partner schools for research, benchmarking, and AI model fine-tuning.

=== 6. Open Compute and Tokenization Participation ===
* Study and participate in open-source projects that allow community-based compute contributions (similar to Folding@home).
* Learn and experiment with decentralized compute-sharing models that enable contributors to sell '''tokens or compute time''' securely and transparently.

----

== Applied Model Evaluation — Synopsis Mail-Agent Test (2026-07-31) ==

First concrete output under the AI research program: an empirical model-selection harness, built for the Synopsis "talk to your email" agent but reusable for CSAMA and 2B evaluation.

> Evaluator: Kimi Code CLI / k1.6 · Methodology: live infra checks + real API tool-call sweeps + mailbox-anchored question verification. Full detail: <code>work/comfac-synopsys/docs/260731-eod-model-selection-session.md</code> and <code>plans/260731-115026-model-selection-test.md</code>.

* '''Method over benchmarks:''' candidates are gated on ''tool-calling fidelity, citation honesty, and admitting absence'' — not prose quality or public benchmark scores. A single fabricated citation fails a candidate outright; every failure carries a failure-mode tag (fabrication / no-search / false-absence / wrong-args / shallow-search / misread / multi-hop-fail) so "failed" distinguishes untrustworthy from merely fixable.
* '''Slate (7 candidates, all tools-gated on real calls):''' qwen3-vl:8b-instruct-q8_0 (control), qwen3-vl:8b-instruct, qwen3.5:9b (thinking on/off arm), gemma4:12b, qwen3:14b, ibm/granite4.1:8b, fablevibes:14b-a3b (community MoE prune — provenance caveat).
* '''Hardware finding:''' 15 GiB usable VRAM (RX 9060 XT class) excludes 27B-class models at Q4 (17 GB+) — concrete evidence for the '''20 GB+ procurement path''' (RX 7900 XT / Radeon PRO R9700) in the scaling goals above.
* '''Small-model finding:''' sub-4B models mostly cannot run a tool loop (granite3.3:2b, phi4-mini failed to emit tool calls at all; llama3.2:3b marginal). For CPU/micro-model (CSAMA) roles, plan non-tool architectures (extractive prefilter → small-model polish).
* '''Infra prerequisites proven:''' Ollama as an enabled systemd service, VPN-reachable from the batch host, no auto-sleep, 100% GPU placement — the pattern any "chief model host" in the cluster must replicate.
* '''Status:''' gated run blocked on one human step (Justin's 20 verified questions). Harness + scorer + golden-set format in <code>work/comfac-synopsys/harness/</code>.

----

== Reference ==

* Inspirational video: [https://youtube.com/qw4fDU18RcU?si=TJ8hYQPIjuQuiORk Watch on YouTube]

----

== End Goal ==

To make Comfac and its academic partners a recognized hub for open, scalable, and sustainable AI research using AMD technologies.

Main Page

2026-07-15T15:21:51Z

Justinaquino: Add De-Risk article link

__NOTOC__
<div style="background:#f8f9fa; border:1px solid #ddd; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
Welcome to the '''Comfac IT Knowledge Base'''. Use the sections below to find guides, SOPs, and references organized by topic.
</div>

== ERPNext / Frappe ==
<div style="column-count:2; column-gap:2em;">
* [[Frappe HRMS]] — '''HR & Payroll''' (with Philippine Localization)
* [[Frappe ERPNext/Webshop]] — '''E-Commerce Webshop''' (setup, architecture, chapters)
* [[Manufacturing v16 260125]]
* [[ERpnext Asset Management Procedure 260113]]
* [[ERPNext HR Module Outline]]
* [[ERPNEXT Payroll POC 251212]]
* [[Comfac ERPNext Strategy Canvas (Expanded)]]
* [[PAD-Driven ERPNext Strategy 260303]] — PAD/AI-agentic implementation strategy for Frappe ERPNext
* [[ERPNext v15 Docker Setup Guide]] — Local Docker setup for evaluation, testing, and student use
* [[Frappe Links and References]]
* [[Using Frappe Wiki]]
* [https://docs.frappe.io/cloud/guidelines-for-contributing-regional-compliance-app Guidelines for Contributing Regional Compliance App]
* [https://docs.frappe.io/cloud/what-are-benches-and-bench-groups What are Benches?]
</div>

== System Administration & Self-Hosting ==
<div style="column-count:2; column-gap:2em;">
* [[Networking PfSense Index]] — Consolidated index of all networking, pfSense, DNS, and infrastructure guides
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]]
* [[Controller Systems 251213-01]]
* [[Power Distribution Tree 251213]]
* [[Introduction: Why Self-Host Your Email?]]
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]]
* [[Mailcow SOGo: Creating Filters for Events, Approvals, and Organizational Emails]]
* [[Spoof Timezone Extension – Setup Guide for Comfac Staff]]
* [[Viber Focus-Stealing]]
* [[🌐 WordPress Website — *You Own Everything, Learn Everything*]]
* [[Portainer to Docker Compose Migration Guide]]
* [[Organizing Coder Terminals]] — Tmux + dynamic titles for managing multiple AI agent terminals
* [[Editing Mastodon Docker Deployment Guide 260402]]
</div>

== Storage & Hardware ==
<div style="column-count:2; column-gap:2em;">
* [[TrueNAS Configuration Options & Scale Options 251130]]
* [[TrueNAS Business Plan: Project 251212]]
* [[Comparison: TrueNAS Mini X+ vs Dell Precision 3680 Tower (2025)]]
* [[Backblaze Drive Stats for Server and Storage Qualification]]
* [[Industrial Controllers and Water Utilities 251011]]
</div>

== AI & Machine Learning ==
<div style="column-count:2; column-gap:2em;">
* [[OpenWebUI - 251128-justin]]
* [[Comfac GPU Scaling and AI Research Goals]]
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]
* [[Ollama GNOME System Tray Panel 260401]] — GNOME system tray toggle to start/stop Ollama and reclaim VRAM
* [[Proceedural Agentic Development Methodology 260304]] — Methodology for systematic agent use
* [[Project OpenCoder: AI Independence Initiative]] — Strategic roadmap for manufacturing intelligence
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 Modelfile fix for tool calling in OpenCode; thinking mode suppression; HDD vs SSD findings
* [[OpenCode Multi-Provider Configuration Guide 260401]] — Dual-mode AI coding setup with Kimi cloud + Ollama local models via Distrobox
* [[PAD-Driven ERPNext Strategy 260303]] — Procedural Agentic Development for Frappe/ERPNext configuration and deployment
* [[Directed Execution: Token-Efficient Agent Development Process]] — Director/Executor/Checker loop and skill distillation for token-efficient agent development (v0.1, 2026-07-15)
* [[De-Risk: Sovereign Training Data v0.1]] — Frontier-Token Quarantine and the ToS-clean path to owned model weights, prompted by the June 2026 Fable 5 export-control suspension (v0.1, 2026-07-15)
</div>

== Job Descriptions ==
<div style="column-count:2; column-gap:2em;">
* [[Job Descriptions]] — Index of all official job descriptions (IT, Engineering, Sales)
* [[JD IT Project Staff]] — IT Project Staff
* [[JD Security Compliance Assistant 260224]] — Security and Compliance Assistant (SCA)
* [[JD Engineering Designer 260108]] — Engineering Designer
* [[JD Engineering Supervisor 260109]] — Engineering Supervisor
* [[JD Technical Sales 260112]] — Technical Sales Engineer
* [[JD Marketing Assistant 251119]] — Marketing Assistant
</div>

== IT Operations & SOPs ==
<div style="column-count:2; column-gap:2em;">
* [[SCA Program Plan 260320]] — Security & Compliance Assistant Program Plan v3 (ISO 9001/27001, PDCA, distributed audit model)
* [[SOP: Inter-Company Ordering and Production Process 260203]] — Ordering and production workflow between Sister Companies and the Cabuyao Plant
* [[Memo: Team Roles & Reporting Process Clarification 260320]] — Role boundaries, data ownership, and the new ERPNext-driven reporting paradigm
* [[Standard Operating Procedure: Distributed Minute Taking & Task Ownership 251208]]
* [[Business Continuity]]
* [[Procedure: CC-Blast Data Breach Prevention]]
* [[8D (Eight Discipline) Problem Solving Procedure]]
* [[Offline Malware Remediation & Data Recovery]]
* [[Troubleshooting: Access & Permission Issues]]
* [[Steps to Repair and OCR a Scanned or Corrupted PDF in Ubuntu]]
* [[IT IMPORTS PROCESSES]]
* [[IT Purchase Requests 241126]]
* [[IT REQUEST (OP-ERP-ITR) - EDITED 250801]]
</div>

== Sales & Business ==
<div style="column-count:2; column-gap:2em;">
* [[Comfac Sales Knowledge Base]]
* [[Comfac CRM – Customer Qualification & Conversion Process]]
* [[Partner Reseller Pricing 251109]]
* [[Biz Analysis Methodology 251109]]
* [[2026 MIS IT KRA KPI Biz Plan]]
* [[SALES INVOICE TAX OUTPUT 250829]]
* [[Projects in Process Report 251023]]
</div>

== Tools & Productivity ==
<div style="column-count:2; column-gap:2em;">
* [[Excel Description Filler Tool 📝]]
* [https://github.com/Comfac-Global-Group/comfac-studies Comfac Studies - Spaced Repetiton Active Recall]
* [[LibreOffice / Nextcloud Office – "Due Tasks" Conditional Formatting]]
* [[Google Drive and Shared Drive Training]]
* [[260108 CGG- GitHub Administration Guide]]
</div>

== Wiki & Documentation ==
<div style="column-count:2; column-gap:2em;">
* [[Mediawiki Setting Up Guide]]
* [[Contributing to Only Office 260307]]
* [[Mediawiki Additional Configuration]]
* [[Mediawiki Docker Migration Guide]]
* [[Home]]
</div>

== Tutorials ==
<div style="column-count:2; column-gap:2em;">
* [[Claude Code Isolation and Burner Workflow 260211]] — Secure AI development environment setup
* [[Opencode isolation and burner workflow 260216]] — OpenCode CLI isolation procedures
* [[LibreOffice Calc NumToWords Extension Complete Guide]] — Extension development
* [[ERPNext v15 Docker Setup Guide]] — ERPNext v15 local Docker setup (students, evaluators, thin-client demos)
* [[Erpnextv15-SSH-setup-241111]] — ERPNext v15 SSH/Portainer production setup
* [[Git-Mediawiki Local Editing 260223]] — Wiki editing with Git
* [[Understanding & Fixing Kernel Panics 260212]] — System debugging
* [[OpenCode in Android Termux 260303]] — OpenCode in Android
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 agentic setup: Modelfile, tool calling fix, storage impact
* [[Lora Basics 260304]] — LORA research
* [https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210 Opencode Copy-paste Clipboard doesnt Work - Solution] https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210
</div>

== Research ==
<div style="column-count:2; column-gap:2em;">
* [[Ladybird Browser]] — Browser engine development
* [[Computing Architecture]] — System design principles
* [[Backblaze Drive Stats for Server and Storage Qualification 260219]] — Drive reliability analysis
</div>

----

== For Users Only ==
* [[Private:Private Ngani]]
* [[Private:Private Nganipart2]]

== CIT-OJT Project Documentations ==
* [[OJTDocs: For OJTs only]]

== Need Help? ==
<div style="column-count:2; column-gap:2em;">
* [[Troubleshooting: Access & Permission Issues]]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents MediaWiki User's Guide]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
</div>

De-Risk: Sovereign Training Data v0.1

2026-07-15T15:21:51Z

Justinaquino: Add De-Risk: Sovereign Training Data v0.1

= De-Risk: Sovereign Training Data v0.1 =
== Building Model Intelligence Without Frontier Tokens in the Corpus ==

<blockquote>'''Evaluator:''' Justin Aquino (CEO / CISO-DPO), authored as JCA</blockquote>
<blockquote>'''Evaluation Date:''' 2026-07-15</blockquote>
<blockquote>'''Methodology:''' Strategy document — synthesis of the Fable 5 export-control incident, Anthropic/OpenAI commercial-terms analysis, and the Directed Execution Process economics. Companion to <code>2026-07-15-fable-ban-sovereign-ai-and-local-model-strategy.md</code> (source report, veracity-reviewed) and <code>2026-07-15-fable-fact-check-and-csama-legal-qa-conversation.md</code> (full Q&A transcript).</blockquote>

'''Owner:''' JCNA (CEO / CISO-DPO) · '''Status:''' Draft for review · '''Date:''' 2026-07-15
'''Companion documents:''' Directed Execution Process v0.1 · Fable Ban & Local AI (veracity-reviewed 2026-07)

----

== 1. Context — What the Fable Episode Actually Proved ==

Three facts from June–July 2026 matter to us. Everything else in the source document was dramatization.

'''1.1 Frontier access is now a policy variable, not an infrastructure constant.''' A Mythos-class model went from launch to worldwide suspension in three days on a single Commerce directive, and stayed dark for 19 days. The trigger was external (a reported jailbreak escalated to Treasury), the scope was blunt (all foreign nationals, unverifiable, therefore everyone), and the reversal was equally abrupt. No SLA, no contract, no self-hosted deployment would have protected a workflow hard-wired to that model. The lesson is not "Anthropic is unreliable" — the lesson is that ''any'' frontier vendor now sits downstream of national-security discretion, and OpenAI's government-coordinated GPT-5.6 rollout confirms the pattern applies industry-wide.

'''1.2 The naive response — distill frontier outputs into your own weights — is a legal trap.''' Anthropic's and OpenAI's terms broadly prohibit using model outputs to train competing models. A pipeline that harvests Fable or Sol completions into a fine-tuning corpus trades a ''regulatory'' dependency for a ''contractual'' liability, and does so in writing, with provenance logs that would be discoverable. For an organization whose CISO-DPO signs the compliance posture, this is not a gray area we can occupy. The source document's "Distilabel ensures ToS compliance" claim was its weakest section precisely because tooling cannot launder provenance.

'''1.3 The clean asset class already exists in our practice.''' Skills, specs, checklists, and QA-derived process knowledge — instructions authored by our people, versioned in our Forgejo — transferred capability across the blackout at zero legal risk. The Directed Execution Process doc formalized this. What it did ''not'' yet do is close the loop from process knowledge to '''model weights we own'''. This document closes that loop, cleanly.

----

== 2. The De-Risk Principle: Frontier-Token Quarantine ==

One rule, enforced architecturally, resolves the entire ToS exposure:

<blockquote>'''No frontier-model-generated token ever enters the training corpus. Frontier models may shape the process; they may never author the data.'''</blockquote>

This splits our AI estate into two zones:

{| class="wikitable"
|-
! Zone !! Contents !! Frontier models (Claude/Fable, Sol)... !! Legal character
|-
| '''Process zone''' || Plans, specs, QA verdicts, RCAs, skill drafts, test designs || ...operate freely here || Ordinary licensed use — Claude helping our team work
|-
| '''Corpus zone''' || Prompts, completions, error traces, corrections, preference pairs destined for fine-tuning || ...are architecturally excluded || 100% owned: our people, our machines, open-weight models, permissive licenses
|}

The subtle failure mode to guard against: a Claude-written QA verdict or RCA is still a frontier token. If that text is pasted verbatim into a training sample, the quarantine is breached. Therefore:

* **Claude's judgments become ''signals'', not ''text''.** Pass/fail, severity, "principle violated" tags — structured fields a human confirms — may drive ''selection and labeling'' of corpus samples. Claude's prose stays in the process zone.
* '''The strongest labels don't come from Claude at all.''' They come from deterministic verifiers — tests pass, lint clean, build succeeds, output matches oracle. Claude helps ''design'' the tests; the CI system ''issues'' the labels. A label emitted by pytest has no author to have a ToS with.
* '''Skills remain process-zone artifacts.''' Instructions and context engineering are not model training; the Directed Execution loop continues unchanged. This document adds a parallel track, it does not replace that one.

----

== 3. The Error Foundry — Why the Error Is the Gold ==

Commodity training data is worthless: every lab has scraped the same internet, and open models are already trained on it. What no one else has — what cannot be scraped, bought, or distilled — is '''the distribution of failures our specific models make on our specific work, paired with verified corrections.'''

A failure trajectory is the single most valuable sample type because it encodes three things at once:

# '''Where the model's capability boundary actually is''' (not where benchmarks claim it is — recall that ~30% of SWE-bench Pro tasks are broken; our CI is not).
# '''A hard negative''' — a plausible-looking wrong answer, which is exactly what preference-optimization methods (DPO/KTO) need and exactly what synthetic "textbook" data lacks.
# '''A verified positive twin''' — once the correction lands and the verifier goes green, we hold a (failed attempt, working attempt) pair on identical context. That pair is a gradient pointing from "what our model does" to "what our work requires."

This also sidesteps the model-collapse problem the source document correctly cited: collapse comes from training on unfiltered synthetic output. Our corpus is synthetic ''attempts'' filtered by ''non-synthetic ground truth'' (executing code, real acceptance criteria, human confirmation). The verifier anchors the distribution to reality.

We already run this pattern. '''Team C at Cabuyao logs negative information from AGV runs for model training''' — this document generalizes Team C's discipline to the entire software and knowledge-work estate.

----

== 4. Pipeline Architecture ==

=== 4.1 Roles ===

{| class="wikitable"
|-
! Layer !! Actor !! Produces !! Zone
|-
| '''Direction''' || Claude (Director session) || FRD-style spec, acceptance criteria, test design, ≤2K-token plan || Process
|-
| '''Execution''' || DeepSeek / Kimi / local Qwen & DeepSeek on OpenCode (vLLM, dual RX 7900 XT) || All code, drafts, attempts — every token of it || '''Corpus'''
|-
| '''Verification''' || CI: pytest/lint/type-check/build via n8n or pre-commit || Deterministic pass/fail labels || '''Corpus''' (labels)
|-
| '''QA''' || Claude (Checker session, separate from Director) || Verdict as structured fields; prose stays out of corpus || Process
|-
| '''RCA''' || Claude + human || Root-cause analysis → feeds ''skill drafts'' and ''new test cases'', never sample text || Process
|-
| '''Correction''' || Open model (re-attempt with hint) or human dev || The corrected trajectory — corpus-eligible because its author is ours || '''Corpus'''
|-
| '''Curation''' || Interns + devs || Provenance manifest, dedup, pair assembly, PR to dataset repo || Corpus
|}

The critical asymmetry: '''Claude reads everything and authors nothing that trains.''' Its intelligence is spent on specs, test oracles, verdict signals, and RCA insight — all of which make the ''open'' models' next attempts better, and make the ''corpus'' labels sharper, without ever contributing a training token.

=== 4.2 The loop, end to end ===

# '''Objective in.''' Real ticket or deliberately challenging intern objective. Director-Claude produces spec + machine-checkable acceptance criteria. Spec is stored in Forgejo (process repo).
# '''Open model executes.''' Full trajectory logged: prompt, context, every attempt, tool calls, outputs. This logging is non-negotiable — the exhaust ''is'' the product.
# '''Verifier fires.''' Fail → the failure trace is tagged and banked (this is the gold, not discarded). Pass → candidate positive.
# '''On failure:''' RCA (Claude + human) identifies the principle violated → two outputs: (a) a ''skill draft'' or new test case (process zone), (b) a ''hint'' given to the open model for a re-attempt. The re-attempt that passes becomes the positive twin.
# '''Pair assembly.''' (context, failed, passed, verifier evidence, provenance manifest) → PR into the dataset repo. Intern authors it; dev reviews it; Forgejo history is the audit trail and the intern's portfolio.
# '''Periodic fine-tune.''' When a domain accumulates enough pairs (target: 500–1,000 verified pairs before first run), fine-tune Qwen/DeepSeek variants on the 7900 XT rig (LoRA/QLoRA first — full fine-tunes are not needed to capture correction patterns). Evaluate against a held-out set of ''our own'' past failures.
# '''Promotion.''' A tuned model earns executor duty only by beating the base model on the held-out failure set and on live first-pass acceptance rate — the same metric already in the Directed Execution scoreboard.

=== 4.3 Provenance manifest (per sample, mandatory) ===

<syntaxhighlight lang="text">
sample_id: uuid
generator: {model: qwen2.5-coder-32b, host: PC00-vllm, license: apache-2.0}
context_source: {ticket: FORGEJO-####, spec_hash: ..., spec_author: human|claude-process-zone}
label: {verifier: pytest@ci, result: fail|pass, evidence: run_url}
frontier_tokens_present: false # hard gate; CI rejects true
human_touch: {curated_by: intern_id, reviewed_by: dev_id}
correction_lineage: failed_sample_id # for positive twins
</syntaxhighlight>

<code>frontier_tokens_present: false</code> is enforced by a pre-merge check on the dataset repo: samples whose context includes Claude-session exports are rejected mechanically, not by policy memo. Same philosophy as Synopsis — deterministic rules first.

=== 4.4 Storage & plumbing ===

* '''Trajectory log:''' SQLite first (Synopsis pattern), one DB per domain, schema versioned in Forgejo. Graduate to ERPNext DocTypes only when the team needs commission-model-style visibility.
* '''Dataset repo:''' dedicated Forgejo org, one repo per domain (<code>ds-coding</code>, <code>ds-erpnext</code>, <code>ds-docs</code>), PR-gated, LFS for traces.
* '''Orchestration:''' n8n handles verifier dispatch and label writes; no human copies test results by hand.
* '''Compute:''' existing dual RX 7900 XT / vLLM stack for both inference and LoRA training; no new capex required for Phase 1–2.

----

== 5. Risk Register — What This De-Risks and What It Doesn't ==

{| class="wikitable"
|-
! Risk !! Naive distillation !! This architecture
|-
| Frontier ToS breach (training competing models) || High — corpus is frontier tokens || '''Eliminated''' — corpus is 100% own/open provenance, mechanically enforced
|-
| Frontier blackout (Fable-type event) || Capability frozen at last distill || Skills + tuned weights both survive; Claude roles degrade gracefully to human plan/QA (slower, not broken)
|-
| Model collapse from synthetic data || High — unfiltered frontier outputs || Low — every sample anchored by deterministic verifier; failures kept as hard negatives
|-
| Vendor lock-in of process knowledge || N/A || Skills in model-portable SKILL.md format; dataset in open formats; weights are Apache/MIT-base
|-
| Data privacy (RA 10173) || Frontier API sees raw work product || Secrets/prod data → '''local agents only''' (existing hard rule, unchanged); corpus lives on-prem; CISO-DPO sign-off on any sample class containing personal data
|-
| Benchmark self-deception || Marketing benchmarks || Held-out set of our own historical failures — unfakeable, directly relevant
|}

'''Residual risks, stated honestly:'''
* ''Judge-influence gray zone.'' Even using Claude's pass/fail ''signals'' to select samples arguably "assists" model development. Our mitigation is that the load-bearing labels are deterministic-verifier labels, humans confirm every Claude-derived tag, and no frontier text enters the corpus. This is a defensible posture, not a court-tested one; counsel (BBLAW) should sanity-check the framing once, briefly.
* ''LoRA ceiling.'' Correction-pattern LoRAs will not make a 32B model a Mythos-class reasoner. That is fine — the Directed Execution economics never asked it to. The 5% burst path to frontier APIs remains for genuinely hard problems, in the process zone where it belongs.
* ''Curation labor.'' The pipeline lives or dies on logging discipline and intern throughput. Hence §6.

----

== 6. Call to Action ==

'''This week'''
# '''CEO/CISO-DPO:''' ratify the Frontier-Token Quarantine as policy (one page, references the transcription-tool memo as precedent for "approved-tool" governance style).
# '''Sysadmin + Carl:''' stand up the dataset Forgejo org, SQLite trajectory schema, and the <code>frontier_tokens_present</code> pre-merge check. Half a day of work; it makes the policy mechanical.
# '''Devs:''' switch OpenCode local-agent sessions to full trajectory logging ''now'', even before curation starts. Every unlogged failure this month is discarded gold.

'''Weeks 2–4'''
# '''Interns (all, not just dev interns):''' first curation objectives issued — assemble 50 verified pairs each from live failure logs, PR'd to the dataset repo. The curriculum ''is'' the loop: they learn spec-reading, verifier evidence, and provenance hygiene simultaneously. Scoreboard: pairs merged, review-pass rate.
# '''Team C liaison:''' map the AGV negative-information logging schema onto the manifest in §4.3 so robotics and software share one provenance convention.
# '''BBLAW (existing engagement):''' 30-minute review of the quarantine framing and the judge-signal question. Not a new engagement — an agenda item.

'''Month 2–3'''
# First LoRA run on the coding domain once ≥500 pairs verified. Evaluate on held-out failure set. Publish results internally — win or lose, the eval harness itself is a durable asset.
# '''Decision gate:''' if tuned executor beats base on first-pass acceptance, promote it in the Directed Execution rotation and begin domain #2 (ERPNext customization is the obvious candidate — our failure data there is uniquely ours).

----

== 7. The Strategic Frame ==

Two tracks, different clock speeds, one direction:

* '''Skills (fast, instant transfer):''' capability as ''instructions'', portable across any executor, already running. Survives blackouts by construction.
* '''Weights (slow, compounding):''' capability as ''parameters we own'', grown exclusively from our own error distribution, legally unencumbered because the corpus never contained a frontier token.

Claude's highest-value role in both is the same: not as the source of answers to memorize, but as the intelligence that designs the tests, reads the failures, and sharpens the questions — while our models, our people, and our verifiers author every byte we will ever train on.

The Fable ban gave us the precedent. The error logs give us the data. The quarantine gives us the clean title.

''The error is the gold. Log everything.''

Main Page

2026-07-15T11:02:55Z

Justinaquino: Add Directed Execution article link

__NOTOC__
<div style="background:#f8f9fa; border:1px solid #ddd; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
Welcome to the '''Comfac IT Knowledge Base'''. Use the sections below to find guides, SOPs, and references organized by topic.
</div>

== ERPNext / Frappe ==
<div style="column-count:2; column-gap:2em;">
* [[Frappe HRMS]] — '''HR & Payroll''' (with Philippine Localization)
* [[Frappe ERPNext/Webshop]] — '''E-Commerce Webshop''' (setup, architecture, chapters)
* [[Manufacturing v16 260125]]
* [[ERpnext Asset Management Procedure 260113]]
* [[ERPNext HR Module Outline]]
* [[ERPNEXT Payroll POC 251212]]
* [[Comfac ERPNext Strategy Canvas (Expanded)]]
* [[PAD-Driven ERPNext Strategy 260303]] — PAD/AI-agentic implementation strategy for Frappe ERPNext
* [[ERPNext v15 Docker Setup Guide]] — Local Docker setup for evaluation, testing, and student use
* [[Frappe Links and References]]
* [[Using Frappe Wiki]]
* [https://docs.frappe.io/cloud/guidelines-for-contributing-regional-compliance-app Guidelines for Contributing Regional Compliance App]
* [https://docs.frappe.io/cloud/what-are-benches-and-bench-groups What are Benches?]
</div>

== System Administration & Self-Hosting ==
<div style="column-count:2; column-gap:2em;">
* [[Networking PfSense Index]] — Consolidated index of all networking, pfSense, DNS, and infrastructure guides
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]]
* [[Controller Systems 251213-01]]
* [[Power Distribution Tree 251213]]
* [[Introduction: Why Self-Host Your Email?]]
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]]
* [[Mailcow SOGo: Creating Filters for Events, Approvals, and Organizational Emails]]
* [[Spoof Timezone Extension – Setup Guide for Comfac Staff]]
* [[Viber Focus-Stealing]]
* [[🌐 WordPress Website — *You Own Everything, Learn Everything*]]
* [[Portainer to Docker Compose Migration Guide]]
* [[Organizing Coder Terminals]] — Tmux + dynamic titles for managing multiple AI agent terminals
* [[Editing Mastodon Docker Deployment Guide 260402]]
</div>

== Storage & Hardware ==
<div style="column-count:2; column-gap:2em;">
* [[TrueNAS Configuration Options & Scale Options 251130]]
* [[TrueNAS Business Plan: Project 251212]]
* [[Comparison: TrueNAS Mini X+ vs Dell Precision 3680 Tower (2025)]]
* [[Backblaze Drive Stats for Server and Storage Qualification]]
* [[Industrial Controllers and Water Utilities 251011]]
</div>

== AI & Machine Learning ==
<div style="column-count:2; column-gap:2em;">
* [[OpenWebUI - 251128-justin]]
* [[Comfac GPU Scaling and AI Research Goals]]
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]
* [[Ollama GNOME System Tray Panel 260401]] — GNOME system tray toggle to start/stop Ollama and reclaim VRAM
* [[Proceedural Agentic Development Methodology 260304]] — Methodology for systematic agent use
* [[Project OpenCoder: AI Independence Initiative]] — Strategic roadmap for manufacturing intelligence
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 Modelfile fix for tool calling in OpenCode; thinking mode suppression; HDD vs SSD findings
* [[OpenCode Multi-Provider Configuration Guide 260401]] — Dual-mode AI coding setup with Kimi cloud + Ollama local models via Distrobox
* [[PAD-Driven ERPNext Strategy 260303]] — Procedural Agentic Development for Frappe/ERPNext configuration and deployment
* [[Directed Execution: Token-Efficient Agent Development Process]] — Director/Executor/Checker loop and skill distillation for token-efficient agent development (v0.1, 2026-07-15)
</div>

== Job Descriptions ==
<div style="column-count:2; column-gap:2em;">
* [[Job Descriptions]] — Index of all official job descriptions (IT, Engineering, Sales)
* [[JD IT Project Staff]] — IT Project Staff
* [[JD Security Compliance Assistant 260224]] — Security and Compliance Assistant (SCA)
* [[JD Engineering Designer 260108]] — Engineering Designer
* [[JD Engineering Supervisor 260109]] — Engineering Supervisor
* [[JD Technical Sales 260112]] — Technical Sales Engineer
* [[JD Marketing Assistant 251119]] — Marketing Assistant
</div>

== IT Operations & SOPs ==
<div style="column-count:2; column-gap:2em;">
* [[SCA Program Plan 260320]] — Security & Compliance Assistant Program Plan v3 (ISO 9001/27001, PDCA, distributed audit model)
* [[SOP: Inter-Company Ordering and Production Process 260203]] — Ordering and production workflow between Sister Companies and the Cabuyao Plant
* [[Memo: Team Roles & Reporting Process Clarification 260320]] — Role boundaries, data ownership, and the new ERPNext-driven reporting paradigm
* [[Standard Operating Procedure: Distributed Minute Taking & Task Ownership 251208]]
* [[Business Continuity]]
* [[Procedure: CC-Blast Data Breach Prevention]]
* [[8D (Eight Discipline) Problem Solving Procedure]]
* [[Offline Malware Remediation & Data Recovery]]
* [[Troubleshooting: Access & Permission Issues]]
* [[Steps to Repair and OCR a Scanned or Corrupted PDF in Ubuntu]]
* [[IT IMPORTS PROCESSES]]
* [[IT Purchase Requests 241126]]
* [[IT REQUEST (OP-ERP-ITR) - EDITED 250801]]
</div>

== Sales & Business ==
<div style="column-count:2; column-gap:2em;">
* [[Comfac Sales Knowledge Base]]
* [[Comfac CRM – Customer Qualification & Conversion Process]]
* [[Partner Reseller Pricing 251109]]
* [[Biz Analysis Methodology 251109]]
* [[2026 MIS IT KRA KPI Biz Plan]]
* [[SALES INVOICE TAX OUTPUT 250829]]
* [[Projects in Process Report 251023]]
</div>

== Tools & Productivity ==
<div style="column-count:2; column-gap:2em;">
* [[Excel Description Filler Tool 📝]]
* [https://github.com/Comfac-Global-Group/comfac-studies Comfac Studies - Spaced Repetiton Active Recall]
* [[LibreOffice / Nextcloud Office – "Due Tasks" Conditional Formatting]]
* [[Google Drive and Shared Drive Training]]
* [[260108 CGG- GitHub Administration Guide]]
</div>

== Wiki & Documentation ==
<div style="column-count:2; column-gap:2em;">
* [[Mediawiki Setting Up Guide]]
* [[Contributing to Only Office 260307]]
* [[Mediawiki Additional Configuration]]
* [[Mediawiki Docker Migration Guide]]
* [[Home]]
</div>

== Tutorials ==
<div style="column-count:2; column-gap:2em;">
* [[Claude Code Isolation and Burner Workflow 260211]] — Secure AI development environment setup
* [[Opencode isolation and burner workflow 260216]] — OpenCode CLI isolation procedures
* [[LibreOffice Calc NumToWords Extension Complete Guide]] — Extension development
* [[ERPNext v15 Docker Setup Guide]] — ERPNext v15 local Docker setup (students, evaluators, thin-client demos)
* [[Erpnextv15-SSH-setup-241111]] — ERPNext v15 SSH/Portainer production setup
* [[Git-Mediawiki Local Editing 260223]] — Wiki editing with Git
* [[Understanding & Fixing Kernel Panics 260212]] — System debugging
* [[OpenCode in Android Termux 260303]] — OpenCode in Android
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 agentic setup: Modelfile, tool calling fix, storage impact
* [[Lora Basics 260304]] — LORA research
* [https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210 Opencode Copy-paste Clipboard doesnt Work - Solution] https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210
</div>

== Research ==
<div style="column-count:2; column-gap:2em;">
* [[Ladybird Browser]] — Browser engine development
* [[Computing Architecture]] — System design principles
* [[Backblaze Drive Stats for Server and Storage Qualification 260219]] — Drive reliability analysis
</div>

----

== For Users Only ==
* [[Private:Private Ngani]]
* [[Private:Private Nganipart2]]

== CIT-OJT Project Documentations ==
* [[OJTDocs: For OJTs only]]

== Need Help? ==
<div style="column-count:2; column-gap:2em;">
* [[Troubleshooting: Access & Permission Issues]]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents MediaWiki User's Guide]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
</div>

Directed Execution: Token-Efficient Agent Development Process

2026-07-15T11:02:54Z

Justinaquino: Add Directed Execution: Token-Efficient Agent Development Process v0.1

= Directed Execution: Token-Efficient Agent Development Process =
'''CGG IT — Process & Skillset Definition v0.1'''
Owner: JCA · Status: Draft for team review · Date: 2026-07-15

----

== 1. Problem Statement ==

Developers are consuming Claude Sonnet and Opus tokens for raw code generation. This inverts the economics of the model market. Frontier-model output tokens are the single most expensive resource in the stack (Opus 4.8 output: ₱1,450/M; Fable 5: ₱2,900/M), while commodity-model output is nearly free by comparison (DeepSeek V4 Flash: ₱16/M — a 90× to 180× spread). Meanwhile, frontier-model ''input'' tokens are roughly 5× cheaper than their own output tokens, and cache hits cheaper still.

The consequence is a simple design rule that the current workflow violates:

<blockquote>'''Expensive models should read a lot and write a little. Cheap models should write a lot and be corrected.'''</blockquote>

Nobody has directed the developers to work this way, and there is no shared mechanism for making the cheap models better over time. Both gaps are addressed here: a role-separated loop for day-to-day work, and a skill system that converts QA corrections into reusable capability for the cheap agents.

== 2. Economic Rationale (worked example) ==

Assume a typical feature task: ~30K tokens of relevant context, ~50K tokens of generated code and tests.

'''Current pattern — Opus does everything:'''
30K in (₱8.70) + 50K out (₱72.50), plus one revision cycle of similar size ≈ '''₱150–160 per task''', with no independent QA gate.

'''Directed pattern:'''

{| class="wikitable"
|-
! Step !! Model !! Tokens !! Cost
|-
| Plan + FRD || Opus 4.8 || 30K in / 2K out || ₱11.60
|-
| Execute || DS V4 Flash || 35K in / 50K out || ₱1.08
|-
| QA review || Opus 4.8 || 60K in / 1K out || ₱18.85
|-
| Correction || DS V4 Flash || 40K in / 20K out || ₱0.64
|-
| Re-check || Opus 4.8 (cached ctx) || 25K in / 0.5K out || ~₱8
|-
| '''Total''' || '''≈ ₱40'''
|}

Roughly a 70–75% cost reduction ''while adding a QA gate that did not previously exist''. The QA read is the largest line item, which is correct — that is where the intelligence is actually needed. Substituting Sonnet as the checker for routine tasks pushes the total under ₱20. As skills accumulate and first-pass acceptance rises, the correction cycle amortizes toward zero.

The point is not merely savings. It is that '''judgment and volume are different products''', and we have been buying volume at judgment prices.

== 3. Principles ==

# '''Direction is the deliverable of intelligence.''' The frontier model's job is decomposition, constraints, acceptance criteria, and verdicts — all short, dense outputs. If Claude is emitting more than ~2K tokens on a task, something is misrouted.
# '''Deterministic-first, same as Synopsis.''' Anything checkable by a linter, test suite, type checker, or script never reaches a paid model. Machine checks run before Claude sees the diff.
# '''Every correction is an asset.''' A QA correction consumed once is an expense; distilled into a skill, it is capital. The loop is not complete until the correction is either distilled or explicitly judged one-off.
# '''Cheap agents are pushed, not babysat.''' Executors get hard objectives with clear acceptance criteria and their accumulated skill library — not hand-holding. Failures are information for the skill system.
# '''The loop is the curriculum.''' Interns learn the same process the agents run: plan, execute, check, correct, distill. Team-wide token efficiency is a literacy goal, not a dev-only optimization.

== 4. Roles ==

{| class="wikitable"
|-
! Role !! Model tier !! Reads !! Writes !! Output budget
|-
| '''Director''' || Claude Opus / Fable || Objective, codebase context, skill index || FRD: decomposition, interfaces, acceptance criteria, risks || ≤ 2K tokens
|-
| '''Executor''' || DS V4 Flash, Kimi K2.6; later local Qwen/DeepSeek via OpenCode || FRD + relevant skills + code context || Code, tests, migration scripts — full volume || Unbounded
|-
| '''Checker''' || Claude Opus (critical) / Sonnet (routine) || Full diff + FRD + machine-check results || Verdict: PASS/FAIL per acceptance criterion, itemized corrections anchored to lines || ≤ 1K tokens
|-
| '''Skill Librarian''' || Human (rotating dev/intern) + cheap model drafting || QA correction logs || Skill drafts, skill index maintenance || —
|}

Director and Checker should be '''separate sessions''' even when the same model — the Checker must evaluate against the FRD, not defend its own plan.

Model routing within tiers: DeepSeek V4 Flash is the default executor. Kimi K2.6 when the task needs multimodal input (screenshots, UI review) or its larger instant-mode quality helps. Local agents take over as the vLLM/Ollama stack proves out on benchmarked task classes — the skill library transfers with them, which is the strategic payoff: skills are model-portable capability, not vendor lock-in.

== 5. The Loop ==

'''Plan → Execute → Machine-check → QA → Correct → Distill → Reuse'''

'''Plan.''' Director receives the objective and produces an FRD-lite (template below). No code beyond interface signatures and test-case ''descriptions''. The FRD is the contract; ambiguity discovered later is a planning defect and goes back to the Director, not patched silently by the Executor.

'''Execute.''' Executor works in OpenCode with the FRD and the relevant skills loaded (skills prepended as a stable prefix — this also maximizes cache hits). It generates code and tests to satisfy the acceptance criteria. It may burn tokens freely; that is what it is for.

'''Machine-check.''' Lint, type-check, test run, formatter. Automated (n8n or a pre-commit script). Failures loop back to the Executor without any paid QA read. Claude never reviews code that fails machine checks.

'''QA.''' Checker reads FRD + diff + machine-check results and returns a structured verdict. It does not rewrite code. Each FAIL item states ''what is wrong, why, and the principle violated'' — the "why" is raw material for distillation.

'''Correct.''' Executor applies corrections. Two correction cycles maximum; a third failure escalates to a human plus a mandatory skill-gap review ("what skill would have prevented this?").

'''Distill.''' Weekly, the Skill Librarian reviews the QA correction log. Any correction pattern appearing '''twice or more''' becomes a skill candidate. A cheap model drafts the skill from the correction transcripts; a human reviews and merges it into the Forgejo skill repo.

'''Reuse.''' Skills are indexed by trigger. The Director's FRD names which skills apply; the Executor loads them. Cheap agents therefore climb: yesterday's correction is today's default behavior.

== 6. Deliverable Contracts ==

=== FRD-lite (Director output) ===

<syntaxhighlight lang="text">
FRD-<seq>: <title>
Objective: one sentence.
Scope in / Scope out: explicit exclusions.
Interfaces: function/API signatures the Executor must implement.
Acceptance criteria: numbered, each machine- or QA-checkable.
Constraints: security, style, dependency, and performance rules that apply.
Skills to load: skill IDs from the index.
Risk notes: where the Executor is most likely to go wrong.
</syntaxhighlight>

=== QA Verdict (Checker output) ===

<syntaxhighlight lang="text">
VERDICT: PASS | FAIL
AC-1: PASS/FAIL — <one line>
AC-n: ...
Corrections (if FAIL):
C1 [file:line] What / Why / Principle violated
Distill flags: corrections likely to recur → candidate skill name
</syntaxhighlight>

The "Principle violated" field is deliberately mandatory. It is what makes the verdict distillable rather than a one-off patch instruction.

== 7. The Skill System ==

A skill is a short markdown file teaching a cheap model a specific competence, in the same shape Anthropic uses for Claude skills — which means skills built here also work when the executor ''is'' Claude, or a local model, or whatever comes next.

'''Format''' (<code>SKILL.md</code> per skill, one directory per skill in the Forgejo repo, e.g. <code>skills/erpnext-patch-migrations/</code>):

<syntaxhighlight lang="text">
name: <kebab-case>
trigger: when this skill applies (used by Director for routing)
procedure: numbered steps / rules
examples: one good, one bad (drawn from real QA corrections)
anti-patterns: the specific failures that birthed this skill
provenance: FRD/QA references, author, date
status: draft | reviewed | adopted | deprecated
</syntaxhighlight>

'''Lifecycle.''' Draft (from correction log, cheap-model-written) → Reviewed (human, PR in Forgejo) → Adopted (in the index, loadable) → Deprecated (superseded or model-obsoleted). Skills are versioned like code because they are code — for the agents.

'''Ownership.''' Devs are consumers and reviewers, not the bottleneck. Interns, working with the local DS agents in OpenCode, author most drafts as part of their objectives. The repo's PR history doubles as an intern portfolio.

== 8. Escalation Rules ==

{| class="wikitable"
|-
! Situation !! Route
|-
| Routine feature/bugfix, skills exist || Flash executes, Sonnet checks
|-
| Novel architecture, security-sensitive, cross-system design || Opus/Fable plans and checks
|-
| Executor fails 2 correction cycles || Human review + skill-gap analysis
|-
| Executor requests clarification || Back to Director (cheap→expensive calls are Director-mediated, never ad hoc)
|-
| Anything touching secrets, credentials, prod data || Local agents only; no external API
|}

The last row is a hard rule and aligns with the transcription-tool memo posture: sensitive context stays on the ZeroTier overlay.

== 9. Metrics & Token Ledger ==

Per task, logged (SQLite to start, consistent with the Synopsis MVP philosophy; ERPNext later if it earns its keep):

* Tokens and ₱ by role (Director / Executor / Checker), per task and per week.
* '''First-pass acceptance rate''' — the headline metric. Rising FPA means skills are working.
* '''Correction cycles per task''' and '''escalation rate'''.
* '''Skill reuse count''' and '''skills authored''' per person — the intern scoreboard.
* '''Cost per merged deliverable''', trended. Target: sustained <30% of the all-frontier baseline within one quarter.

The ledger is not surveillance; it is the feedback signal that tells us when a task class is ready to move from Flash to a local model, and when a checker can be downgraded from Opus to Sonnet.

== 10. Rollout ==

'''Week 1 — Instrument and declare.''' Stand up the skill repo in Forgejo, the token ledger, and the machine-check gate. Short directive to the team: no frontier-model code generation for tasks with an FRD path; frontier models plan and check.

'''Week 2 — Seed skills.''' Mine the last month of Claude chat history for recurring correction patterns; interns draft the first 5–10 skills (likely candidates: ERPNext patch conventions, Frappe API idioms, our lint/commit standards, test scaffolding).

'''Week 3 — First directed sprints.''' Each intern gets one challenging objective run fully through the loop with a local DS agent in OpenCode. Devs act as Skill Librarian reviewers. Every completed objective must ship at least one skill PR.

'''Week 4 — Review.''' FPA, cost per deliverable, and skill count reviewed against baseline. Decide the first task class to pilot on fully local models.

'''Steady state.''' The loop is the standard operating rhythm. Quarterly, revisit model routing (the pricing table this document was built from will be stale in months) and prune deprecated skills.

----

''Reasoning summary: the spread between frontier output pricing and commodity output pricing (90×+) makes "smart model writes code" the single most expensive habit in the workflow, while the input/output asymmetry (5×) makes "smart model reads everything, writes verdicts" nearly free by comparison. The skill system converts the residual cost — QA corrections — into permanent, model-portable capability, so the cheap tier's quality compounds and the expensive tier's involvement shrinks over time. Interns are the labor force and the beneficiaries of the same loop.''

Tutorial: Exposing a Dockerized Web App via NPM Direct DB Config

2026-07-11T12:56:50Z

Justinaquino: Uploaded tutorial

__NOTOC__

<div style="background-color: #e7f3fe; border-left: 6px solid #2196F3; padding: 15px; margin-bottom: 20px;">
<strong>Tutorial:</strong> Exposing a Dockerized Web App via NPM Direct DB Config<br>
<strong>Audience:</strong> Self-hosters who need to publish a Dockerized service through Nginx Proxy Manager without admin-panel credentials.<br>
<strong>Last updated:</strong> 2026-07-11
</div>

= My Dockerized Web App — NPM Proxy Host Setup (Direct DB Method) =

'''Scope:''' Expose a Dockerized internal web application through Nginx Proxy Manager (NPM) on <docker-host> without using the NPM Admin UI, because NPM admin-panel credentials are not stored in the BRC credential store.

'''Outcome:''' <code>http://app.example.org</code> resolves to the analyzer on <docker-host> (<code><npm-host-zerotier-ip>:<app-port></code>) via NPM proxy host <code><proxy-host-id></code>. HTTPS is pending the manual SSL-certificate step in the NPM UI.

----

== What You Need ==

{| class="wikitable"
|-
! Item
! Value / Location
|-
| Target domain
| <code>app.example.org</code>
|-
| Backing service
| <code><npm-host-zerotier-ip>:<app-port></code> (<docker-host> ZeroTier, <code>myapp</code> container)
|-
| NPM host
| <docker-host> (<code><npm-host-local-ip></code> local / <code><npm-host-zerotier-ip></code> ZeroTier)
|-
| NPM DB container
| <code>nginx-proxy-manager-db</code>
|-
| NPM app container
| <code>nginx-proxy-manager-app</code>
|-
| NPM DB credentials
| <code>npm</code> / <code>npm</code> (hardcoded in NPM stack)
|-
| <docker-host> SSH credentials
| <code><credential-store>/<docker-host></code>
|-
| Tooling on the agent side
| <code>sshpass</code> (<code>command -v sshpass</code> to verify)
|}

----

== Step 1 — Deploy the Application ==

The analyzer runs as a Docker Compose stack on <docker-host>:

<pre>
# On <docker-host>
/opt/myapp/docker compose up -d
</pre>

It exposes host port <code><app-port></code> and has a one-minute cron sync that pulls <code>main</code> and restarts the container when the repo changes.

Verify it responds locally:

<pre>
curl http://127.0.0.1:<app-port>/api/health
# expected: {"status":"ok","authenticated":false}
</pre>

----

== Step 2 — Set Up the SSH Helper ==

From the workspace, load <docker-host> credentials from BRC and define a one-line SSH wrapper:

<pre>
WORKDIR=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
BRC="$WORKDIR/<credential-store>/<docker-host>"
PASS=$(grep 'password:' "$BRC" | awk '{print $NF}')
HOST=$(grep 'zerotier_ip:' "$BRC" | awk '{print $NF}')
<docker-host>_USER=$(grep -m1 'user:' "$BRC" | awk '{print $NF}')

<docker-host>_SSH() {
sshpass -p "$PASS" ssh \
-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \
"$<docker-host>_USER@$HOST" "$@"
}
</pre>

If <code>sshpass</code> is missing, install it first (<code>apt-get install -y sshpass</code> or equivalent). Do '''not''' treat a missing <code>sshpass</code> as "no SSH access."

----

== Step 3 — Check for Existing Hosts ==

List any existing proxy host that uses the target domain:

<pre>
<docker-host>_SSH "docker exec nginx-proxy-manager-db mysql -unpm -pnpm -h127.0.0.1 npm -e \\"
SELECT id, domain_names, forward_host, forward_port, enabled
FROM proxy_host
WHERE domain_names LIKE '%app.example.org%' AND is_deleted=0;
\\""
</pre>

If a row exists but points to the wrong target, update it or delete it before inserting a duplicate.

----

== Step 4 — Back Up the <code>proxy_host</code> Table ==

Always backup before writing:

<pre>
<docker-host>_SSH "docker exec nginx-proxy-manager-db mysqldump -unpm -pnpm -h127.0.0.1 npm proxy_host" \
> "/tmp/npm-proxy-host-backup-$(date +%Y%m%d-%H%M%S).sql"
</pre>

<blockquote>'''Note:''' Use <code>-h127.0.0.1</code>; the default socket connection may reject the <code>npm</code> user.</blockquote>

----

== Step 5 — Insert the Proxy Host Row ==

Insert an HTTP-only row (<code>certificate_id=0</code>, <code>ssl_forced=0</code>). SSL is requested later from the NPM UI.

<pre>
DOMAIN="app.example.org"
TARGET_IP="<npm-host-zerotier-ip>"
TARGET_PORT="<app-port>"

<docker-host>_SSH "docker exec nginx-proxy-manager-db mysql -unpm -pnpm -h127.0.0.1 npm -e \\"
INSERT INTO proxy_host
(created_on, modified_on, owner_user_id, domain_names, forward_host, forward_port,
access_list_id, certificate_id, ssl_forced, caching_enabled, block_exploits,
advanced_config, meta, allow_websocket_upgrade, http2_support, forward_scheme, enabled, locations,
hsts_enabled, hsts_subdomains, trust_forwarded_proto)
VALUES
(NOW(), NOW(), 1, '[\\\\\"${DOMAIN}\\\\\"]', '${TARGET_IP}', ${TARGET_PORT},
0, 0, 0, 0, 0,
'',
'{\\\\\"nginx_online\\\\\":true,\\\\\"nginx_err\\\\\":null}',
0, 0, 'http', 1, '[]',
0, 0, 0);
\\""
</pre>

Record the <code>id</code> returned by the next SELECT; for this host it is <code><proxy-host-id></code>.

----

== Step 6 — Archive Any Manual Config File ==

If a previous workaround created a hand-edited <code>.conf</code> file in <code>/data/compose/3/data/nginx/proxy_host/</code>, move it out of nginx's include path so it does not conflict with the DB-generated config. The proxy_host directory is owned by root, so use a privileged throwaway container:

<pre>
<docker-host>_SSH "docker run --rm \
-v /data/compose/3/data/nginx/proxy_host:/proxy \
alpine sh -c 'test -f /proxy/<manual-config>.conf && mv /proxy/<manual-config>.conf /proxy/<manual-config>.conf.manual-backup-$(date +%Y%m%d-%H%M%S) || true'"
</pre>

----

== Step 7 — Restart the NPM App Container ==

Restarting regenerates the nginx configs from the DB:

<pre>
<docker-host>_SSH "docker restart nginx-proxy-manager-app"
sleep 5
</pre>

----

== Step 8 — Force Config Generation If Needed ==

Direct DB inserts create the row, but NPM's internal config generator may not write <code>proxy_host/<id>.conf</code> until the host is created or updated through the app. If the config file is missing, force it from inside the app container:

<pre>
HOST_ID=<proxy-host-id>

<docker-host>_SSH "docker exec nginx-proxy-manager-app sh -c 'cat > /tmp/regen-proxy-host.mjs <<EOF
import proxyHostModel from \\"/app/models/proxy_host.js\\";
import internalNginx from \\"/app/internal/nginx.js\\";

const host = await proxyHostModel.query().where(\\"id\\", ${HOST_ID}).first();
if (!host) {
console.error(\\"proxy_host ${HOST_ID} not found\\");
process.exit(1);
}
await internalNginx.configure(proxyHostModel, \\"proxy_host\\", host);
console.log(\\"Regenerated config for\\", host.domain_names);
EOF
node /tmp/regen-proxy-host.mjs'"
</pre>

This writes the config file, tests nginx, updates the row's <code>meta</code>, and reloads nginx.

----

== Step 9 — Verify ==

Check the generated config:

<pre>
<docker-host>_SSH "ls -la /data/compose/3/data/nginx/proxy_host/<proxy-host-id>.conf"
<docker-host>_SSH "cat /data/compose/3/data/nginx/proxy_host/<proxy-host-id>.conf"
</pre>

Test nginx syntax:

<pre>
<docker-host>_SSH "docker exec nginx-proxy-manager-app nginx -t"
</pre>

Test end-to-end HTTP (from <docker-host>, because public DNS may not be live yet):

<pre>
<docker-host>_SSH "curl -fsS -H 'Host: app.example.org' http://127.0.0.1:80/api/health"
# expected: {"status":"ok","authenticated":false}
</pre>

Once Cloudflare DNS points <code>app.example.org</code> at the <vps-relay> VPS relay, <code>http://app.example.org/</code> will work publicly.

----

== Step 10 — Request the SSL Certificate (Manual NPM UI Step) ==

A DB insert cannot complete an ACME DNS-01 challenge. The final certificate step must be done in the NPM Admin UI:

# Open <code>http://<npm-host-zerotier-ip>:81</code> (<docker-host> ZeroTier) or your NPM admin URL.
# '''Hosts → Proxy Hosts''' → click <code>app.example.org</code>.
# Go to the '''SSL''' tab.
# '''SSL Certificate → Request a new SSL Certificate'''.
# Enable '''Force SSL''', '''HTTP/2 Support''', and '''HSTS''' as desired.
# Agree to the Let's Encrypt ToS and request the certificate.

After the certificate issues, NPM updates <code>proxy_host.certificate_id</code> and <code>ssl_forced</code> automatically and regenerates <code><proxy-host-id>.conf</code> with HTTPS listeners.

----

== Troubleshooting ==

{| class="wikitable"
|-
! Symptom
! Cause
! Fix
|-
| <code>Access denied for user 'npm'@'localhost'</code> during backup
| <code>mysqldump</code> used socket instead of TCP
| Add <code>-h127.0.0.1</code>
|-
| Row exists but no <code><id>.conf</code> after restart
| Direct DB insert did not trigger config generator
| Run the Node force-regeneration script in Step 8
|-
| <code>nginx: [emerg] duplicate server_name</code>
| Old manual <code>.conf</code> still in <code>proxy_host/</code>
| Archive/remove it with a privileged container (Step 6)
|-
| <code>curl</code> returns 404 or no response
| DNS not pointing at NPM yet, or wrong <code>forward_host</code> / <code>forward_port</code>
| Verify DNS A record and the <code>proxy_host</code> row
|-
| Cert request fails
| Let's Encrypt rate limit or Cloudflare API token missing
| Check NPM SSL logs; use the unpause link if rate-limited
|}

----

== References ==

* Reusable NPM direct-DB skill: <code>tools/IT-knowledge/skills/npm-direct-db-modification/SKILL.md</code>
* Analyzer repo: <code><your-app-repo></code>
* NPM Proxy Map in orientation: <code><orientation-doc>.md</code> § Published Sites
* Cloudflare/VPS relay notes: <code>tools/IT-knowledge/networking/NPM_Migration_to_Homelab_VPS_Relay_260401.mw</code>

[[Category:Tutorial]]
[[Category:Nginx Proxy Manager]]
[[Category:Docker]]
[[Category:DevOps]]

Organizing Coder Terminals

2026-05-02T08:13:26Z

Justinaquino: Added RCA: tmux send-keys broke launchers, fixed with direct exec; ce-char-gen troubleshooting

== Problem ==

When running multiple AI coding agents (Claude, Kimi, Qwen, OpenCode) in separate GNOME Terminal windows, every tab looks identical — usually titled by the running process name (e.g., "Kimi Code"). After opening 3–4 terminals, it becomes impossible to tell at a glance which terminal belongs to which project without clicking into each one.

GNOME Terminal 3.44+ removed the "Set Title" option from the tab right-click menu, eliminating the old manual workaround.

== Solution ==

Use '''tmux''' inside every terminal:
* One named tmux session per project (e.g., <code>claude</code>, <code>kimi</code>, <code>qwen</code>)
* A <code>title</code> bash command that renames both the tmux window and the terminal title
* Persistent panes — if an AI agent crashes, the pane stays alive and can be respawned

== Quick Start ==

=== Launch All Agents at Once ===

Run on the Ubuntu desktop:
<pre>
~/start_dev_env.sh
</pre>

This opens 5 GNOME Terminal windows:
{| class="wikitable"
! # !! Window Title !! Tmux Session !! Purpose
|-
| 1 || Claude Code — tmux || claude || Claude Code AI agent
|-
| 2 || OpenCode Claude — tmux || opencode-claude || OpenCode (Claude provider)
|-
| 3 || OpenCode Kimi — tmux || kimi || OpenCode (Kimi provider)
|-
| 4 || OpenCode Qwen — tmux || qwen || OpenCode (Qwen provider)
|-
| 5 || Tmux — General || general || Plain bash for git, docker, file ops
|}

Each session survives even if the GNOME Terminal window is closed.

=== Launch Individual Agents ===

Double-click any desktop launcher:
* <code>~/Desktop/claude.sh</code>
* <code>~/Desktop/kimi.sh</code>
* <code>~/Desktop/opencode.sh</code>
* <code>~/Desktop/Qwen.sh</code>

Each launcher auto-creates or reattaches to its tmux session.

== How to Title Your Session ==

=== The Default Title Is the Command Itself ===

Every new terminal opens with the title:
<pre>
title "project"
</pre>

This is intentional — the '''default title is the command reminder'''. You never forget the syntax because it's staring at you from the tab.

=== Change It ===

Inside any terminal, type:
<pre>
title "ce char gen"
</pre>

This does two things:
# Renames the tmux window (visible in the green status bar at the bottom)
# Sets the GNOME Terminal tab/window title

Change it anytime:
<pre>
title "mneme shipgen"
title "IT-knowledge docs"
title "$(hostname)" # reset to hostname
</pre>

The title auto-resets after every shell prompt, so AI agents cannot overwrite it.

=== Tmux-Only Renaming ===
<pre>
tmux rename-window "my project" # rename current window
tmux rename-session "newname" # rename entire session
</pre>

=== Key Shortcuts ===
{| class="wikitable"
! Key !! Action
|-
| Ctrl+b , || Rename current window (interactive prompt)
|-
| Ctrl+b r || Respawn pane (restart AI agent if it crashed)
|-
| Ctrl+b d || Detach session (keeps it running in background)
|-
| Ctrl+b | || Split pane horizontally
|-
| Ctrl+b - || Split pane vertically
|-
| Alt+Arrow || Switch panes
|-
| Ctrl+b R || Reload tmux config
|}

== Reattaching to Sessions ==

If a terminal window is closed, the tmux session keeps running:
<pre>
tmux list-sessions
tmux attach-session -t claude
tmux attach-session -t kimi
</pre>

Aliases added to <code>~/.bashrc</code>:
<pre>
tls # list sessions
tas claude # attach to claude session
</pre>

== Configuration Files ==

{| class="wikitable"
! File !! Purpose
|-
| <code>~/.tmux.conf</code> || Tmux settings (status bar, mouse, key bindings)
|-
| <code>~/.bashrc</code> || <code>title()</code> function + auto-reset + tmux aliases
|-
| <code>~/.config/tmux-launcher.sh</code> || Helper script for desktop launchers
|}

== Troubleshooting ==

{| class="wikitable"
! Symptom !! Cause !! Fix
|-
| Title shows "Kimi Code" instead of custom || AI resets it via escape sequences || <code>PROMPT_COMMAND</code> auto-resets after every prompt
|-
| Tab right-click has no "Set Title" || GNOME Terminal 3.44+ removed it || Use <code>title</code> bash command or <code>Ctrl+b ,</code>
|-
| <code>title</code> command not found || <code>.bashrc</code> not loaded || Start an interactive shell, or run <code>source ~/.bashrc</code>
|-
| Default title shows <code>title "project"</code> || Working as designed — syntax reminder || Type <code>title "your real project"</code> to replace it
|-
| Tmux status bar shows <b>"ce char gen"</b> || Old <code>~/.tmux.conf</code> on host hardcoded the title || Replace host <code>~/.tmux.conf</code> with container's clean version
|-
| AI agent crashed and pane is dead || Process exited || Press <code>Ctrl+b r</code> to respawn
|-
| Session already exists || Previous session still running || <code>tmux attach -t <name></code> or <code>tmux kill-session -t <name></code>
|}

== RCA: Why Tmux Broke the Original Launch Scripts ==

=== What Worked Before (No Tmux) ===
<pre>
distrobox enter agent260411 -- bash -c 'cd /home/justin/opencode260220 && ./csb.sh; exec bash'
</pre>
<code>./csb.sh</code> does <code>exec claude</code>, which replaces the shell with the interactive AI agent. Claude owns the TTY and runs until the user exits.

=== What Broke (First Tmux Attempt) ===
The initial <code>tmux-launcher.sh</code> used <code>tmux send-keys</code> to type commands into a detached session:
<pre>
tmux new-session -s "$SESSION" -n "$WINDOW" -d
tmux send-keys -t "$SESSION:$WINDOW" "./csb.sh" C-m
tmux attach-session -t "$SESSION"
</pre>

=== Why This Failed ===
# '''Race condition''': <code>send-keys</code> types faster than the shell initializes. The command often arrived before bash was ready, causing "command not found" or silent failure.
# '''No TTY guarantee''': Interactive apps (Claude, Kimi) need a controlling terminal. <code>send-keys</code> provides a pane but doesn't guarantee the app receives proper TTY initialization before the keystrokes land.
# '''Exit timing''': If the app started before attach, the user attached to a pane that was already dead or mid-execution.

=== The Fix ===
Replace <code>send-keys</code> with direct command execution via a wrapper script. This gives tmux the full command upfront, so it initializes the TTY properly before the app starts — exactly like the original scripts, just wrapped in tmux.

== See Also ==

* [[IT Knowledge Base]]
* [[Forgejo]]
* [[Docker Stacks]]

[[Category:System Administration]]
[[Category:Development Environment]]
[[Category:AI Agents]]

Main Page

2026-05-02T07:31:02Z

Justinaquino: Added Organizing Coder Terminals to IT index

__NOTOC__
<div style="background:#f8f9fa; border:1px solid #ddd; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
Welcome to the '''Comfac IT Knowledge Base'''. Use the sections below to find guides, SOPs, and references organized by topic.
</div>

== ERPNext / Frappe ==
<div style="column-count:2; column-gap:2em;">
* [[Frappe HRMS]] — '''HR & Payroll''' (with Philippine Localization)
* [[Frappe ERPNext/Webshop]] — '''E-Commerce Webshop''' (setup, architecture, chapters)
* [[Manufacturing v16 260125]]
* [[ERpnext Asset Management Procedure 260113]]
* [[ERPNext HR Module Outline]]
* [[ERPNEXT Payroll POC 251212]]
* [[Comfac ERPNext Strategy Canvas (Expanded)]]
* [[PAD-Driven ERPNext Strategy 260303]] — PAD/AI-agentic implementation strategy for Frappe ERPNext
* [[ERPNext v15 Docker Setup Guide]] — Local Docker setup for evaluation, testing, and student use
* [[Frappe Links and References]]
* [[Using Frappe Wiki]]
* [https://docs.frappe.io/cloud/guidelines-for-contributing-regional-compliance-app Guidelines for Contributing Regional Compliance App]
* [https://docs.frappe.io/cloud/what-are-benches-and-bench-groups What are Benches?]
</div>

== System Administration & Self-Hosting ==
<div style="column-count:2; column-gap:2em;">
* [[Networking PfSense Index]] — Consolidated index of all networking, pfSense, DNS, and infrastructure guides
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]]
* [[Controller Systems 251213-01]]
* [[Power Distribution Tree 251213]]
* [[Introduction: Why Self-Host Your Email?]]
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]]
* [[Mailcow SOGo: Creating Filters for Events, Approvals, and Organizational Emails]]
* [[Spoof Timezone Extension – Setup Guide for Comfac Staff]]
* [[Viber Focus-Stealing]]
* [[🌐 WordPress Website — *You Own Everything, Learn Everything*]]
* [[Portainer to Docker Compose Migration Guide]]
* [[Organizing Coder Terminals]] — Tmux + dynamic titles for managing multiple AI agent terminals
* [[Editing Mastodon Docker Deployment Guide 260402]]
</div>

== Storage & Hardware ==
<div style="column-count:2; column-gap:2em;">
* [[TrueNAS Configuration Options & Scale Options 251130]]
* [[TrueNAS Business Plan: Project 251212]]
* [[Comparison: TrueNAS Mini X+ vs Dell Precision 3680 Tower (2025)]]
* [[Backblaze Drive Stats for Server and Storage Qualification]]
* [[Industrial Controllers and Water Utilities 251011]]
</div>

== AI & Machine Learning ==
<div style="column-count:2; column-gap:2em;">
* [[OpenWebUI - 251128-justin]]
* [[Comfac GPU Scaling and AI Research Goals]]
* [[🧠 Process: Selecting and Installing the Right Ollama Model for Your Hardware]]
* [[Ollama GNOME System Tray Panel 260401]] — GNOME system tray toggle to start/stop Ollama and reclaim VRAM
* [[Proceedural Agentic Development Methodology 260304]] — Methodology for systematic agent use
* [[Project OpenCoder: AI Independence Initiative]] — Strategic roadmap for manufacturing intelligence
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 Modelfile fix for tool calling in OpenCode; thinking mode suppression; HDD vs SSD findings
* [[OpenCode Multi-Provider Configuration Guide 260401]] — Dual-mode AI coding setup with Kimi cloud + Ollama local models via Distrobox
* [[PAD-Driven ERPNext Strategy 260303]] — Procedural Agentic Development for Frappe/ERPNext configuration and deployment
</div>

== Job Descriptions ==
<div style="column-count:2; column-gap:2em;">
* [[Job Descriptions]] — Index of all official job descriptions (IT, Engineering, Sales)
* [[JD IT Project Staff]] — IT Project Staff
* [[JD Security Compliance Assistant 260224]] — Security and Compliance Assistant (SCA)
* [[JD Engineering Designer 260108]] — Engineering Designer
* [[JD Engineering Supervisor 260109]] — Engineering Supervisor
* [[JD Technical Sales 260112]] — Technical Sales Engineer
* [[JD Marketing Assistant 251119]] — Marketing Assistant
</div>

== IT Operations & SOPs ==
<div style="column-count:2; column-gap:2em;">
* [[SCA Program Plan 260320]] — Security & Compliance Assistant Program Plan v3 (ISO 9001/27001, PDCA, distributed audit model)
* [[SOP: Inter-Company Ordering and Production Process 260203]] — Ordering and production workflow between Sister Companies and the Cabuyao Plant
* [[Memo: Team Roles & Reporting Process Clarification 260320]] — Role boundaries, data ownership, and the new ERPNext-driven reporting paradigm
* [[Standard Operating Procedure: Distributed Minute Taking & Task Ownership 251208]]
* [[Business Continuity]]
* [[Procedure: CC-Blast Data Breach Prevention]]
* [[8D (Eight Discipline) Problem Solving Procedure]]
* [[Offline Malware Remediation & Data Recovery]]
* [[Troubleshooting: Access & Permission Issues]]
* [[Steps to Repair and OCR a Scanned or Corrupted PDF in Ubuntu]]
* [[IT IMPORTS PROCESSES]]
* [[IT Purchase Requests 241126]]
* [[IT REQUEST (OP-ERP-ITR) - EDITED 250801]]
</div>

== Sales & Business ==
<div style="column-count:2; column-gap:2em;">
* [[Comfac Sales Knowledge Base]]
* [[Comfac CRM – Customer Qualification & Conversion Process]]
* [[Partner Reseller Pricing 251109]]
* [[Biz Analysis Methodology 251109]]
* [[2026 MIS IT KRA KPI Biz Plan]]
* [[SALES INVOICE TAX OUTPUT 250829]]
* [[Projects in Process Report 251023]]
</div>

== Tools & Productivity ==
<div style="column-count:2; column-gap:2em;">
* [[Excel Description Filler Tool 📝]]
* [https://github.com/Comfac-Global-Group/comfac-studies Comfac Studies - Spaced Repetiton Active Recall]
* [[LibreOffice / Nextcloud Office – "Due Tasks" Conditional Formatting]]
* [[Google Drive and Shared Drive Training]]
* [[260108 CGG- GitHub Administration Guide]]
</div>

== Wiki & Documentation ==
<div style="column-count:2; column-gap:2em;">
* [[Mediawiki Setting Up Guide]]
* [[Contributing to Only Office 260307]]
* [[Mediawiki Additional Configuration]]
* [[Mediawiki Docker Migration Guide]]
* [[Home]]
</div>

== Tutorials ==
<div style="column-count:2; column-gap:2em;">
* [[Claude Code Isolation and Burner Workflow 260211]] — Secure AI development environment setup
* [[Opencode isolation and burner workflow 260216]] — OpenCode CLI isolation procedures
* [[LibreOffice Calc NumToWords Extension Complete Guide]] — Extension development
* [[ERPNext v15 Docker Setup Guide]] — ERPNext v15 local Docker setup (students, evaluators, thin-client demos)
* [[Erpnextv15-SSH-setup-241111]] — ERPNext v15 SSH/Portainer production setup
* [[Git-Mediawiki Local Editing 260223]] — Wiki editing with Git
* [[Understanding & Fixing Kernel Panics 260212]] — System debugging
* [[OpenCode in Android Termux 260303]] — OpenCode in Android
* [[OpenCoder Qwen35 Agentic Setup 260330]] — Qwen3.5 agentic setup: Modelfile, tool calling fix, storage impact
* [[Lora Basics 260304]] — LORA research
* [https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210 Opencode Copy-paste Clipboard doesnt Work - Solution] https://github.com/anomalyco/opencode/issues/4283#issuecomment-4083399210
</div>

== Research ==
<div style="column-count:2; column-gap:2em;">
* [[Ladybird Browser]] — Browser engine development
* [[Computing Architecture]] — System design principles
* [[Backblaze Drive Stats for Server and Storage Qualification 260219]] — Drive reliability analysis
</div>

----

== For Users Only ==
* [[Private:Private Ngani]]
* [[Private:Private Nganipart2]]

== CIT-OJT Project Documentations ==
* [[OJTDocs: For OJTs only]]

== Need Help? ==
<div style="column-count:2; column-gap:2em;">
* [[Troubleshooting: Access & Permission Issues]]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents MediaWiki User's Guide]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
</div>

Organizing Coder Terminals

2026-05-02T07:27:04Z

Justinaquino: Updated: default title is now the command reminder 'title "project"' (2026-05-02)

== Problem ==

When running multiple AI coding agents (Claude, Kimi, Qwen, OpenCode) in separate GNOME Terminal windows, every tab looks identical — usually titled by the running process name (e.g., "Kimi Code"). After opening 3–4 terminals, it becomes impossible to tell at a glance which terminal belongs to which project without clicking into each one.

GNOME Terminal 3.44+ removed the "Set Title" option from the tab right-click menu, eliminating the old manual workaround.

== Solution ==

Use '''tmux''' inside every terminal:
* One named tmux session per project (e.g., <code>claude</code>, <code>kimi</code>, <code>qwen</code>)
* A <code>title</code> bash command that renames both the tmux window and the terminal title
* Persistent panes — if an AI agent crashes, the pane stays alive and can be respawned

== Quick Start ==

=== Launch All Agents at Once ===

Run on the Ubuntu desktop:
<pre>
~/start_dev_env.sh
</pre>

This opens 5 GNOME Terminal windows:
{| class="wikitable"
! # !! Window Title !! Tmux Session !! Purpose
|-
| 1 || Claude Code — tmux || claude || Claude Code AI agent
|-
| 2 || OpenCode Claude — tmux || opencode-claude || OpenCode (Claude provider)
|-
| 3 || OpenCode Kimi — tmux || kimi || OpenCode (Kimi provider)
|-
| 4 || OpenCode Qwen — tmux || qwen || OpenCode (Qwen provider)
|-
| 5 || Tmux — General || general || Plain bash for git, docker, file ops
|}

Each session survives even if the GNOME Terminal window is closed.

=== Launch Individual Agents ===

Double-click any desktop launcher:
* <code>~/Desktop/claude.sh</code>
* <code>~/Desktop/kimi.sh</code>
* <code>~/Desktop/opencode.sh</code>
* <code>~/Desktop/Qwen.sh</code>

Each launcher auto-creates or reattaches to its tmux session.

== How to Title Your Session ==

=== The Default Title Is the Command Itself ===

Every new terminal opens with the title:
<pre>
title "project"
</pre>

This is intentional — the '''default title is the command reminder'''. You never forget the syntax because it's staring at you from the tab.

=== Change It ===

Inside any terminal, type:
<pre>
title "ce char gen"
</pre>

This does two things:
# Renames the tmux window (visible in the green status bar at the bottom)
# Sets the GNOME Terminal tab/window title

Change it anytime:
<pre>
title "mneme shipgen"
title "IT-knowledge docs"
title "$(hostname)" # reset to hostname
</pre>

The title auto-resets after every shell prompt, so AI agents cannot overwrite it.

=== Tmux-Only Renaming ===
<pre>
tmux rename-window "my project" # rename current window
tmux rename-session "newname" # rename entire session
</pre>

=== Key Shortcuts ===
{| class="wikitable"
! Key !! Action
|-
| Ctrl+b , || Rename current window (interactive prompt)
|-
| Ctrl+b r || Respawn pane (restart AI agent if it crashed)
|-
| Ctrl+b d || Detach session (keeps it running in background)
|-
| Ctrl+b | || Split pane horizontally
|-
| Ctrl+b - || Split pane vertically
|-
| Alt+Arrow || Switch panes
|-
| Ctrl+b R || Reload tmux config
|}

== Reattaching to Sessions ==

If a terminal window is closed, the tmux session keeps running:
<pre>
tmux list-sessions
tmux attach-session -t claude
tmux attach-session -t kimi
</pre>

Aliases added to <code>~/.bashrc</code>:
<pre>
tls # list sessions
tas claude # attach to claude session
</pre>

== Configuration Files ==

{| class="wikitable"
! File !! Purpose
|-
| <code>~/.tmux.conf</code> || Tmux settings (status bar, mouse, key bindings)
|-
| <code>~/.bashrc</code> || <code>title()</code> function + auto-reset + tmux aliases
|-
| <code>~/.config/tmux-launcher.sh</code> || Helper script for desktop launchers
|}

== Troubleshooting ==

{| class="wikitable"
! Symptom !! Cause !! Fix
|-
| Title shows "Kimi Code" instead of custom || AI resets it via escape sequences || <code>PROMPT_COMMAND</code> auto-resets after every prompt
|-
| Tab right-click has no "Set Title" || GNOME Terminal 3.44+ removed it || Use <code>title</code> bash command or <code>Ctrl+b ,</code>
|-
| <code>title</code> command not found || <code>.bashrc</code> not loaded || Start an interactive shell, or run <code>source ~/.bashrc</code>
|-
| Default title shows <code>title "project"</code> || Working as designed — it's the syntax reminder || Type <code>title "your real project"</code> to replace it
|-
| AI agent crashed and pane is dead || Process exited || Press <code>Ctrl+b r</code> to respawn
|-
| Session already exists || Previous session still running || <code>tmux attach -t <name></code> or <code>tmux kill-session -t <name></code>
|}

== See Also ==

* [[IT Knowledge Base]]
* [[Forgejo]]
* [[Docker Stacks]]

[[Category:System Administration]]
[[Category:Development Environment]]
[[Category:AI Agents]]

Organizing Coder Terminals

2026-05-02T07:09:30Z

Justinaquino: Created article on organizing coder terminals with tmux (2026-05-02)

Forgejo Pages

2026-04-28T13:24:36Z

Justinaquino: Added Forgejo Pages setup guide

= Forgejo Pages — Complete Setup Guide =

<blockquote>**Wiki:** wiki.gi7b.org | **Last updated:** 2026-04-28</blockquote>
<blockquote>**Status:** Production — `pages.gi7b.org` live on PC03</blockquote>

----

== Overview ==

Forgejo does '''not''' have a built-in static site server. To serve Pages, you run a
separate <code>ronmi/forgejo-pages</code> container alongside Forgejo. It reads files from a
special branch in each repo via the Forgejo API and serves them over HTTP.

<syntaxhighlight>
Browser → Cloudflare DNS → NPM (SSL) → forgejo-pages:8080 → Forgejo API → repo branch
</syntaxhighlight>

* **Forgejo:** `https://git.gi7b.org` (container: `forgejo`, internal port 3000)
* **Pages server:** `https://pages.gi7b.org` (container: `forgejo-pages`, internal port 8080)
* **Routing:** path-based — `https://pages.gi7b.org/{owner}/{repo}/`
* **Branch name:** `static-pages` (exact, hardcoded default in this image)

----

== Gotchas — Read This First ==

=== 1. There is no built-in Pages in Forgejo ===
<code>ENABLE_FORGEJO_PAGES = true</code> in <code>app.ini</code> does nothing. It is not a real setting.
You need the external <code>ronmi/forgejo-pages</code> container.

=== 2. Branch must be named exactly `static-pages` ===
Not <code>gh-pages</code>, not <code>pages</code>, not <code>static_pages</code>. The image default is <code>static-pages</code>.
If the branch doesn't exist in the repo, the server returns 404.

=== 3. Use two separate tokens ===
{| class="wikitable"
! Token !! Scope !! Used by
|-
| `forgejo-pages` service token | `repository: read` | Docker container reads repo files via API
|-
| `git-push` personal token | `repository: read+write` + `user: read` | You/AI push code via git CLI
|}

Never use your account password for git CLI over HTTPS — it will be rejected.

=== 4. NPM forward port is the internal container port ===
When NPM uses the container DNS name (<code>forgejo-pages</code>), forward to port <code>8080</code> (internal).
If using the host IP (<code>192.168.196.76</code>), forward to port <code>8585</code> (exposed host port).
Mixing these up causes 502 Bad Gateway.

=== 5. Remove NPM Access List from git.gi7b.org ===
HTTP Basic Auth at the NPM layer blocks git CLI, API calls, and webhooks.
Forgejo's own auth (tokens, SSH keys, 2FA) is the correct security layer for a git host.

=== 6. SSH is more reliable than HTTPS for git push ===
HTTPS git auth has multiple failure modes (token scopes, credential helpers, NPM layers).
SSH just works. Set it up once per machine and never deal with tokens for pushing again.

----

== Docker Compose Setup ==

'''File:''' <code>/home/user/forgejo/compose.yml</code>

<syntaxhighlight lang="yaml">
services:
server:
image: codeberg.org/forgejo/forgejo:13
container_name: forgejo
restart: unless-stopped
environment:
- USER_UID=1000
- USER_GID=1000
volumes:
- ./data:/data
- /etc/localtime:/etc/localtime:ro
ports:
- "3001:3000"
- "223:22"
networks:
- internal
- proxy

pages:
image: ronmi/forgejo-pages
container_name: forgejo-pages
restart: unless-stopped
command: serve --server http://forgejo:3000 --token ${FORGEJO_PAGES_TOKEN} --bind :8080
ports:
- "8585:8080"
networks:
- internal
- proxy
depends_on:
- server

networks:
internal:
driver: bridge
proxy:
external: true
name: npm_proxy
</syntaxhighlight>

'''File:''' <code>/home/user/forgejo/.env</code>

<syntaxhighlight>
FORGEJO_PAGES_TOKEN=your_read_only_repository_token_here
</syntaxhighlight>

----

== Tokens ==

=== Service Token (for forgejo-pages container) ===
Generated in Forgejo → Settings → Applications:
* **Name:** `forgejo-pages-service`
* **Repository and Organization Access:** All
* **Permissions:** `repository: Read` only, everything else No access
* Goes in `/home/user/forgejo/.env` as `FORGEJO_PAGES_TOKEN`

=== Personal Push Token (for git CLI / AI agents) ===
Generated in Forgejo → Settings → Applications:
* **Name:** `git-push-{machinename}`
* **Repository and Organization Access:** All
* **Permissions:** `repository: Read and Write`, `user: Read`, everything else No access
* Used as the **password** when git prompts, or embedded in SSH-less workflows

----

== NPM Proxy Host — pages.gi7b.org ==

'''Details tab:'''
{| class="wikitable"
! Field !! Value
|-
| Domain Names | `pages.gi7b.org`
|-
| Scheme | `http`
|-
| Forward Hostname / IP | `forgejo-pages` (container name) OR `192.168.196.76` (host IP)
|-
| Forward Port | `8080` if using container name / `8585` if using host IP
|-
| Cache Assets | ✅ On
|-
| Block Common Exploits | ✅ On
|-
| Websockets Support | Off
|-
| Access List | **Publicly Accessible** (no HTTP Basic Auth)
|}

'''SSL tab:'''
{| class="wikitable"
! Field !! Value
|-
| SSL Certificate | `pages.gi7b.org` (Let's Encrypt)
|-
| Force SSL | ✅ On
|-
| HTTP/2 Support | ✅ On
|}

----

== SSH Setup for Git Push (per machine) ==

Run once on each machine that needs to push to Forgejo:

<syntaxhighlight lang="bash">
# Generate key
ssh-keygen -t ed25519 -C "{machinename}-git" -f ~/.ssh/id_ed25519 -N ""

# Show public key to add to Forgejo
cat ~/.ssh/id_ed25519.pub
</syntaxhighlight>

Add the public key in Forgejo → Settings → SSH / GPG Keys → Add Key.

Set remote URL to SSH (note custom port 223):

<syntaxhighlight lang="bash">
git remote set-url origin ssh://git@192.168.196.76:223/{owner}/{repo}.git
</syntaxhighlight>

<blockquote>Use the ZeroTier IP `192.168.196.76` directly — port 223 is not forwarded through</blockquote>
<blockquote>the public relay (PC06). SSH over ZeroTier is reliable for internal machines.</blockquote>
<blockquote>For external machines, either forward port 223 through PC06 or use HTTPS with a token.</blockquote>

----

== Publishing a Page (Repeatable Workflow) ==

=== New repo — first time ===

<syntaxhighlight lang="bash">
git clone ssh://git@192.168.196.76:223/{owner}/{repo}.git
cd {repo}

# Create orphan branch (no shared history with main)
git checkout --orphan static-pages
git rm -rf . 2>/dev/null || true

# Create your site
mkdir -p .
cat > index.html <<'EOF'
<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><title>My Page</title></head>
<body>
<h1>Hello from Forgejo Pages</h1>
</body>
</html>
EOF

git add .
git commit -m "Initial pages content"
git push -u origin static-pages
</syntaxhighlight>

Live immediately at: <code>https://pages.gi7b.org/{owner}/{repo}/</code>

=== Update existing pages ===

<syntaxhighlight lang="bash">
git checkout static-pages
# edit files
git add .
git commit -m "Update pages"
git push
</syntaxhighlight>

=== Via Forgejo Web UI (no git needed) ===

1. Open repo → click '''New File'''
2. Filename: <code>index.html</code>, add content
3. In commit section: select '''"Create a new branch"'''
4. Branch name: <code>static-pages</code>
5. Commit

----

== Verification ==

<syntaxhighlight lang="bash">
# Local test (on PC03)
curl -i http://localhost:8585/{owner}/{repo}/

# Expected: HTTP/1.1 200 OK + your HTML

# Check pages server logs
docker logs forgejo-pages --tail 20
</syntaxhighlight>

Browser: <code>https://pages.gi7b.org/{owner}/{repo}/</code> (trailing slash matters)

----

== Troubleshooting ==

{| class="wikitable"
! Symptom !! Cause !! Fix
|-
| 400 Bad Request | No valid owner/repo path in URL | URL must be `/{owner}/{repo}/`
|-
| 404 Not Found | `static-pages` branch missing or no `index.html` at root | Create branch, push `index.html` to root
|-
| 502 Bad Gateway | NPM port mismatch or container not on `npm_proxy` network | Check forward port (8080 internal / 8585 host). Verify: `docker network inspect npm_proxy \ | grep forgejo`
|-
| Auth failed (git push) | Wrong token scope or using account password | Use personal push token with `repository: write`. Use SSH instead.
|-
| SSH connection refused | Port 223 not reachable from external machine | Use ZeroTier IP for internal machines. Forward port via PC06 for external.
|-
| Pages container crash-looping | Missing `serve` command or bad token | Check `docker logs forgejo-pages`. Verify `.env` token is correct.
|-
| Stale content | Browser cache | Hard refresh (Ctrl+Shift+R) or test with `curl`
|}

Buzz Transcription

2026-04-24T18:43:50Z

Justinaquino: Add Buzz meeting transcription guide + Vulkan GPU & OOM investigation (2026-04-25)

Buzz is an open-source, offline-capable audio/meeting transcription tool powered by OpenAI Whisper (via whisper.cpp). On this system it is installed as a Flatpak and runs with Vulkan GPU acceleration on the AMD RX 7600.

== How to Transcribe a Meeting ==

=== Prerequisites ===
* Buzz installed (Flatpak: <code>io.github.chidiwilliams.Buzz</code>)
* A model downloaded — recommended: <code>ggml-large-v3-turbo</code> for quality, <code>ggml-tiny</code> for speed
* Models are stored at <code>~/.var/app/io.github.chidiwilliams.Buzz/cache/Buzz/models/</code>

=== File Transcription (Meeting Recording) ===
# Launch Buzz from the application menu or run: <code>flatpak run io.github.chidiwilliams.Buzz</code>
# Go to '''File → Import Media''' and select your meeting recording (MP3, WAV, M4A, etc.)
# In the transcription dialog:
#* '''Model''': Select <code>large-v3-turbo</code> (best quality for meetings)
#* '''Task''': Transcribe
#* '''Language''': Select your language or leave on Auto
#* '''Extract Speech''': '''Leave unchecked''' for files longer than ~30 minutes (see [[#OOM Crash with Large Files|OOM Crash]] below)
#* '''Output''': SRT, VTT, or TXT depending on your need
# Click '''Transcribe'''
# When complete, the transcript appears in the main window and is saved alongside the source file

=== Live Transcription (Real-Time) ===
# Go to '''File → Record and Transcribe'''
# Select your microphone input
# Choose model and language
# Click '''Record''' — transcription appears live on screen
# Stop recording when done; export via '''File → Export'''

=== Recommended Settings for Meetings ===
{| class="wikitable"
|-
! Setting !! Value !! Reason
|-
| Model || large-v3-turbo || Best accuracy; 1.6 GB VRAM, runs on RX 7600
|-
| Extract Speech || '''Off''' for files >30 min || Demucs uses 8–15 GB RAM for long files (OOM risk)
|-
| Language || Set explicitly || Faster than auto-detect
|-
| Task || Transcribe || Use Translate only if you need English output from another language
|}

=== Before Each Session: Clear Swap ===
Prior transcription sessions can leave stale pages in swap. Run this before starting a long transcription:
<pre>sudo swapoff -a && sudo swapon -a</pre>
This is safe when free RAM exceeds swap used (typical on this system: 15+ GB free, 8 GB swap).

== GPU Acceleration ==

Buzz's Flatpak installation includes a Vulkan-enabled <code>whisper-cli</code>. On this system, GPU inference is automatically active — no configuration needed.

* GPU in use: '''AMD RX 7600 (RDNA3, RADV NAVI33)'''
* Confirmed by: <code>whisper_backend_init_gpu: using Vulkan0 backend</code> in runtime output
* Buzz checks for Vulkan at startup (<code>IS_VULKAN_SUPPORTED</code>) and omits the <code>--no-gpu</code> flag when found

To force CPU inference (for debugging):
<pre>flatpak override --user io.github.chidiwilliams.Buzz --env=BUZZ_FORCE_CPU=true</pre>

To revert:
<pre>flatpak override --user --reset io.github.chidiwilliams.Buzz</pre>

== OOM Crash with Large Files ==

=== Symptom ===
When selecting <code>ggml-large-v3-turbo</code> in Buzz and starting a transcription on a long file, the application crashes. VRAM usage never visibly climbs before the crash.

=== Root Cause ===
The crash is caused by the '''Extract Speech (Demucs)''' pre-processing step, not the large model.

Demucs is a PyTorch-based music source separation model that strips background noise from audio before passing it to the transcription engine. It processes raw PCM audio at full float32 precision entirely in RAM:

{| class="wikitable"
|-
! Audio Duration !! Compressed Size !! RAM Required (Demucs)
|-
| 1 hour MP3 || ~60 MB || 500 MB – 1 GB
|-
| 3–4 hour session || ~220 MB || 8–15 GB peak
|}

The combination that caused the crash:
# Swap already exhausted from previous sessions
# Extract Speech (Demucs) triggered on a ~220 MB MP3 (~3–4 hours of audio)
# Python RAM usage exceeded available RAM + swap ceiling
# OOM killer terminated the process at 22 GB RSS
# <code>whisper-cli</code> was never launched → no VRAM activity observed

=== Why VRAM Never Climbed ===
<code>whisper-cli</code> runs as a subprocess of the Python GUI. The OOM kill happened during Demucs pre-processing — <code>whisper-cli</code> was never started, so no VRAM allocation occurred.

From the Buzz log at crash time:
<pre>~/.var/app/io.github.chidiwilliams.Buzz/.local/state/Buzz/log/logs.txt</pre>
The last entry was <code>Will extract speech</code> — the log never reached <code>Starting whisper file transcription</code>.

=== Fix ===
'''Uncheck "Extract Speech"''' in the Buzz transcription dialog for any file longer than ~30 minutes. The <code>large-v3-turbo</code> model has built-in noise tolerance that makes Demucs pre-processing unnecessary in most cases.

Optionally, grow the swapfile if you need Extract Speech for shorter files:
<pre>sudo swapoff /swap.img
sudo fallocate -l 16G /swap.img
sudo mkswap /swap.img
sudo swapon /swap.img</pre>

== Environment Variables ==

{| class="wikitable"
|-
! Variable !! Default !! Effect
|-
| <code>BUZZ_FORCE_CPU</code> || false || Set to <code>true</code> to disable GPU inference
|-
| <code>BUZZ_WHISPERCPP_N_THREADS</code> || cpu_count / 2 || Override thread count for whisper-cli
|}

Set via: <code>flatpak override --user io.github.chidiwilliams.Buzz --env=VAR=value</code>

== Key File Paths ==

{| class="wikitable"
|-
! Path !! Description
|-
| <code>/var/lib/flatpak/app/io.github.chidiwilliams.Buzz/.../buzz/whisper_cpp/whisper-cli</code> || Bundled Vulkan whisper-cli (libwhisper 1.8.3)
|-
| <code>~/.var/app/io.github.chidiwilliams.Buzz/cache/Buzz/models/</code> || Buzz model cache (ggml binaries)
|-
| <code>~/.var/app/io.github.chidiwilliams.Buzz/.local/state/Buzz/log/logs.txt</code> || Buzz application log
|-
| <code>~/.var/app/io.github.chidiwilliams.Buzz/config/Buzz.conf</code> || Buzz settings
|-
| <code>~/whisper.cpp/build/bin/whisper-cli</code> || Custom Vulkan-enabled whisper.cpp build
|-
| <code>~/bin/whisper-cli-vulkan</code> || Wrapper script for custom build (sets <code>LD_LIBRARY_PATH</code>)
|-
| <code>~/.local/share/pipx/venvs/buzz-captions/lib/python3.12/site-packages/buzz/whisper_cpp/</code> || pipx install whisper_cpp directory (directly modifiable)
|}

== Investigation Summary ==

{| class="wikitable"
|-
! Question !! Finding
|-
| Is Buzz using the RX 7600? || '''Yes.''' <code>using Vulkan0 backend</code> confirmed inside the Flatpak sandbox.
|-
| Was <code>--no-gpu</code> being added? || '''No.''' <code>IS_VULKAN_SUPPORTED = True</code> in the sandbox; flag is never appended.
|-
| Does the large model load correctly? || '''Yes.''' 1.6 GB to VRAM, transcribes in ~1.25s on a short clip.
|-
| What caused the crash? || '''Extract Speech (Demucs) OOM.''' Python killed at 22 GB RSS before whisper-cli launched.
|-
| Why was VRAM not climbing? || <code>whisper-cli</code> was never started — process died during Demucs pre-processing.
|-
| Fix? || '''Uncheck Extract Speech''' for long files. Clear swap before sessions.
|}

''Investigation date: 2026-04-25. System: Ubuntu 24.04, AMD RX 7600, Buzz 1.4.4 (Flatpak).''

PfSense Sales Training Material

2026-04-23T11:59:49Z

Justinaquino: Restructure: client-friendly networking table, expand myths section, add 5-Pillar Scoping Framework

= pfSense Sales Training Material =

'''Reference:''' [https://chatgpt.com/share/67c82515-7074-800e-b29c-0df75f5492f3 Full Session Log]

----

== 1. Introduction ==

; Objective
: Provide a clear, layman-friendly explanation of what a firewall is, why pfSense is a powerful solution, and how its key features protect networks.

; Audience
: Sales teams, marketing, and non-technical staff who need to explain the technology to potential customers — non-technical decision-makers, IT managers, and SMB owners.

----

== 2. Network Basics ==

; Definition
: Networking is the ability to connect computers and systems together. It occurs when more than one device communicates with another device or group of devices.

=== Networking Disciplines ===

==== ECE (Electronics and Communication Engineering) ====
* Focuses on how electronic devices work and on designing/building network hardware from basic components.
* In the Philippines, a PRC ECE license is required to sign off plans for CCTV installations — the only legally mandated network designs (CCTV and phone lines).
* '''Sales Note:''' Clients needing custom electronic solutions (for automation or high-security requirements) will require ECE expertise.

==== IT (Information Technology) ====
* Specializes in deploying and integrating off-the-shelf networking equipment.
* Advanced configurations improve reliability, scalability (hundreds to thousands of users), and automation for convenience.
* '''Sales Note:''' Larger-scale deployments and convenience features command higher-level IT skills and corresponding investment.

=== Networking Functions ===

{| class="wikitable"
|-
! Function
! What This Means for Your Business
! Technical Role
|-
| '''Connecting to the Internet'''<br/>(WAN — Wide Area Network)
| Your business's door to the outside world — controls what comes in and what goes out.
| Connects the facility to external networks (Internet or other sites).
|-
| '''Connecting Your Devices Together'''<br/>(LAN — Local Area Network)
| Lets computers, printers, servers, and phones talk to each other inside your office.
| Connects devices within the facility for internal communications.
|-
| '''Staying Online Even When Hardware Fails'''<br/>(High Availability)
| Prevents downtime — if one device fails, another takes over automatically.
| Builds redundancy and resilience so services stay online despite failures.
|-
| '''Controlling Who Can Access What'''<br/>(User Management)
| Staff, guests, and contractors each see only what they're supposed to see.
| Implements captive portals, LDAP, RADIUS to organize users by roles and privileges.
|-
| '''Protecting Against Attacks and Breaches'''<br/>(Security)
| Keeps threats out and sensitive data in — separates risky zones from critical systems.
| Establishes hardened systems using DMZs (buffer zones) and proxy servers.
|-
| '''Wireless Connectivity'''<br/>(Wi-Fi)
| Lets staff and devices connect without cables — can be segmented by department or role.
| Deploys mesh or enterprise Wi-Fi for convenient, flexible connectivity.
|-
| '''Wired Connectivity'''<br/>(Ethernet/LAN Cabling)
| High-speed, reliable connections for servers, workstations, and critical equipment.
| Provides high-bandwidth, low-latency connections for critical systems.
|}

----

== 3. Key Myths & Objections ==

Understanding and countering these objections is critical in every sales conversation.

=== Myth 1: "We're too small — we don't need a firewall" ===
; Reality
: Small and medium businesses are the most targeted precisely because attackers know they have weak defenses. Anyone hosting a web server, NAS, ERP system, or remote workers needs a firewall. Size is not protection.

=== Myth 2: "Our ISP router/modem is enough" ===
; Reality
: ISP-provided routers are consumer-grade equipment with no intrusion detection, no network segmentation, no VPN capability, and no traffic monitoring. They are designed for convenience, not security.

=== Myth 3: "Firewalls only block traffic" ===
; Reality
: Modern firewalls do far more — they segment your network into zones, prioritize critical traffic (e.g., video calls over casual browsing), detect intrusions in real time, and enable secure VPN access for remote workers.

=== Myth 4: "A VPN is all the security I need" ===
; Reality
: A VPN only encrypts traffic between two points. It does nothing to protect your internal network from threats already inside, compromised devices, or unauthorized users on-site.

=== Myth 5: "The cloud handles our security" ===
; Reality
: Cloud providers secure their own infrastructure. Your office network, on-site devices, servers, and traffic between locations remain entirely your responsibility.

=== Myth 6: "Hardware firewalls are different from software firewalls" ===
; Reality
: All firewalls are computers running software. A "hardware firewall" is simply dedicated hardware optimized to run firewall software. Performance scales by upgrading network interface cards: 100 Mbps → 1 Gbps → 10 Gbps → 100 Gbps.

=== Myth 7: "Competitor products are better out-of-the-box" ===
; Reality
: Competitors like Fortinet and Cisco lock key features behind annual licenses that expire. When you stop paying, features stop working. pfSense delivers enterprise-grade features permanently — only updates and support require payment.

----

== 4. Why pfSense? ==

* '''Open Source:''' No recurring feature licenses; you pay only for support and updates. When support lapses, pfSense continues to work — only security updates stop.
* '''Enterprise Features:'''
** LAN/WAN routing and segmentation
** VPN (remote access and site-to-site)
** IDS/IPS (intrusion detection and prevention)
** High Availability & Load Balancing
** DHCP, DNS, and user Authentication
* '''No License Lock-in:''' Other vendors "rent" features that expire with licenses. pfSense features remain available indefinitely.

----

== 5. Core Functions & Features ==

=== Primary Functions ===

{| class="wikitable"
|-
! Function
! Explanation
|-
| '''LAN'''
| Segments and protects internal network traffic to enforce security zones.
|-
| '''WAN'''
| Controls access to the Internet; filters inbound/outbound traffic.
|-
| '''VPN'''
| Creates encrypted tunnels for secure remote access or site-to-site links.
|-
| '''IDS/IPS'''
| Monitors traffic for threats and automatically blocks or alerts on intrusions.
|}

=== Secondary Features ===

* '''Authentication:''' Integrates with Active Directory, LDAP, RADIUS for user-based firewall policies.
* '''DHCP:''' Assigns IP addresses automatically to devices on the network.
* '''DNS:''' Acts as resolver or forwarder to improve name lookup speed and security.
* '''Load Balancer / HA:''' Distributes traffic across multiple WAN links or appliances and provides failover.

----

== 6. The 5-Pillar Scoping Framework ==

Use this framework on every prospect conversation. Work through each pillar in order — each answer builds context for the next. The goal is to understand the client's situation before recommending any hardware or solution.

=== Pillar 1: Stakes ===

''Budget equals stakes. Before pricing anything, establish what is at risk.''

; Key Questions
: "What happens to your business if the network goes down for a full day?"
: "What data do you store or process — customer records, financial data, health information?"
: "Have you experienced a breach or outage before? What did it cost you?"

; What It Tells You
: The client's tolerance for risk and the true value of the protection being sold. A business that loses 50,000 PHP per hour of downtime has very different stakes than one running a small shared drive.

; How It Maps to pfSense
: '''High stakes''' → High Availability setup, IDS/IPS, VLAN segmentation, full TAC support.
: '''Lower stakes''' → Single appliance, basic firewall rules, standard support.

; Sales Note
: This pillar justifies the budget. Never skip it — without establishing stakes, you are selling on price alone and will always lose to the cheapest option.

=== Pillar 2: Devices & Users ===

''Knowing the scale determines the hardware tier.''

; Key Questions
: "How many staff members use the network daily?"
: "What devices are connected — computers, phones, tablets, IP cameras, printers, servers, POS terminals?"
: "Do you have remote workers or multiple office locations?"

; What It Tells You
: Scale of deployment, number of network interfaces needed, and whether user management features (captive portal, RADIUS) are required.

; How It Maps to pfSense
: <10 users → Entry-level appliance.
: 10–100 users → Mid-range (Netgate 4200 series).
: 100–500 users → HA pair (2× Netgate 4200 MAX, ~120k PHP one-time).
: 500+ users or ISP → Netgate 6100 series or higher.

=== Pillar 3: Bandwidth & Traffic ===

''Traffic type matters as much as raw speed.''

; Key Questions
: "What is your current internet plan speed (download/upload)?"
: "What do people do on the network — video calls, large file transfers, cloud apps, IP cameras streaming 24/7?"
: "Do you have peak hours where the network slows down noticeably?"

; What It Tells You
: WAN capacity requirements, whether QoS (Quality of Service) is needed to prioritize traffic types, and the processing load for IDS/IPS inspection.

; How It Maps to pfSense
: Heavy video/VoIP usage → QoS rules to prioritize real-time traffic.
: Heavy cloud usage → WAN load balancing for redundancy and speed.
: Many IP cameras → Dedicated VLAN and allocated bandwidth.

=== Pillar 4: Hardware Compatibility ===

''Existing infrastructure must integrate — not be replaced.''

; Key Questions
: "What servers do you have on-site — web servers, NAS, ERP, database?"
: "Do you have CCTV systems, POS terminals, VoIP phones, or other specialty devices?"
: "What network switches and access points are currently deployed?"

; What It Tells You
: VLAN design requirements, potential conflicts with existing devices, number of network interfaces needed, and whether any equipment requires a DMZ or special firewall rules.

; How It Maps to pfSense
: '''NAS or web server''' → DMZ or isolated VLAN with strict inbound rules.
: '''CCTV system''' → Isolated VLAN with no internet access (security best practice).
: '''POS terminals''' → Segmented from general office traffic (PCI-DSS compliance).
: '''VoIP phones''' → Dedicated VLAN with QoS priority to prevent call drops.

=== Pillar 5: Features & Functions Needed ===

''Match the pfSense feature set to the client's actual workflow.''

; Key Questions
: "Do staff work remotely and need secure access to office systems?"
: "Do you have a second office location that needs to connect to the main office?"
: "Do guests or contractors need network access, separate from staff?"
: "Are there compliance requirements — PCI, HIPAA, data privacy laws?"

; What It Tells You
: Which pfSense features to highlight in the proposal and configure in the deployment.

; How It Maps to pfSense
: Remote workers → VPN (OpenVPN or WireGuard).
: Multiple sites → Site-to-site VPN.
: Guest or contractor access → Captive portal with time or bandwidth limits.
: Compliance requirements → IDS/IPS, logging, VLAN segmentation, audit trails.

----

== 7. Sizing & Total Cost of Ownership (TCO) ==

=== Sizing Guidelines ===

{| class="wikitable"
|-
! Company Size / Bandwidth
! Recommended Model
! Notes
|-
| Under 1 Gbps Internet
| Netgate 6100 Series
| Fits most small-to-medium offices
|-
| Up to 500 Users
| 2× Netgate 4200 MAX (HA setup)
| ~120k PHP one-time cost for both appliances
|-
| Large Networks / ISPs (>1 Gbps)
| Netgate 6100+ or higher
| Only ISPs or large enterprises need these models
|}

=== Example: Makati Office (200 Users) ===

* '''Hardware Cost:''' 2×4200 MAX for HA → '''120,000 PHP''' (one-time)
* '''Annual Costs:'''
** License Renewal: 7,500 PHP × 2 = '''15,000 PHP/year'''
** TAC Support: '''45,000 PHP/year''' (one needed in HA)
** Snort Subscription: 24,000 PHP × 2 = '''48,000 PHP/year'''
** '''Total Annual: ~84,000 PHP/year'''

{{Note|'''Competitor Comparison:''' Fortinet equivalent: 150k PHP hardware + 200k PHP/year support → pfSense is more cost-effective.}}

----

== 8. Next Steps for Sales ==

# Work through the [[#The 5-Pillar Scoping Framework|5-Pillar Scoping Framework]] with the client before recommending any hardware.
# Select the right appliance based on scoping output (6100 vs 4200 MAX vs higher models).
# Prepare TCO comparison (pfSense vs competitor).
# Send proposal template and service brochure.

----

== Resources & References ==

* [https://www.comfac-it.com/services/netgate-pfsense-setup Setup Services]
* [https://www.comfac-it.com/blog-post/making-sense-of-unified-threat-management-utm UTM Deep Dive]
* [https://www.pfsense.org/products/ Netgate Product Info]

PfSense Training Project Tracker

2026-04-23T10:43:07Z

Justinaquino: Update Phase 1: Decision made to use dedicated training machine instead of 200-core server; add hardware selection tasks

__NOTOC__
<div style="background:#fff8e1; border:1px solid #ffcc80; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Project Tracker''' for Comfac's pfSense Practical Training System implementation. This page tracks all tasks from material conversion to infrastructure deployment and course delivery.
</div>

== Phase 0: Material Conversion (FUND001 → Wiki) ==
Convert all Netgate FUND001 training PDFs into CITWiki pages with detailed summaries. Each wiki page should include: learning objectives, key concepts, step-by-step lab instructions adapted for virtual environment, and troubleshooting tips.

=== Slide Decks ===
* [x] '''SEG1 — Introduction to pfSense''' → [[Training: pfSense Introduction]]
* [x] '''SEG2 — Interfaces, VIPs, and Rules''' → [[Training: Interfaces and Firewall Rules]]
* [x] '''SEG3 — NAT and VIPs''' → [[Training: NAT and Virtual IPs]]
* [x] '''SEG4 — pfSense Services''' → [[Training: pfSense Services]]
* [x] '''SEG5 — VPNs and IPsec''' → [[Training: IPsec VPN]]
* [x] '''SEG6 — OpenVPN''' → [[Training: OpenVPN]]
* [x] '''SEG7 — WireGuard''' → [[Training: WireGuard]]
* [x] '''SEG8 — Multi-WAN''' → [[Training: Multi-WAN]]
* [x] '''SEG9 — Traffic Shaping''' → [[Training: Traffic Shaping]]
* [x] '''SEG10 — High Availability''' → [[Training: High Availability]]
* [x] '''SEG11 — Other Features''' → [[Training: Monitoring and Packages]]

=== Labs ===
* [x] '''Lab 1 — Intro, Getting Started, Backup/Restore''' → [[Training Lab 1: Introduction and Backup Restore]]
* [x] '''Lab 2 — Interfaces, Firewall Rules, Aliases''' → [[Training Lab 2: Firewall Rules and Aliases]]
* [x] '''Lab 3 — Virtual IPs and NAT''' → [[Training Lab 3: NAT and Virtual IPs]]
* [x] '''Lab 4 — Services and Branch Network Setup''' → [[Training Lab 4: Services and Branch Network]]
* [x] '''Lab 5 — IPsec''' → [[Training Lab 5: IPsec VPN]]
* [x] '''Lab 6 — OpenVPN''' → [[Training Lab 6: OpenVPN]]
* [x] '''Lab 7 — WireGuard''' → [[Training Lab 7: WireGuard]]
* [x] '''Lab 8 — Multi-WAN''' → [[Training Lab 8: Multi-WAN]]
* [x] '''Lab 9 — Traffic Shaping''' → [[Training Lab 9: Traffic Shaping]]
* [x] '''Lab 10 — High Availability''' → [[Training Lab 10: High Availability]]

=== Comfac Original Content ===
* [x] '''Introduction Training (Module 0)''' → [[Training: Setting Up a Firewall for Yourself]] — Personal/small business firewall
* [ ] '''the-pfsense-documentation.pdf''' → Summarize into [[Training: pfSense Complete Reference]] or link as external reference
* [ ] '''WindowsTrainingSupportFiles.zip''' → Extract and document client software requirements ([[Training: Client Software Requirements]])
* [ ] '''Training Videos (4× .mkv)''' → Catalog timestamps and link from relevant wiki pages

== Phase 1: Infrastructure Setup ==
Build the virtual training environment on a '''dedicated training machine''' — NOT the 200-core / 1TB RAM production server. The 200-core machine should remain fully available for ERPNext, AI workloads, and production services.

=== Resource Analysis (Completed) ===
* [x] '''R.1''' Compare Pure Linux (FOSS) vs Windows stacks -> [[Networking PfSense Index#Resource Estimates Per Student]]
* [x] '''R.2''' Calculate 20% server utilization targets -> 13 students (Linux), 6 students (Windows)
* [x] '''R.3''' Analyze container-based alternatives -> LXC for Linux routers; KVM still required for pfSense
* [x] '''R.4''' Define exercise-limited deployment model -> Right-size per lab; 0-4 vCPUs per student
* [x] '''R.5''' Specify smaller server options for 10 students -> Dell R630 (Linux) / R740 (Windows)
* [x] '''R.6''' Design AI evaluation pipeline -> Qwen 3.5 Coder 9GB + DeepSeek + OpenCode for automated readiness
* [x] '''R.7''' Decide against using 200-core server -> Training will run on dedicated used server or repurposed desktop

=== Hardware Selection ===
* [ ] '''H.1''' Audit retiring desktops from Win2Lin migration for reuse as training server
* [ ] '''H.2''' If no suitable desktop: procure used Dell R630/R640 (32c/64GB) or HP DL360 Gen9
* [ ] '''H.3''' If rack space/noise is issue: procure 3x Intel N100 mini-PCs for silent cluster
* [ ] '''H.4''' Install Intel i350-T4 quad-port NIC if machine only has 1 Ethernet port
* [ ] '''H.5''' Label machine as CIT-TRAINING-01; document in asset inventory

=== Host Preparation ===
* [ ] '''A.1''' Install Ubuntu Server LTS 22.04/24.04 on training hardware
* [ ] '''A.2''' Configure KVM/libvirt with storage pools (NVMe for golden images, SSD for ephemeral clones)
* [ ] '''A.3''' Set up network bridges: br-mgmt, br-lan, br-wan, br-dmz, br-internet
* [ ] '''A.4''' Configure VLANs for student isolation (one VLAN per student or per lab)
* [ ] '''A.5''' Install and configure Ansible controller (host or Docker container)
* [ ] '''A.6''' Verify training machine has no dependency on 200-core server (standalone)

=== Base Images ===
* [ ] '''B.1''' Download pfSense CE ISO and create qcow2 golden image (1 vCPU, 512 MB RAM, 4 GB disk - microVM)
* [ ] '''B.2''' Create Alpine Linux LXC golden image (0.5 vCPU, 256 MB RAM, 1 GB disk)
* [ ] '''B.3''' Create Debian XFCE LXC golden image for NoVNC client (0.5 vCPU, 256 MB RAM, 2 GB disk)
* [ ] '''B.4''' Create Ubuntu Server LXC golden image (0.5 vCPU, 256 MB RAM, 1 GB disk)
* [ ] '''B.5''' Create "Internet Router" LXC golden image (0.5 vCPU, 128 MB RAM, 0.5 GB disk)
* [ ] '''B.6''' Test each golden image boots and functions correctly

=== Automation ===
* [ ] '''C.1''' Write Ansible playbook: lab1-student-env.yml (1 pfSense microVM + 1 LXC client)
* [ ] '''C.2''' Write Ansible playbook: lab2-student-env.yml (1 pfSense + 1 client + 1 server LXC)
* [ ] '''C.3''' Write Ansible playbook: lab3-student-env.yml (1 pfSense + 1 server + internet router LXC)
* [ ] '''C.4''' Write Ansible playbook: lab4-student-env.yml (2 pfSense + 2 clients + 1 server)
* [ ] '''C.5''' Write Ansible playbooks for Labs 5-10 (VPNs, Multi-WAN, Shaping, HA)
* [ ] '''C.6''' Write Ansible playbook: cleanup-student-env.yml (destroy VMs/LXCs, free resources)
* [ ] '''C.7''' Write Ansible playbook: reset-student-env.yml (revert to snapshot/linked clone base)
* [ ] '''C.8''' Test all playbooks end-to-end with a single student ID

=== NoVNC Portal ===
* [ ] '''D.1''' Evaluate Kimchi vs Apache Guacamole vs custom NoVNC proxy
* [ ] '''D.2''' Install and configure chosen NoVNC solution
* [ ] '''D.3''' Integrate NoVNC with student authentication (LDAP, local wiki accounts, or simple token-based)
* [ ] '''D.4''' Build student dashboard: list of phases/labs, "Launch Lab" button, countdown timer
* [ ] '''D.5''' Test 5 concurrent NoVNC sessions for stability
* [ ] '''D.6''' Test 20 concurrent NoVNC sessions for performance

=== AI Evaluation Pipeline ===
* [ ] '''E.1''' Deploy Qwen 3.5 Instruct Coder 9GB on GPU box or 200-core host
* [ ] '''E.2''' Build pytest + Selenium test suite for pfSense GUI validation
* [ ] '''E.3''' Build SSH-based health check suite for VM/LXC connectivity
* [ ] '''E.4''' Integrate DeepSeek or OpenCode for playbook syntax validation
* [ ] '''E.5''' Create readiness dashboard (pass/fail per lab, resource usage graphs)
* [ ] '''E.6''' Schedule automated nightly tests of all lab environments

== Phase 2: Curriculum Development ==
Design the student-facing training program.

=== Introduction Course (Most Common Use Case) ===
* [x] '''E.1''' Define "Setting Up a Firewall for Yourself" scope: home office / small business
* [x] '''E.2''' Write Module 0: Why You Need a Firewall (threats, NAT basics, basic topology)
* [x] '''E.3''' Write Module 1: Install pfSense on Old PC or VM (hardware requirements, USB install, first boot wizard)
* [x] '''E.4''' Write Module 2: Basic WAN + LAN Setup (DHCP, DNS, first internet connection)
* [x] '''E.5''' Write Module 3: Essential Firewall Rules (block incoming, allow outgoing, ICMP)
* [x] '''E.6''' Write Module 4: Port Forwarding for Common Services (game server, camera, NAS)
* [x] '''E.7''' Write Module 5: VPN for Remote Access (WireGuard road warrior setup)
* [x] '''E.8''' Write Module 6: Backup and Updates (config.xml backup, update schedule)
* [x] '''E.9''' Create hands-on lab for Introduction Course (single pfSense + 1 client VM)
* [ ] '''E.10''' Record or source video walkthroughs for each module

=== Full FUND001 Adaptation ===
* [x] '''F.1''' Map each SEG slide deck to a wiki training page with summary + key takeaways
* [x] '''F.2''' Adapt Netgate labs from physical/virtualbox environment to KVM/Ansible environment
* [ ] '''F.3''' Update IP addressing schema for Comfac virtual lab (avoid conflicts with production)
* [ ] '''F.4''' Write pre-lab briefing pages (what you'll learn, expected outcomes)
* [ ] '''F.5''' Write post-lab review pages (common mistakes, verification steps, "show me" checklist)
* [ ] '''F.6''' Create quiz questions for each phase (5–10 questions, auto-graded if possible)

== Phase 3: Pilot & Refinement ==
Run the training with a small group before full rollout.

=== Internal Pilot ===
* [ ] '''G.1''' Recruit 3–5 internal Comfac IT staff as pilot students
* [ ] '''G.2''' Run Phase 1 (Foundations) with pilot group — collect feedback
* [ ] '''G.3''' Run Phase 2 (NAT & Services) with pilot group — collect feedback
* [ ] '''G.4''' Run one VPN lab (IPsec or OpenVPN) with pilot group — test resource limits
* [ ] '''G.5''' Document all bugs, confusion points, and timeouts
* [ ] '''G.6''' Refine playbooks and wiki pages based on pilot feedback

=== Resource Tuning ===
* [ ] '''H.1''' Measure actual CPU/RAM/disk usage per student during pilot
* [ ] '''H.2''' Adjust VM specs if over- or under-provisioned
* [ ] '''H.3''' Test memory overcommit ratios for safe concurrency scaling
* [ ] '''H.4''' Document maximum safe concurrent student count

== Phase 4: Deployment & Operations ==
Prepare for regular training delivery.

=== Student Onboarding ===
* [ ] '''I.1''' Create student onboarding guide (how to access portal, use NoVNC, reset lab)
* [ ] '''I.2''' Create instructor guide (how to monitor progress, assist students, grade labs)
* [ ] '''I.3''' Set up scheduling system (book lab time slots, prevent over-allocation)
* [ ] '''I.4''' Create completion certificates or badges

=== Monitoring & Maintenance ===
* [ ] '''J.1''' Set up host monitoring (Prometheus/Grafana or simple `libvirt` stats)
* [ ] '''J.2''' Configure alerts for host resource exhaustion
* [ ] '''J.3''' Schedule weekly base image updates (pfSense patches, OS updates)
* [ ] '''J.4''' Document disaster recovery (rebuild host from Ansible, restore golden images)

== Quick Status Dashboard ==
{| class="wikitable"
! Phase !! Status !! % Complete !! Blockers
|-
| Phase 0: Material Conversion || 🟢 Done (22/23) || 96% || Pending: reference PDF, support files, videos
|-
| Phase 1: Infrastructure Setup || 🟡 In Progress || 20% || Hardware decision made; acquire dedicated training machine
|-
| Phase 2: Curriculum Development || 🟡 In Progress || 65% || Need video recordings, quizzes, pre/post lab pages
|-
| Phase 3: Pilot & Refinement || 🔴 Not Started || 0% || Waiting on Phase 1 + 2
|-
| Phase 4: Deployment & Operations || 🔴 Not Started || 0% || Waiting on Phase 3
|}

== Resource Summary ==
'''Per-student minimum:''' 6 vCPUs, 6.5 GB RAM, 62 GB disk
'''Per-student full lab:''' 10 vCPUs, 10.5 GB RAM, 110 GB disk
'''200-core / 1TB capacity:''' 20–40 concurrent students (conservative to optimized)

'''Next Actions (This Week):'''
# Summarize the-pfsense-documentation.pdf into a reference page
# Document WindowsTrainingSupportFiles.zip contents
# Catalog training video timestamps
# Begin Ansible playbook drafting for Lab 1 environment
# Evaluate Kimchi vs Guacamole for NoVNC portal

Networking PfSense Index

2026-04-23T10:42:09Z

Justinaquino: Add Dedicated Training Server Strategy: recommend separate machine instead of 200-core server; include mini-PC cluster, used server, desktop repurpose, ARM SBC options; cost-benefit analysis

__NOTOC__
<div style="background:#f0f7ff; border:1px solid #b8d4f0; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Consolidated index''' for all networking infrastructure guides, pfSense documentation, DNS/ad-blocking resources, and network equipment references at Comfac IT.
</div>

== pfSense Core Guides ==
* [[pfSense Sales Training Material]] — Product knowledge and sales positioning for Netgate/pfSense hardware and software
* [[Modern Guide: pfSense Captive Portal with FreeRADIUS & ACME]] — Enterprise Wi-Fi captive portal with RADIUS authentication and Let's Encrypt SSL
* [[pfSense CE → pfSense Plus Upgrade Guide]] — Step-by-step migration from Community Edition to pfSense Plus
* [[SOP: Network Troubleshooting & pfSense Monitoring 251130]] — Standard operating procedures for network diagnostics and pfSense health monitoring

== Network Infrastructure & Equipment ==
* [[Tplink Mikrotik Equivalent]] — Cross-reference of TP-Link and MikroTik models for network deployments
* [[Controller Systems 251213-01]] — Network and infrastructure controller systems
* [[Power Distribution Tree 251213]] — Power architecture for network and server racks
* [[NPM Migration to Homelab VPS Relay 260401]] — Nginx Proxy Manager migration; VPS as iptables/ZeroTier relay with homelab redundancy

== DNS, Ad Blocking & Pi-hole ==
* [https://github.com/Comfac-Global-Group/pi-hole Comfac Pi-hole Repository] — GitHub repository for Pi-hole DNS sinkhole deployment
* [https://github.com/Comfac-Global-Group/pi-hole/blob/master/How%20this%20Works.md How Pi-hole Works] — Technical overview of the Pi-hole DNS filtering architecture

== Training & Skills ==
* [[Skills and Competencies for IT Staff Trained in pfSense]] — Required competencies and certification path for pfSense-administering staff
* [[PfSense Training Project Tracker]] — '''Implementation tracker''' for the NoVNC virtual lab, material conversion, and curriculum development

== Practical Training System (NoVNC Virtual Lab) ==
'''Goal:''' Build a self-hosted, virtualized pfSense training environment where Comfac trainees can learn hands-on without physical hardware. All labs run via NoVNC in a browser, orchestrated on Comfac's 200-core / 1TB RAM machine.

=== Training Architecture Vision ===
Each student gets an isolated virtual network sandbox containing:
* 2× pfSense VMs (HQ HA pair or HQ + Branch)
* 1–2× Client VMs (Windows/Linux desktop)
* 1× Server VM (web/DNS/target)
* 1× Simulated "Internet" router VM

Access is through a NoVNC web portal. Students click a lab, and their environment is provisioned automatically via Ansible/Terraform or Docker/KVM.

=== Resource Estimates Per Student ===

==== Stack A: Pure Linux / FOSS (Recommended for Comfac) ====
All components run on open-source software. Clients are lightweight Linux VMs or LXC containers. No Windows licensing required.

{| class="wikitable"
! Component !! vCPUs !! RAM !! Disk !! Virtualization !! Notes
|-
| pfSense VM || 1 || 512 MB || 4 GB || KVM microVM || FreeBSD requires KVM; use tiny QEMU args
|-
| Linux Client (LXC) || 0.5 || 256 MB || 1 GB || LXC container || Alpine or Debian with XFCE; NoVNC access
|-
| Linux Server (LXC) || 0.5 || 256 MB || 1 GB || LXC container || nginx, BIND, or simple Python HTTP
|-
| Internet Router (LXC) || 0.5 || 128 MB || 0.5 GB || LXC container || Static routes only; FRR optional
|-
| NoVNC Proxy (Docker) || 0.5 || 256 MB || 0.5 GB || Docker container || websockify + nginx
|-
| '''Total per student''' || '''3''' || '''1.4 GB''' || '''7 GB''' || — || Thin-provisioned; linked clones
|}

==== Stack B: Windows Client (Full Desktop Experience) ====
For trainees who need a Windows desktop for browser-based management or specific client software.

{| class="wikitable"
! Component !! vCPUs !! RAM !! Disk !! Virtualization !! Notes
|-
| pfSense VM || 2 || 1 GB || 8 GB || KVM || Standard qcow2 image
|-
| Windows Client || 2 || 4 GB || 40 GB || KVM || Windows 10/11 thin client; needs GPU if GUI-heavy
|-
| Ubuntu Server || 1 || 1 GB || 10 GB || KVM || Full VM for compatibility
|-
| Internet Router || 1 || 512 MB || 4 GB || KVM || Ubuntu with static routes
|-
| NoVNC Proxy || 0.5 || 256 MB || 0.5 GB || Docker || Shared across students
|-
| '''Total per student''' || '''6.5''' || '''6.8 GB''' || '''63 GB''' || — || Higher resource cost
|}

==== Stack C: Hybrid — Containers for Linux Router Exercises ====
For basic routing/firewall concept labs only (not pfSense-specific), replace pfSense with Linux routers in containers.

{| class="wikitable"
! Component !! vCPUs !! RAM !! Disk !! Virtualization !! Notes
|-
| Linux Router (LXC) || 0.5 || 128 MB || 0.5 GB || LXC || Alpine + iptables/nftables + WireGuard
|-
| Linux Client (LXC) || 0.5 || 256 MB || 1 GB || LXC || Alpine or Debian
|-
| Linux Server (LXC) || 0.5 || 256 MB || 1 GB || LXC || nginx, BIND
|-
| Internet Router (LXC) || 0.5 || 128 MB || 0.5 GB || LXC || Static routes
|-
| '''Total per student''' || '''2''' || '''768 MB''' || '''3 GB''' || — || Cannot teach pfSense GUI; teaches concepts only
|}

'''Important:''' pfSense is FreeBSD-based and cannot run in Linux containers (Docker/LXC). Stack C is suitable for teaching routing/VPN concepts using Linux tools (iptables, nftables, WireGuard, strongSwan), but not for teaching the pfSense web interface. For pfSense GUI training, use Stack A or B.

=== Server Capacity: 20% Utilization Target ===
The goal is to run the training environment using only 20% of the 200-core / 1TB RAM server, leaving 80% for other Comfac workloads (ERPNext, AI models, file services).

'''20% of available resources:'''
* 40 vCPUs (20% of 200)
* 200 GB RAM (20% of 1 TB)
* ~2 TB SSD (assuming 10 TB array, 20% = 2 TB)

'''Concurrent student capacity at 20% utilization:'''

{| class="wikitable"
! Stack !! Per-Student Resources !! Students at 20% CPU !! Students at 20% RAM !! Limiting Factor
|-
| '''A: Pure Linux''' || 3 vCPU / 1.4 GB || 13 || 142 || '''CPU: 13 students'''
|-
| '''B: Windows''' || 6.5 vCPU / 6.8 GB || 6 || 29 || '''CPU: 6 students'''
|-
| '''C: Containers''' || 2 vCPU / 0.8 GB || 20 || 250 || '''CPU: 20 students'''
|}

'''Recommendation:''' Use Stack A (Pure Linux) for all labs. This yields ~13 concurrent students within the 20% budget, or up to ~30 students if spread across time slots (not everyone needs a lab simultaneously).

=== Smaller Server: What Hardware for 10 Students? ===
If buying a dedicated training server instead of using the 200-core machine:

{| class="wikitable"
! Stack !! CPU !! RAM !! Storage !! NICs !! Example Hardware
|-
| '''A: Pure Linux''' || 32 cores || 32 GB || 500 GB NVMe || 2x 1GbE || Used Dell R630/R640 (~$300-500)
|-
| '''B: Windows''' || 64 cores || 96 GB || 1 TB NVMe || 2x 1GbE || Used Dell R740 / HP DL360 (~$600-900)
|-
| '''C: Containers''' || 16 cores || 16 GB || 250 GB NVMe || 2x 1GbE || Old desktop + Intel NIC (~$100-200)
|}

=== Dedicated Training Server Strategy (Recommended) ===
The 200-core / 1TB RAM machine is Comfac's primary production server (ERPNext, AI models, file services, build pipelines). Running training labs on it consumes resources that could be used for revenue-generating workloads.

'''Recommendation: Do NOT run training on the 200-core server.''' Instead, deploy training on a dedicated, smaller machine.

{| class="wikitable"
! Option !! Hardware !! Cost (Used) !! Capacity (Stack A) !! Power !! Notes
|-
| '''A. Mini-PC Cluster''' || 3× Intel N100/N305 mini-PCs (4c/8t, 16GB RAM, 512GB SSD each) || ~$450 total || 12 students || ~45W total || Silent, no rack needed. One PC fails = 4 students affected.
|-
| '''B. Single Used Server''' || Dell R630 / HP DL360 Gen9 (2× E5-2680v4, 64GB RAM, 1TB NVMe) || ~$400-600 || 15-20 students || ~150W || Rackmount, redundant PSU, IPMI.
|-
| '''C. Desktop Repurpose''' || Old Comfac desktop (i5-8400, 32GB RAM, 500GB SSD) + Intel i350-T4 NIC || $0 + $50 NIC || 6-8 students || ~65W || Free if you have spare desktops.
|-
| '''D. ARM SBC Cluster''' || 4× Raspberry Pi 5 (4GB) + 1× Pi 5 (8GB as controller) || ~$300 total || 4-6 students || ~25W total || Cannot run x86 pfSense; must use Linux routers (Stack C only).
|}

'''Best choice for Comfac: Option B (Single Used Server) or Option C (Repurpose Desktop).'''
* Option B gives headroom for growth to 20 students
* Option C is free if you have retiring desktops from the Win2Lin migration
* Both keep the 200-core server 100% free for production

=== Cost-Benefit: 200-Core Server vs Dedicated Training Box ===
{| class="wikitable"
! Factor !! Training on 200-Core Server !! Dedicated Training Server
|-
| '''Hardware Cost''' || $0 (already owned) || $0-$600
|-
| '''Power Cost''' || Already running || +$10-30/month
|-
| '''Opportunity Cost''' || '''High''' — 20% of server unavailable for ERPNext/AI/builds || '''Zero''' — production server untouched
|-
| '''Risk''' || Training crashes could affect production VMs || Isolated; training issues contained
|-
| '''Noise/Location''' || Must stay in server room || Mini-PC or desktop can sit in training room
|-
| '''Maintenance Window''' || Must coordinate with production || Anytime; reboot freely
|}

'''Verdict:''' A $400 used server or a $0 repurposed desktop pays for itself in 1-2 months by keeping the 200-core machine fully available for production workloads.

=== Cluster-in-a-Box: Old PC + Proxmox VE ===
For the absolute lowest cost (repurposed old PC):
# Install Proxmox VE (Debian-based hypervisor with web GUI)
# Create LXC templates for Alpine/Debian clients
# Create KVM VMs for pfSense microVMs
# Install NoVNC via Proxmox built-in console or add Kimchi/Guacamole
# Students access via browser to the Proxmox web UI

'''Specs needed for 8 students (Stack A):'''
* CPU: 6-core / 12-thread (Intel 6th-gen i5 or better; AMD Ryzen 5)
* RAM: 32 GB DDR4
* Storage: 500 GB NVMe or SSD
* NIC: Intel i350-T4 quad-port (for VLANs and bridges)
* Cost: $0 (old PC) + $50 (NIC) if you already have the PC

This is the path of least resistance for Comfac given the Win2Lin migration will free up desktops.

=== Exercise-Limited Deployment (Right-Sizing per Lab) ===
Not every lab needs the full sandbox. Deploy only what is needed:

{| class="wikitable"
! Lab !! Stack A Deployed !! vCPUs Used !! RAM Used !! Disk Used
|-
| Day 1 — Theory only || None (wiki only) || 0 || 0 || 0
|-
| Lab 1 (Intro/Backup) || 1 pfSense + 1 client || 1.5 || 768 MB || 5 GB
|-
| Lab 2 (Rules) || 1 pfSense + 1 client + 1 server || 2 || 1 GB || 6 GB
|-
| Lab 3 (NAT) || 1 pfSense + 1 server + router || 2 || 900 MB || 5.5 GB
|-
| Lab 4 (Services) || 2 pfSense + 2 clients + 1 server || 4 || 2.1 GB || 11 GB
|-
| Lab 5-7 (VPNs) || 2 pfSense + 2 clients || 3 || 1.5 GB || 10 GB
|-
| Lab 8 (Multi-WAN) || 1 pfSense + 1 client + router || 2 || 900 MB || 5.5 GB
|-
| Lab 9 (Shaping) || 1 pfSense + 2 clients || 2.5 || 1.3 GB || 6 GB
|-
| Lab 10 (HA) || 2 pfSense + 1 client || 2.5 || 1.3 GB || 9 GB
|}

'''Scheduling strategy:''' If students are scheduled in 1-hour slots and labs are provisioned on-demand, the same 40 vCPUs / 200 GB RAM can serve 40-60 student-slots per day (not concurrently, but sequentially).

=== Phase 1: Resource Setup Validation ===
Before full student rollout, validate the resource model with these tests:

{| class="wikitable"
! Test !! Purpose !! Command / Method !! Pass Criteria
|-
| '''T1: MicroVM Boot''' || Verify pfSense runs in 512MB/1vCPU || qemu-system-x86_64 -m 512 -smp 1 -drive file=pfsense.qcow2 || Boots to login in < 120s
|-
| '''T2: LXC Container Spawn''' || Verify sub-1GB containers work || lxc launch images:alpine/3.19 client || Starts in < 10s; SSH reachable
|-
| '''T3: NoVNC Session''' || Verify one student can access console || websockify + TigerVNC || 640x480 responsive; < 500ms latency
|-
| '''T4: 5 Concurrent Students''' || Validate 20% CPU/RAM budget || Ansible: deploy 5x Stack A || Total < 8 vCPU, < 7 GB RAM
|-
| '''T5: Lab 4 Full Deploy''' || Heaviest lab (2 pfSense + 2 clients + server) || ansible-playbook lab4.yml || Deploys in < 5 min; all VMs pingable
|-
| '''T6: Snapshot Reset Speed''' || Time to reset between students || virsh snapshot-revert + virsh start || < 60 seconds total
|-
| '''T7: AI Evaluation Readiness''' || Validate environment for automated testing || See AI Evaluation section below || All labs pass synthetic health checks
|}

=== AI Evaluation: Automated Readiness Testing ===
Before students arrive, AI agents will validate that each lab environment is functional. This replaces manual smoke-testing.

'''Evaluation Stack:'''
* '''Qwen 3.5 Instruct Coder (9GB)''' — Runs locally on the 200-core server or a dedicated GPU box. Evaluates: pfSense GUI accessibility, rule syntax, VPN handshake status, config.xml validity.
* '''DeepSeek Coder (optional)''' — Cloud or local. Validates Ansible playbook correctness, network topology logic, resource allocation math.
* '''OpenCode (local agent)''' — Executes shell commands inside VMs/containers via SSH/API. Performs end-to-end tests: ping, curl, ipsec status, wg show, etc.

'''Automated Test Sequence (per lab):'''
# Deploy lab environment via Ansible
# AI agent logs into pfSense (admin credentials)
# Screenshot/check each configured page matches expected state
# Run connectivity tests from client VMs
# Verify services are listening on correct ports
# Generate pass/fail report with specific error details
# Destroy lab environment

'''Benefits:'''
* Catch broken base images before students arrive
* Validate that config.xml injections work correctly
* Ensure network isolation between students
* Measure actual resource usage vs. estimates
* Generate readiness dashboard for instructors

'''Implementation:'''
* Python + Selenium/Playwright for pfSense GUI testing
* Paramiko/fabric for SSH-based VM tests
* pytest framework for test organization
* GitHub Actions or local Cron for scheduled runs
* Output: Markdown report posted to wiki or sent via Matrix/Email

== Related Infrastructure ==
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]] — Server migration and infrastructure hardening
* [[Introduction: Why Self-Host Your Email?]] — Self-hosted email infrastructure context
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]] — Email server deployment
* [[Portainer to Docker Compose Migration Guide]] — Container orchestration for network services

----
''This index consolidates networking resources previously scattered across the [[Main Page]]. Last updated: 260423.''

PfSense Training Project Tracker

2026-04-23T10:14:45Z

Justinaquino: Update Phase 1: Resource analysis completed (R.1-R.6), add AI evaluation pipeline tasks, update status dashboard

__NOTOC__
<div style="background:#fff8e1; border:1px solid #ffcc80; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Project Tracker''' for Comfac's pfSense Practical Training System implementation. This page tracks all tasks from material conversion to infrastructure deployment and course delivery.
</div>

== Phase 0: Material Conversion (FUND001 → Wiki) ==
Convert all Netgate FUND001 training PDFs into CITWiki pages with detailed summaries. Each wiki page should include: learning objectives, key concepts, step-by-step lab instructions adapted for virtual environment, and troubleshooting tips.

=== Slide Decks ===
* [x] '''SEG1 — Introduction to pfSense''' → [[Training: pfSense Introduction]]
* [x] '''SEG2 — Interfaces, VIPs, and Rules''' → [[Training: Interfaces and Firewall Rules]]
* [x] '''SEG3 — NAT and VIPs''' → [[Training: NAT and Virtual IPs]]
* [x] '''SEG4 — pfSense Services''' → [[Training: pfSense Services]]
* [x] '''SEG5 — VPNs and IPsec''' → [[Training: IPsec VPN]]
* [x] '''SEG6 — OpenVPN''' → [[Training: OpenVPN]]
* [x] '''SEG7 — WireGuard''' → [[Training: WireGuard]]
* [x] '''SEG8 — Multi-WAN''' → [[Training: Multi-WAN]]
* [x] '''SEG9 — Traffic Shaping''' → [[Training: Traffic Shaping]]
* [x] '''SEG10 — High Availability''' → [[Training: High Availability]]
* [x] '''SEG11 — Other Features''' → [[Training: Monitoring and Packages]]

=== Labs ===
* [x] '''Lab 1 — Intro, Getting Started, Backup/Restore''' → [[Training Lab 1: Introduction and Backup Restore]]
* [x] '''Lab 2 — Interfaces, Firewall Rules, Aliases''' → [[Training Lab 2: Firewall Rules and Aliases]]
* [x] '''Lab 3 — Virtual IPs and NAT''' → [[Training Lab 3: NAT and Virtual IPs]]
* [x] '''Lab 4 — Services and Branch Network Setup''' → [[Training Lab 4: Services and Branch Network]]
* [x] '''Lab 5 — IPsec''' → [[Training Lab 5: IPsec VPN]]
* [x] '''Lab 6 — OpenVPN''' → [[Training Lab 6: OpenVPN]]
* [x] '''Lab 7 — WireGuard''' → [[Training Lab 7: WireGuard]]
* [x] '''Lab 8 — Multi-WAN''' → [[Training Lab 8: Multi-WAN]]
* [x] '''Lab 9 — Traffic Shaping''' → [[Training Lab 9: Traffic Shaping]]
* [x] '''Lab 10 — High Availability''' → [[Training Lab 10: High Availability]]

=== Comfac Original Content ===
* [x] '''Introduction Training (Module 0)''' → [[Training: Setting Up a Firewall for Yourself]] — Personal/small business firewall
* [ ] '''the-pfsense-documentation.pdf''' → Summarize into [[Training: pfSense Complete Reference]] or link as external reference
* [ ] '''WindowsTrainingSupportFiles.zip''' → Extract and document client software requirements ([[Training: Client Software Requirements]])
* [ ] '''Training Videos (4× .mkv)''' → Catalog timestamps and link from relevant wiki pages

== Phase 1: Infrastructure Setup ==
Build the virtual training environment on Comfac's 200-core / 1TB RAM machine.

=== Resource Analysis (Completed) ===
* [x] '''R.1''' Compare Pure Linux (FOSS) vs Windows stacks -> [[Networking PfSense Index#Resource Estimates Per Student]]
* [x] '''R.2''' Calculate 20% server utilization targets -> 13 students (Linux), 6 students (Windows)
* [x] '''R.3''' Analyze container-based alternatives -> LXC for Linux routers; KVM still required for pfSense
* [x] '''R.4''' Define exercise-limited deployment model -> Right-size per lab; 0-4 vCPUs per student
* [x] '''R.5''' Specify smaller server options for 10 students -> Dell R630 (Linux) / R740 (Windows)
* [x] '''R.6''' Design AI evaluation pipeline -> Qwen 3.5 Coder 9GB + DeepSeek + OpenCode for automated readiness

=== Host Preparation ===
* [ ] '''A.1''' Install Ubuntu Server LTS on 200-core host
* [ ] '''A.2''' Configure KVM/libvirt with storage pools (NVMe for images, SSD for ephemeral clones)
* [ ] '''A.3''' Set up network bridges: br-mgmt, br-lan, br-wan, br-dmz, br-internet
* [ ] '''A.4''' Configure VLANs for student isolation (one VLAN per student or per lab)
* [ ] '''A.5''' Install and configure Ansible controller (host or container)

=== Base Images ===
* [ ] '''B.1''' Download pfSense CE ISO and create qcow2 golden image (1 vCPU, 512 MB RAM, 4 GB disk - microVM)
* [ ] '''B.2''' Create Alpine Linux LXC golden image (0.5 vCPU, 256 MB RAM, 1 GB disk)
* [ ] '''B.3''' Create Debian XFCE LXC golden image for NoVNC client (0.5 vCPU, 256 MB RAM, 2 GB disk)
* [ ] '''B.4''' Create Ubuntu Server LXC golden image (0.5 vCPU, 256 MB RAM, 1 GB disk)
* [ ] '''B.5''' Create "Internet Router" LXC golden image (0.5 vCPU, 128 MB RAM, 0.5 GB disk)
* [ ] '''B.6''' Test each golden image boots and functions correctly

=== Automation ===
* [ ] '''C.1''' Write Ansible playbook: lab1-student-env.yml (1 pfSense microVM + 1 LXC client)
* [ ] '''C.2''' Write Ansible playbook: lab2-student-env.yml (1 pfSense + 1 client + 1 server LXC)
* [ ] '''C.3''' Write Ansible playbook: lab3-student-env.yml (1 pfSense + 1 server + internet router LXC)
* [ ] '''C.4''' Write Ansible playbook: lab4-student-env.yml (2 pfSense + 2 clients + 1 server)
* [ ] '''C.5''' Write Ansible playbooks for Labs 5-10 (VPNs, Multi-WAN, Shaping, HA)
* [ ] '''C.6''' Write Ansible playbook: cleanup-student-env.yml (destroy VMs/LXCs, free resources)
* [ ] '''C.7''' Write Ansible playbook: reset-student-env.yml (revert to snapshot/linked clone base)
* [ ] '''C.8''' Test all playbooks end-to-end with a single student ID

=== NoVNC Portal ===
* [ ] '''D.1''' Evaluate Kimchi vs Apache Guacamole vs custom NoVNC proxy
* [ ] '''D.2''' Install and configure chosen NoVNC solution
* [ ] '''D.3''' Integrate NoVNC with student authentication (LDAP, local wiki accounts, or simple token-based)
* [ ] '''D.4''' Build student dashboard: list of phases/labs, "Launch Lab" button, countdown timer
* [ ] '''D.5''' Test 5 concurrent NoVNC sessions for stability
* [ ] '''D.6''' Test 20 concurrent NoVNC sessions for performance

=== AI Evaluation Pipeline ===
* [ ] '''E.1''' Deploy Qwen 3.5 Instruct Coder 9GB on GPU box or 200-core host
* [ ] '''E.2''' Build pytest + Selenium test suite for pfSense GUI validation
* [ ] '''E.3''' Build SSH-based health check suite for VM/LXC connectivity
* [ ] '''E.4''' Integrate DeepSeek or OpenCode for playbook syntax validation
* [ ] '''E.5''' Create readiness dashboard (pass/fail per lab, resource usage graphs)
* [ ] '''E.6''' Schedule automated nightly tests of all lab environments

== Phase 2: Curriculum Development ==
Design the student-facing training program.

=== Introduction Course (Most Common Use Case) ===
* [x] '''E.1''' Define "Setting Up a Firewall for Yourself" scope: home office / small business
* [x] '''E.2''' Write Module 0: Why You Need a Firewall (threats, NAT basics, basic topology)
* [x] '''E.3''' Write Module 1: Install pfSense on Old PC or VM (hardware requirements, USB install, first boot wizard)
* [x] '''E.4''' Write Module 2: Basic WAN + LAN Setup (DHCP, DNS, first internet connection)
* [x] '''E.5''' Write Module 3: Essential Firewall Rules (block incoming, allow outgoing, ICMP)
* [x] '''E.6''' Write Module 4: Port Forwarding for Common Services (game server, camera, NAS)
* [x] '''E.7''' Write Module 5: VPN for Remote Access (WireGuard road warrior setup)
* [x] '''E.8''' Write Module 6: Backup and Updates (config.xml backup, update schedule)
* [x] '''E.9''' Create hands-on lab for Introduction Course (single pfSense + 1 client VM)
* [ ] '''E.10''' Record or source video walkthroughs for each module

=== Full FUND001 Adaptation ===
* [x] '''F.1''' Map each SEG slide deck to a wiki training page with summary + key takeaways
* [x] '''F.2''' Adapt Netgate labs from physical/virtualbox environment to KVM/Ansible environment
* [ ] '''F.3''' Update IP addressing schema for Comfac virtual lab (avoid conflicts with production)
* [ ] '''F.4''' Write pre-lab briefing pages (what you'll learn, expected outcomes)
* [ ] '''F.5''' Write post-lab review pages (common mistakes, verification steps, "show me" checklist)
* [ ] '''F.6''' Create quiz questions for each phase (5–10 questions, auto-graded if possible)

== Phase 3: Pilot & Refinement ==
Run the training with a small group before full rollout.

=== Internal Pilot ===
* [ ] '''G.1''' Recruit 3–5 internal Comfac IT staff as pilot students
* [ ] '''G.2''' Run Phase 1 (Foundations) with pilot group — collect feedback
* [ ] '''G.3''' Run Phase 2 (NAT & Services) with pilot group — collect feedback
* [ ] '''G.4''' Run one VPN lab (IPsec or OpenVPN) with pilot group — test resource limits
* [ ] '''G.5''' Document all bugs, confusion points, and timeouts
* [ ] '''G.6''' Refine playbooks and wiki pages based on pilot feedback

=== Resource Tuning ===
* [ ] '''H.1''' Measure actual CPU/RAM/disk usage per student during pilot
* [ ] '''H.2''' Adjust VM specs if over- or under-provisioned
* [ ] '''H.3''' Test memory overcommit ratios for safe concurrency scaling
* [ ] '''H.4''' Document maximum safe concurrent student count

== Phase 4: Deployment & Operations ==
Prepare for regular training delivery.

=== Student Onboarding ===
* [ ] '''I.1''' Create student onboarding guide (how to access portal, use NoVNC, reset lab)
* [ ] '''I.2''' Create instructor guide (how to monitor progress, assist students, grade labs)
* [ ] '''I.3''' Set up scheduling system (book lab time slots, prevent over-allocation)
* [ ] '''I.4''' Create completion certificates or badges

=== Monitoring & Maintenance ===
* [ ] '''J.1''' Set up host monitoring (Prometheus/Grafana or simple `libvirt` stats)
* [ ] '''J.2''' Configure alerts for host resource exhaustion
* [ ] '''J.3''' Schedule weekly base image updates (pfSense patches, OS updates)
* [ ] '''J.4''' Document disaster recovery (rebuild host from Ansible, restore golden images)

== Quick Status Dashboard ==
{| class="wikitable"
! Phase !! Status !! % Complete !! Blockers
|-
| Phase 0: Material Conversion || 🟢 Done (22/23) || 96% || Pending: reference PDF, support files, videos
|-
| Phase 1: Infrastructure Setup || 🟡 In Progress || 15% || Resource analysis complete; need host access for image builds
|-
| Phase 2: Curriculum Development || 🟡 In Progress || 65% || Need video recordings, quizzes, pre/post lab pages
|-
| Phase 3: Pilot & Refinement || 🔴 Not Started || 0% || Waiting on Phase 1 + 2
|-
| Phase 4: Deployment & Operations || 🔴 Not Started || 0% || Waiting on Phase 3
|}

== Resource Summary ==
'''Per-student minimum:''' 6 vCPUs, 6.5 GB RAM, 62 GB disk
'''Per-student full lab:''' 10 vCPUs, 10.5 GB RAM, 110 GB disk
'''200-core / 1TB capacity:''' 20–40 concurrent students (conservative to optimized)

'''Next Actions (This Week):'''
# Summarize the-pfsense-documentation.pdf into a reference page
# Document WindowsTrainingSupportFiles.zip contents
# Catalog training video timestamps
# Begin Ansible playbook drafting for Lab 1 environment
# Evaluate Kimchi vs Guacamole for NoVNC portal

Networking PfSense Index

2026-04-23T10:10:50Z

Justinaquino: Update Resource Estimates: Add Linux FOSS vs Windows stacks, 20% utilization target, container analysis, AI evaluation, exercise-limited deployment

__NOTOC__
<div style="background:#f0f7ff; border:1px solid #b8d4f0; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Consolidated index''' for all networking infrastructure guides, pfSense documentation, DNS/ad-blocking resources, and network equipment references at Comfac IT.
</div>

== pfSense Core Guides ==
* [[pfSense Sales Training Material]] — Product knowledge and sales positioning for Netgate/pfSense hardware and software
* [[Modern Guide: pfSense Captive Portal with FreeRADIUS & ACME]] — Enterprise Wi-Fi captive portal with RADIUS authentication and Let's Encrypt SSL
* [[pfSense CE → pfSense Plus Upgrade Guide]] — Step-by-step migration from Community Edition to pfSense Plus
* [[SOP: Network Troubleshooting & pfSense Monitoring 251130]] — Standard operating procedures for network diagnostics and pfSense health monitoring

== Network Infrastructure & Equipment ==
* [[Tplink Mikrotik Equivalent]] — Cross-reference of TP-Link and MikroTik models for network deployments
* [[Controller Systems 251213-01]] — Network and infrastructure controller systems
* [[Power Distribution Tree 251213]] — Power architecture for network and server racks
* [[NPM Migration to Homelab VPS Relay 260401]] — Nginx Proxy Manager migration; VPS as iptables/ZeroTier relay with homelab redundancy

== DNS, Ad Blocking & Pi-hole ==
* [https://github.com/Comfac-Global-Group/pi-hole Comfac Pi-hole Repository] — GitHub repository for Pi-hole DNS sinkhole deployment
* [https://github.com/Comfac-Global-Group/pi-hole/blob/master/How%20this%20Works.md How Pi-hole Works] — Technical overview of the Pi-hole DNS filtering architecture

== Training & Skills ==
* [[Skills and Competencies for IT Staff Trained in pfSense]] — Required competencies and certification path for pfSense-administering staff
* [[PfSense Training Project Tracker]] — '''Implementation tracker''' for the NoVNC virtual lab, material conversion, and curriculum development

== Practical Training System (NoVNC Virtual Lab) ==
'''Goal:''' Build a self-hosted, virtualized pfSense training environment where Comfac trainees can learn hands-on without physical hardware. All labs run via NoVNC in a browser, orchestrated on Comfac's 200-core / 1TB RAM machine.

=== Training Architecture Vision ===
Each student gets an isolated virtual network sandbox containing:
* 2× pfSense VMs (HQ HA pair or HQ + Branch)
* 1–2× Client VMs (Windows/Linux desktop)
* 1× Server VM (web/DNS/target)
* 1× Simulated "Internet" router VM

Access is through a NoVNC web portal. Students click a lab, and their environment is provisioned automatically via Ansible/Terraform or Docker/KVM.

=== Resource Estimates Per Student ===

==== Stack A: Pure Linux / FOSS (Recommended for Comfac) ====
All components run on open-source software. Clients are lightweight Linux VMs or LXC containers. No Windows licensing required.

{| class="wikitable"
! Component !! vCPUs !! RAM !! Disk !! Virtualization !! Notes
|-
| pfSense VM || 1 || 512 MB || 4 GB || KVM microVM || FreeBSD requires KVM; use tiny QEMU args
|-
| Linux Client (LXC) || 0.5 || 256 MB || 1 GB || LXC container || Alpine or Debian with XFCE; NoVNC access
|-
| Linux Server (LXC) || 0.5 || 256 MB || 1 GB || LXC container || nginx, BIND, or simple Python HTTP
|-
| Internet Router (LXC) || 0.5 || 128 MB || 0.5 GB || LXC container || Static routes only; FRR optional
|-
| NoVNC Proxy (Docker) || 0.5 || 256 MB || 0.5 GB || Docker container || websockify + nginx
|-
| '''Total per student''' || '''3''' || '''1.4 GB''' || '''7 GB''' || — || Thin-provisioned; linked clones
|}

==== Stack B: Windows Client (Full Desktop Experience) ====
For trainees who need a Windows desktop for browser-based management or specific client software.

{| class="wikitable"
! Component !! vCPUs !! RAM !! Disk !! Virtualization !! Notes
|-
| pfSense VM || 2 || 1 GB || 8 GB || KVM || Standard qcow2 image
|-
| Windows Client || 2 || 4 GB || 40 GB || KVM || Windows 10/11 thin client; needs GPU if GUI-heavy
|-
| Ubuntu Server || 1 || 1 GB || 10 GB || KVM || Full VM for compatibility
|-
| Internet Router || 1 || 512 MB || 4 GB || KVM || Ubuntu with static routes
|-
| NoVNC Proxy || 0.5 || 256 MB || 0.5 GB || Docker || Shared across students
|-
| '''Total per student''' || '''6.5''' || '''6.8 GB''' || '''63 GB''' || — || Higher resource cost
|}

==== Stack C: Hybrid — Containers for Linux Router Exercises ====
For basic routing/firewall concept labs only (not pfSense-specific), replace pfSense with Linux routers in containers.

{| class="wikitable"
! Component !! vCPUs !! RAM !! Disk !! Virtualization !! Notes
|-
| Linux Router (LXC) || 0.5 || 128 MB || 0.5 GB || LXC || Alpine + iptables/nftables + WireGuard
|-
| Linux Client (LXC) || 0.5 || 256 MB || 1 GB || LXC || Alpine or Debian
|-
| Linux Server (LXC) || 0.5 || 256 MB || 1 GB || LXC || nginx, BIND
|-
| Internet Router (LXC) || 0.5 || 128 MB || 0.5 GB || LXC || Static routes
|-
| '''Total per student''' || '''2''' || '''768 MB''' || '''3 GB''' || — || Cannot teach pfSense GUI; teaches concepts only
|}

'''Important:''' pfSense is FreeBSD-based and cannot run in Linux containers (Docker/LXC). Stack C is suitable for teaching routing/VPN concepts using Linux tools (iptables, nftables, WireGuard, strongSwan), but not for teaching the pfSense web interface. For pfSense GUI training, use Stack A or B.

=== Server Capacity: 20% Utilization Target ===
The goal is to run the training environment using only 20% of the 200-core / 1TB RAM server, leaving 80% for other Comfac workloads (ERPNext, AI models, file services).

'''20% of available resources:'''
* 40 vCPUs (20% of 200)
* 200 GB RAM (20% of 1 TB)
* ~2 TB SSD (assuming 10 TB array, 20% = 2 TB)

'''Concurrent student capacity at 20% utilization:'''

{| class="wikitable"
! Stack !! Per-Student Resources !! Students at 20% CPU !! Students at 20% RAM !! Limiting Factor
|-
| '''A: Pure Linux''' || 3 vCPU / 1.4 GB || 13 || 142 || '''CPU: 13 students'''
|-
| '''B: Windows''' || 6.5 vCPU / 6.8 GB || 6 || 29 || '''CPU: 6 students'''
|-
| '''C: Containers''' || 2 vCPU / 0.8 GB || 20 || 250 || '''CPU: 20 students'''
|}

'''Recommendation:''' Use Stack A (Pure Linux) for all labs. This yields ~13 concurrent students within the 20% budget, or up to ~30 students if spread across time slots (not everyone needs a lab simultaneously).

=== Smaller Server: What Hardware for 10 Students? ===
If buying a dedicated training server instead of using the 200-core machine:

{| class="wikitable"
! Stack !! CPU !! RAM !! Storage !! NICs !! Example Hardware
|-
| '''A: Pure Linux''' || 32 cores || 32 GB || 500 GB NVMe || 2x 1GbE || Used Dell R630/R640 (~$300-500)
|-
| '''B: Windows''' || 64 cores || 96 GB || 1 TB NVMe || 2x 1GbE || Used Dell R740 / HP DL360 (~$600-900)
|-
| '''C: Containers''' || 16 cores || 16 GB || 250 GB NVMe || 2x 1GbE || Old desktop + Intel NIC (~$100-200)
|}

=== Exercise-Limited Deployment (Right-Sizing per Lab) ===
Not every lab needs the full sandbox. Deploy only what is needed:

{| class="wikitable"
! Lab !! Stack A Deployed !! vCPUs Used !! RAM Used !! Disk Used
|-
| Day 1 — Theory only || None (wiki only) || 0 || 0 || 0
|-
| Lab 1 (Intro/Backup) || 1 pfSense + 1 client || 1.5 || 768 MB || 5 GB
|-
| Lab 2 (Rules) || 1 pfSense + 1 client + 1 server || 2 || 1 GB || 6 GB
|-
| Lab 3 (NAT) || 1 pfSense + 1 server + router || 2 || 900 MB || 5.5 GB
|-
| Lab 4 (Services) || 2 pfSense + 2 clients + 1 server || 4 || 2.1 GB || 11 GB
|-
| Lab 5-7 (VPNs) || 2 pfSense + 2 clients || 3 || 1.5 GB || 10 GB
|-
| Lab 8 (Multi-WAN) || 1 pfSense + 1 client + router || 2 || 900 MB || 5.5 GB
|-
| Lab 9 (Shaping) || 1 pfSense + 2 clients || 2.5 || 1.3 GB || 6 GB
|-
| Lab 10 (HA) || 2 pfSense + 1 client || 2.5 || 1.3 GB || 9 GB
|}

'''Scheduling strategy:''' If students are scheduled in 1-hour slots and labs are provisioned on-demand, the same 40 vCPUs / 200 GB RAM can serve 40-60 student-slots per day (not concurrently, but sequentially).

=== Phase 1: Resource Setup Validation ===
Before full student rollout, validate the resource model with these tests:

{| class="wikitable"
! Test !! Purpose !! Command / Method !! Pass Criteria
|-
| '''T1: MicroVM Boot''' || Verify pfSense runs in 512MB/1vCPU || qemu-system-x86_64 -m 512 -smp 1 -drive file=pfsense.qcow2 || Boots to login in < 120s
|-
| '''T2: LXC Container Spawn''' || Verify sub-1GB containers work || lxc launch images:alpine/3.19 client || Starts in < 10s; SSH reachable
|-
| '''T3: NoVNC Session''' || Verify one student can access console || websockify + TigerVNC || 640x480 responsive; < 500ms latency
|-
| '''T4: 5 Concurrent Students''' || Validate 20% CPU/RAM budget || Ansible: deploy 5x Stack A || Total < 8 vCPU, < 7 GB RAM
|-
| '''T5: Lab 4 Full Deploy''' || Heaviest lab (2 pfSense + 2 clients + server) || ansible-playbook lab4.yml || Deploys in < 5 min; all VMs pingable
|-
| '''T6: Snapshot Reset Speed''' || Time to reset between students || virsh snapshot-revert + virsh start || < 60 seconds total
|-
| '''T7: AI Evaluation Readiness''' || Validate environment for automated testing || See AI Evaluation section below || All labs pass synthetic health checks
|}

=== AI Evaluation: Automated Readiness Testing ===
Before students arrive, AI agents will validate that each lab environment is functional. This replaces manual smoke-testing.

'''Evaluation Stack:'''
* '''Qwen 3.5 Instruct Coder (9GB)''' — Runs locally on the 200-core server or a dedicated GPU box. Evaluates: pfSense GUI accessibility, rule syntax, VPN handshake status, config.xml validity.
* '''DeepSeek Coder (optional)''' — Cloud or local. Validates Ansible playbook correctness, network topology logic, resource allocation math.
* '''OpenCode (local agent)''' — Executes shell commands inside VMs/containers via SSH/API. Performs end-to-end tests: ping, curl, ipsec status, wg show, etc.

'''Automated Test Sequence (per lab):'''
# Deploy lab environment via Ansible
# AI agent logs into pfSense (admin credentials)
# Screenshot/check each configured page matches expected state
# Run connectivity tests from client VMs
# Verify services are listening on correct ports
# Generate pass/fail report with specific error details
# Destroy lab environment

'''Benefits:'''
* Catch broken base images before students arrive
* Validate that config.xml injections work correctly
* Ensure network isolation between students
* Measure actual resource usage vs. estimates
* Generate readiness dashboard for instructors

'''Implementation:'''
* Python + Selenium/Playwright for pfSense GUI testing
* Paramiko/fabric for SSH-based VM tests
* pytest framework for test organization
* GitHub Actions or local Cron for scheduled runs
* Output: Markdown report posted to wiki or sent via Matrix/Email

== Related Infrastructure ==
* [[System Hardening Strategy: Win2Lin Migration & Infrastructure 251129]] — Server migration and infrastructure hardening
* [[Introduction: Why Self-Host Your Email?]] — Self-hosted email infrastructure context
* [[Mailcow + Thunderbird Setup Guide (Email + Calendar)]] — Email server deployment
* [[Portainer to Docker Compose Migration Guide]] — Container orchestration for network services

----
''This index consolidates networking resources previously scattered across the [[Main Page]]. Last updated: 260423.''

PfSense Training Project Tracker

2026-04-23T07:22:44Z

Justinaquino: Update tracker - Phase 0 material conversion 96% complete

__NOTOC__
<div style="background:#fff8e1; border:1px solid #ffcc80; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Project Tracker''' for Comfac's pfSense Practical Training System implementation. This page tracks all tasks from material conversion to infrastructure deployment and course delivery.
</div>

== Phase 0: Material Conversion (FUND001 → Wiki) ==
Convert all Netgate FUND001 training PDFs into CITWiki pages with detailed summaries. Each wiki page should include: learning objectives, key concepts, step-by-step lab instructions adapted for virtual environment, and troubleshooting tips.

=== Slide Decks ===
* [x] '''SEG1 — Introduction to pfSense''' → [[Training: pfSense Introduction]]
* [x] '''SEG2 — Interfaces, VIPs, and Rules''' → [[Training: Interfaces and Firewall Rules]]
* [x] '''SEG3 — NAT and VIPs''' → [[Training: NAT and Virtual IPs]]
* [x] '''SEG4 — pfSense Services''' → [[Training: pfSense Services]]
* [x] '''SEG5 — VPNs and IPsec''' → [[Training: IPsec VPN]]
* [x] '''SEG6 — OpenVPN''' → [[Training: OpenVPN]]
* [x] '''SEG7 — WireGuard''' → [[Training: WireGuard]]
* [x] '''SEG8 — Multi-WAN''' → [[Training: Multi-WAN]]
* [x] '''SEG9 — Traffic Shaping''' → [[Training: Traffic Shaping]]
* [x] '''SEG10 — High Availability''' → [[Training: High Availability]]
* [x] '''SEG11 — Other Features''' → [[Training: Monitoring and Packages]]

=== Labs ===
* [x] '''Lab 1 — Intro, Getting Started, Backup/Restore''' → [[Training Lab 1: Introduction and Backup Restore]]
* [x] '''Lab 2 — Interfaces, Firewall Rules, Aliases''' → [[Training Lab 2: Firewall Rules and Aliases]]
* [x] '''Lab 3 — Virtual IPs and NAT''' → [[Training Lab 3: NAT and Virtual IPs]]
* [x] '''Lab 4 — Services and Branch Network Setup''' → [[Training Lab 4: Services and Branch Network]]
* [x] '''Lab 5 — IPsec''' → [[Training Lab 5: IPsec VPN]]
* [x] '''Lab 6 — OpenVPN''' → [[Training Lab 6: OpenVPN]]
* [x] '''Lab 7 — WireGuard''' → [[Training Lab 7: WireGuard]]
* [x] '''Lab 8 — Multi-WAN''' → [[Training Lab 8: Multi-WAN]]
* [x] '''Lab 9 — Traffic Shaping''' → [[Training Lab 9: Traffic Shaping]]
* [x] '''Lab 10 — High Availability''' → [[Training Lab 10: High Availability]]

=== Comfac Original Content ===
* [x] '''Introduction Training (Module 0)''' → [[Training: Setting Up a Firewall for Yourself]] — Personal/small business firewall
* [ ] '''the-pfsense-documentation.pdf''' → Summarize into [[Training: pfSense Complete Reference]] or link as external reference
* [ ] '''WindowsTrainingSupportFiles.zip''' → Extract and document client software requirements ([[Training: Client Software Requirements]])
* [ ] '''Training Videos (4× .mkv)''' → Catalog timestamps and link from relevant wiki pages

== Phase 1: Infrastructure Setup ==
Build the virtual training environment on Comfac's 200-core / 1TB RAM machine.

=== Host Preparation ===
* [ ] '''A.1''' Install Ubuntu Server LTS on 200-core host
* [ ] '''A.2''' Configure KVM/libvirt with storage pools (NVMe for images, SSD for ephemeral clones)
* [ ] '''A.3''' Set up network bridges: `br-mgmt`, `br-lan`, `br-wan`, `br-dmz`, `br-internet`
* [ ] '''A.4''' Configure VLANs for student isolation (one VLAN per student or per lab)
* [ ] '''A.5''' Install and configure Ansible controller (host or container)

=== Base Images ===
* [ ] '''B.1''' Download pfSense CE ISO and create qcow2 golden image (2 vCPU, 1 GB RAM, 8 GB disk)
* [ ] '''B.2''' Create Ubuntu Server 22.04/24.04 golden image (1 vCPU, 1 GB RAM, 10 GB disk)
* [ ] '''B.3''' Create Windows 10/11 thin client golden image (2 vCPU, 4 GB RAM, 40 GB disk) — OR decide to use Linux clients only
* [ ] '''B.4''' Create "Internet Router" golden image (Ubuntu with FRR/Quagga or simple static routes, 1 vCPU, 512 MB RAM)
* [ ] '''B.5''' Test each golden image boots and functions correctly

=== Automation ===
* [ ] '''C.1''' Write Ansible playbook: `lab1-student-env.yml` (1 pfSense + 1 client)
* [ ] '''C.2''' Write Ansible playbook: `lab2-student-env.yml` (1 pfSense + 1 client + 1 server)
* [ ] '''C.3''' Write Ansible playbook: `lab3-student-env.yml` (1 pfSense + 1 server + internet)
* [ ] '''C.4''' Write Ansible playbook: `lab4-student-env.yml` (2 pfSense + 2 clients + 1 server)
* [ ] '''C.5''' Write Ansible playbooks for Labs 5–10 (VPNs, Multi-WAN, Shaping, HA)
* [ ] '''C.6''' Write Ansible playbook: `cleanup-student-env.yml` (destroy VMs, free resources)
* [ ] '''C.7''' Write Ansible playbook: `reset-student-env.yml` (revert to snapshot/linked clone base)
* [ ] '''C.8''' Test all playbooks end-to-end with a single student ID

=== NoVNC Portal ===
* [ ] '''D.1''' Evaluate Kimchi vs Apache Guacamole vs custom NoVNC proxy
* [ ] '''D.2''' Install and configure chosen NoVNC solution
* [ ] '''D.3''' Integrate NoVNC with student authentication (LDAP, local wiki accounts, or simple token-based)
* [ ] '''D.4''' Build student dashboard: list of phases/labs, "Launch Lab" button, countdown timer
* [ ] '''D.5''' Test 5 concurrent NoVNC sessions for stability
* [ ] '''D.6''' Test 20 concurrent NoVNC sessions for performance

== Phase 2: Curriculum Development ==
Design the student-facing training program.

=== Introduction Course (Most Common Use Case) ===
* [x] '''E.1''' Define "Setting Up a Firewall for Yourself" scope: home office / small business
* [x] '''E.2''' Write Module 0: Why You Need a Firewall (threats, NAT basics, basic topology)
* [x] '''E.3''' Write Module 1: Install pfSense on Old PC or VM (hardware requirements, USB install, first boot wizard)
* [x] '''E.4''' Write Module 2: Basic WAN + LAN Setup (DHCP, DNS, first internet connection)
* [x] '''E.5''' Write Module 3: Essential Firewall Rules (block incoming, allow outgoing, ICMP)
* [x] '''E.6''' Write Module 4: Port Forwarding for Common Services (game server, camera, NAS)
* [x] '''E.7''' Write Module 5: VPN for Remote Access (WireGuard road warrior setup)
* [x] '''E.8''' Write Module 6: Backup and Updates (config.xml backup, update schedule)
* [x] '''E.9''' Create hands-on lab for Introduction Course (single pfSense + 1 client VM)
* [ ] '''E.10''' Record or source video walkthroughs for each module

=== Full FUND001 Adaptation ===
* [x] '''F.1''' Map each SEG slide deck to a wiki training page with summary + key takeaways
* [x] '''F.2''' Adapt Netgate labs from physical/virtualbox environment to KVM/Ansible environment
* [ ] '''F.3''' Update IP addressing schema for Comfac virtual lab (avoid conflicts with production)
* [ ] '''F.4''' Write pre-lab briefing pages (what you'll learn, expected outcomes)
* [ ] '''F.5''' Write post-lab review pages (common mistakes, verification steps, "show me" checklist)
* [ ] '''F.6''' Create quiz questions for each phase (5–10 questions, auto-graded if possible)

== Phase 3: Pilot & Refinement ==
Run the training with a small group before full rollout.

=== Internal Pilot ===
* [ ] '''G.1''' Recruit 3–5 internal Comfac IT staff as pilot students
* [ ] '''G.2''' Run Phase 1 (Foundations) with pilot group — collect feedback
* [ ] '''G.3''' Run Phase 2 (NAT & Services) with pilot group — collect feedback
* [ ] '''G.4''' Run one VPN lab (IPsec or OpenVPN) with pilot group — test resource limits
* [ ] '''G.5''' Document all bugs, confusion points, and timeouts
* [ ] '''G.6''' Refine playbooks and wiki pages based on pilot feedback

=== Resource Tuning ===
* [ ] '''H.1''' Measure actual CPU/RAM/disk usage per student during pilot
* [ ] '''H.2''' Adjust VM specs if over- or under-provisioned
* [ ] '''H.3''' Test memory overcommit ratios for safe concurrency scaling
* [ ] '''H.4''' Document maximum safe concurrent student count

== Phase 4: Deployment & Operations ==
Prepare for regular training delivery.

=== Student Onboarding ===
* [ ] '''I.1''' Create student onboarding guide (how to access portal, use NoVNC, reset lab)
* [ ] '''I.2''' Create instructor guide (how to monitor progress, assist students, grade labs)
* [ ] '''I.3''' Set up scheduling system (book lab time slots, prevent over-allocation)
* [ ] '''I.4''' Create completion certificates or badges

=== Monitoring & Maintenance ===
* [ ] '''J.1''' Set up host monitoring (Prometheus/Grafana or simple `libvirt` stats)
* [ ] '''J.2''' Configure alerts for host resource exhaustion
* [ ] '''J.3''' Schedule weekly base image updates (pfSense patches, OS updates)
* [ ] '''J.4''' Document disaster recovery (rebuild host from Ansible, restore golden images)

== Quick Status Dashboard ==
{| class="wikitable"
! Phase !! Status !! % Complete !! Blockers
|-
| Phase 0: Material Conversion || 🟢 Done (22/23) || 96% || Pending: reference PDF, support files, videos
|-
| Phase 1: Infrastructure Setup || 🔴 Not Started || 0% || Need 200-core host access
|-
| Phase 2: Curriculum Development || 🟡 In Progress || 65% || Need video recordings, quizzes, pre/post lab pages
|-
| Phase 3: Pilot & Refinement || 🔴 Not Started || 0% || Waiting on Phase 1 + 2
|-
| Phase 4: Deployment & Operations || 🔴 Not Started || 0% || Waiting on Phase 3
|}

== Resource Summary ==
'''Per-student minimum:''' 6 vCPUs, 6.5 GB RAM, 62 GB disk
'''Per-student full lab:''' 10 vCPUs, 10.5 GB RAM, 110 GB disk
'''200-core / 1TB capacity:''' 20–40 concurrent students (conservative to optimized)

'''Next Actions (This Week):'''
# Summarize the-pfsense-documentation.pdf into a reference page
# Document WindowsTrainingSupportFiles.zip contents
# Catalog training video timestamps
# Begin Ansible playbook drafting for Lab 1 environment
# Evaluate Kimchi vs Guacamole for NoVNC portal

Training: Setting Up a Firewall for Yourself

2026-04-23T07:21:00Z

Justinaquino: Create Introduction Training Module 0 - personal/small business firewall setup

__NOTOC__
<div style="background:#fff3e0; border:1px solid #ffb74d; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Comfac Entry-Level Training: Module 0''' — Setting Up a Firewall for Yourself. The most common, practical starting point before advancing to the full FUND001 curriculum.
</div>

== Target Audience ==
* Home users who want to secure their network
* Small business owners (1–10 employees)
* IT staff new to networking before they tackle enterprise deployments
* Anyone who has never configured a router or firewall before

== Learning Objectives ==
By the end of this module, you will be able to:
* Explain why a firewall is necessary for homes and small offices
* Install pfSense on an old PC or VM with minimum hardware
* Configure basic WAN and LAN interfaces
* Set up essential firewall rules (allow outgoing, block incoming)
* Configure port forwarding for common services
* Set up a basic WireGuard VPN for remote access
* Back up and update the firewall configuration
* Diagnose common connectivity problems

== Module 0: Why You Need a Firewall ==
=== The Threats at Home and Small Office ===
Most people rely on the "router" provided by their ISP. These devices are:
* '''Minimally configured''' — often with default passwords and outdated firmware
* '''Poorly maintained''' — ISPs rarely push security updates promptly
* '''Limited in features''' — no VPN, no traffic logging, no intrusion detection

'''Common risks:'''
* Unauthorized remote access to cameras, NAS, printers
* Malware spreading between family/employee devices
* Cryptojacking, ransomware, botnet participation
* Data exfiltration from poorly secured IoT devices

'''What a firewall gives you:'''
* '''Stateful inspection''' — only allows return traffic for connections you initiated
* '''Network segmentation''' — isolate guests, IoT, and work devices
* '''VPN access''' — securely access your home/office network from anywhere
* '''Logging & visibility''' — see what devices are doing on your network
* '''Ad and malware blocking''' — integrate with DNS blocklists (Pi-hole)

== Module 1: Hardware and Installation ==
=== Minimum Hardware ===
{| class="wikitable"
! Component !! Minimum !! Recommended
|-
| CPU || 64-bit, 1 GHz || 64-bit, 2+ cores, AES-NI support
|-
| RAM || 1 GB || 4 GB
|-
| Storage || 8 GB SSD/USB || 32 GB SSD
|-
| NICs || 2 Ethernet ports || Intel i210/i350 dual/quad port NIC
|}

'''Good sources of cheap hardware:'''
* Old office desktops (Dell OptiPlex, HP EliteDesk)
* Thin clients with PCIe slot for NIC
* Used 1U servers (noisy but cheap)
* Protectli/Qotom mini-PCs (purpose-built, fanless)

'''Installation methods:'''
# Download pfSense CE ISO from https://www.pfsense.org/downloads
# Write to USB with Rufus (Windows) or dd (Linux)
# Boot from USB, install to SSD/HDD
# Remove USB, reboot
# Default LAN: 192.168.1.1

== Module 2: First Boot and Basic Setup ==
=== The Setup Wizard ===
# Connect laptop to LAN port
# Browse to https://192.168.1.1
# Log in: admin / pfsense
# Complete the wizard:
#* '''General Info''' — Set hostname (e.g., homefw), domain (local)
#* '''Time Server''' — Use default or local NTP
#* '''WAN''' — Select DHCP (most home/DSL) or PPPoE (some fiber)
#* '''LAN''' — Leave 192.168.1.1/24 or change to obscure subnet (e.g., 10.47.83.1/24)
#* '''Password''' — Change from default immediately

'''Why change from 192.168.1.1?''' If you later connect via VPN from a coffee shop that also uses 192.168.1.x, your traffic may not route correctly. Using an obscure subnet avoids this.

=== Essential Post-Setup ===
# '''System -> General Setup''' — Set timezone, language
# '''System -> Advanced -> Networking''' — Disable NAT reflection if not needed
# '''System -> Update''' — Check for updates immediately
# '''Diagnostics -> Backup & Restore''' — Download first config backup

== Module 3: Essential Firewall Rules ==
=== Default Rules (pfSense handles these automatically) ===
* '''LAN''' — Allow all (default)
* '''WAN''' — Block all (implicit, not shown)

=== Best Practice: Restrict LAN Outbound ===
For a more secure home/small office, replace "LAN allow all" with specific allowed protocols:

{| class="wikitable"
! Protocol !! Port !! Purpose
|-
| TCP/UDP || 53 || DNS
|-
| TCP/UDP || 123 || NTP
|-
| TCP/UDP || 443 || HTTPS
|-
| TCP || 80 || HTTP (optional)
|-
| TCP/UDP || 5222 || XMPP/chat (optional)
|}

'''How to do it:'''
# Firewall -> Rules -> LAN
# Delete the default "Allow All" rule
# Add rules for each protocol/port above
# Add a final "Block" rule at the bottom (with logging enabled)

'''Note:''' This breaks some apps/games. For a family home, "Allow All" outbound is usually fine. For a business, restrict outbound.

== Module 4: Port Forwarding ===
=== Common Scenarios ===
{| class="wikitable"
! Service !! External Port !! Internal IP !! Internal Port !! Notes
|-
| Minecraft server || 25565 || 192.168.1.50 || 25565 || Gaming
|-
| Camera/DVR || 8080 || 192.168.1.60 || 80 || Change default port
|-
| NAS/Web || 443 || 192.168.1.70 || 443 || Use reverse proxy if multiple services
|-
| Plex || 32400 || 192.168.1.80 || 32400 || Remote streaming
|}

'''Steps:'''
# Firewall -> NAT -> Port Forward
# Click Add
# Interface: WAN
# Protocol: TCP (or TCP/UDP)
# Destination: WAN Address
# Destination Port Range: external port
# Redirect Target IP: internal server IP
# Redirect Target Port: internal port
# Save → Apply

'''Security tip:''' Don't forward RDP (3389) or SSH (22) directly. Use a VPN instead.

== Module 5: WireGuard VPN (Road Warrior) ==
=== Why VPN beats port forwarding ===
* One secure tunnel instead of many open ports
* Access your entire network as if you were there
* Works on phones, laptops, tablets
* No need to expose individual services

=== Setup Steps ===
# Install '''WireGuard package''' — System -> Package Manager -> Available Packages
# VPN -> WireGuard -> Settings → Enable
# Tunnels → Add Tunnel
#* Name: RoadWarrior
#* Listen Port: 51820
#* Interface Keys: Generate key pair
# Save
# Assign interface — Interfaces -> Assignments → add wg0 as OPTx
# Enable interface, set static IP: 10.200.200.1/24
# Peers → Add Peer
#* Tunnel: RoadWarrior
#* Public Key: [client's public key]
#* Allowed IPs: 10.200.200.2/32
#* Endpoint: [blank for roaming clients]
# Firewall -> Rules -> WireGuard interface → Allow All
# Firewall -> Rules -> LAN → Allow from WireGuard net
# Firewall -> NAT -> Outbound → Manual → Add rule for WireGuard net → WAN

'''Client config (phone/laptop):'''
* Install WireGuard app
* Create tunnel, scan QR code or paste config
* Peer: [server public key], Endpoint: your-public-ip:51820
* Allowed IPs: 0.0.0.0/0 (full tunnel) or 192.168.1.0/24 (split tunnel)

'''Opening the port:'''
# Firewall -> Rules -> WAN
# Add rule: Protocol UDP, Port 51820, Source Any, Destination WAN Address

== Module 6: Backup and Maintenance ==
=== Monthly Checklist ===
* [ ] System -> Update: Check for updates
* [ ] Diagnostics -> Backup & Restore: Download config backup
* [ ] Check Dashboard for interface errors, high CPU, or memory usage
* [ ] Review Firewall logs for blocked suspicious traffic
* [ ] Verify VPN clients can still connect

=== Yearly Checklist ===
* [ ] Rotate WireGuard keys
* [ ] Review all port forwards — remove unused ones
* [ ] Check certificate expiry (if using ACME/Let's Encrypt)
* [ ] Audit user accounts and passwords
* [ ] Test restore from backup on a spare VM

== Troubleshooting Common Problems ==
{| class="wikitable"
! Problem !! Likely Cause !! Fix
|-
| No Internet after install || WAN not getting IP || Check cable; set WAN to DHCP or PPPoE
|-
| Can't access web GUI || Wrong IP; HTTPS blocked || Try http://192.168.1.1; check laptop IP
|-
| Port forward not working || ISP CGNAT || Check WAN IP vs public IP; use VPN instead
|-
| VPN connects but no LAN access || Missing firewall/NAT rule || Add allow rule on WireGuard iface; add outbound NAT
|-
| Slow Internet || Hardware too weak || Check CPU usage; upgrade NIC or whole box
|-
| Can't reach some websites || DNS issue || Use 1.1.1.1 or 8.8.8.8 in DNS Resolver forwarders
|}

== Build Your Own Firewall — Capstone Exercise ==
'''Scenario:''' You have an old Dell OptiPlex, a 2-port Intel NIC, and a home fiber connection.

'''Requirements:'''
# Install pfSense CE
# Configure WAN (DHCP) and LAN (static 10.47.83.1/24)
# Set admin password
# Enable DNS Resolver with forwarding to Cloudflare (1.1.1.1)
# Create firewall rules: allow DNS, HTTPS, NTP outbound only
# Set up WireGuard for 2 devices (phone + laptop)
# Forward port 32400 to a Plex server at 10.47.83.50
# Enable AutoConfigBackup (or manual monthly backups)
# Document everything in a simple runbook

'''Success criteria:'''
* Family can browse web normally
* You can VPN in from outside and access LAN resources
* Plex is accessible remotely
* Configuration is backed up

== Next Steps ==
Once comfortable with this module, advance to the full '''FUND001 curriculum''':
# [[Training: pfSense Introduction]] — Phase 1, Day 1
# [[Training Lab 1: Introduction and Backup Restore]] — Hands-on lab

Or explore specialized topics:
* [[Training: pfSense Services]] — DHCP, DNS, Dynamic DNS deep dive
* [[Training: Multi-WAN]] — Add a backup ISP connection
* [[Networking PfSense Index]] — All Comfac networking resources

----
''This module was created for Comfac IT practical training. Built on real-world frequency of problems encountered from personal to small-business networks.''

Training: Monitoring and Packages

2026-04-23T07:16:09Z

Justinaquino:

__NOTOC__
<div style="background:#1e3a5f; color:#fff; padding:12px; border-radius:6px; margin-bottom:16px;">
<span style="font-size:1.2em; font-weight:bold;">📘 Netgate pfSense Training — Module 11</span><br/>
System Monitoring, Logging, and the Package System
</div>

== Learning Objectives ==

By the end of this module, you should be able to:

{| class="wikitable" style="width:100%;"
|-
! Objective
! Description
|-
| Monitor system health
| Use built-in Status pages, Traffic Graphs, and RRD Graphs to observe system performance.
|-
| Configure logging
| Access system logs and export them to an external log aggregation server.
|-
| Understand SNMP
| Enable and use SNMP for remote monitoring and integration with NMS tools.
|-
| Manage packages
| Install, update, and remove packages to extend pfSense functionality.
|-
| Evaluate package maturity
| Interpret version numbers (e.g., 0.x = young package) and assess stability.
|}

== System Monitoring ==

=== Status Pages ===

pfSense provides many built-in '''Status''' pages that give real-time and historical insight into system behavior:

* '''Dashboard''' — customizable overview with widgets for system info, interfaces, services, and gateways.
* '''Traffic Graph''' — live view of traffic per interface.
* '''RRD Graphs''' — historical data for CPU, memory, interface traffic, packets, states, and quality.
* '''System Logs''' — consolidated logging for the firewall, DHCP, DNS, VPN, and other services.

=== RRD Graphs ===

'''RRDtool''' is integrated into pfSense to store and graph time-series data. Available graphs include:

{| class="wikitable" style="width:100%;"
|-
! Category
! Metrics
|-
| System
| CPU usage, memory usage, swap usage, load average
|-
| Traffic
| Inbound/outbound bytes and packets per interface
|-
| Packets
| Passed, blocked, and error packet counts
|-
| Quality
| Gateway latency and packet loss over time
|-
| States
| Current firewall state table size
|}

=== SNMP Monitoring ===

pfSense includes an '''SNMP service''' (via '''bsnmpd''') that allows remote monitoring with tools such as:

* Zabbix
* Nagios / Icinga
* Cacti
* PRTG
* LibreNMS

Enable SNMP under '''Services → SNMP''' and configure community strings, traps, and binding interfaces as needed.

=== Logging ===

System logs are available under the '''Status → System Logs''' menu. Key capabilities:

* View logs by category (Firewall, DHCP, DNS Resolver, VPN, etc.)
* Adjust log verbosity and retention
* '''Export logs''' to an external log aggregation server (e.g., Syslog, Graylog, ELK stack, Splunk) for centralized analysis

== Package System ==

=== Overview ===

The '''Package System''' extends pfSense beyond the base installation. Packages are installed from the official Netgate repository via '''System → Package Manager'''.

=== Common and Popular Packages ===

{| class="wikitable" style="width:100%;"
|-
! Package
! Purpose
! Category
|-
| '''pfBlockerNG'''
| IP and DNS-based blocking for geo-location, threat feeds, and ad blocking
| Security / Filtering
|-
| '''Suricata'''
| High-performance Network IDS/IPS with rule-based threat detection
| Security
|-
| '''Snort'''
| Network intrusion detection and prevention system
| Security
|-
| '''HAProxy'''
| TCP/HTTP load balancer and reverse proxy
| Traffic Management
|-
| '''Squid / SquidGuard'''
| Web proxy with content filtering and access control
| Proxy / Filtering
|-
| '''pfSense-pkg-FRR'''
| Routing protocols (BGP, OSPF, RIP)
| Routing
|-
| '''ntopng'''
| Network traffic probe and flow analysis
| Monitoring
|-
| '''NRPE / Zabbix Agent'''
| Client agents for remote monitoring integration
| Monitoring
|-
| '''ACME'''
| Automatic SSL/TLS certificate issuance via Let's Encrypt
| Certificates
|-
| '''Telegraf'''
| Metrics collection agent for InfluxDB/Prometheus
| Monitoring
|}

=== Package Installation Best Practices ===

* '''Pay attention to version numbers!''' A version of '''0.n''' typically indicates a young or experimental package.
* Install packages only from the official repository or trusted sources.
* Use '''Backup / Restore''' to preserve package states for reinstallation after upgrades.
* Review package documentation before installing in production.

=== Backup and Restore for Packages ===

pfSense's built-in backup system includes an option to reinstall packages automatically after a restore. Ensure this option is enabled under '''Diagnostics → Backup & Restore''' when creating configuration backups.

== Summary ==

* pfSense provides robust '''system monitoring''' through Status pages, Traffic Graphs, '''RRD Graphs''', and '''SNMP'''.
* '''System logs''' can be viewed locally or exported to external aggregation servers for centralized analysis.
* The '''Package System''' dramatically extends pfSense capabilities with popular additions such as '''pfBlockerNG''', '''Suricata''', '''HAProxy''', and '''Squid'''.
* Always evaluate '''package maturity''' (version numbers) and maintain '''backups''' before making significant changes.

== Next Module ==

* Previous: [[Training: Firewall Rules and NAT]]
* Next: [[Training: VPN Configuration]]
* Return to [[Training: pfSense Course Index]]

== Source Attribution ==

* '''Source:''' Netgate pfSense Training Material
* '''Document:''' FUND001-LIVE-SLIDE-SEG11-OTHER.pdf
* '''Section:''' 11 — Other Features (Monitoring, Logging, Packages)
* '''Copyright:''' © 2017 Rubicon Communications dba Netgate
* '''Conversion Date:''' {{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY}}

[[Category:pfSense Training]]
[[Category:Network Security]]

Training: Monitoring and Packages

2026-04-23T07:14:48Z

Justinaquino: Created page with "__NOTOC__ <div style="background:#1e3a5f; color:#fff; padding:12px; border-radius:6px; margin-bottom:16px;"> <span style="font-size:1.2em; font-weight:bold;">📘 Netgate pfSense Training — Module 11</span><br/> System Monitoring, Logging, and the Package System </div> == Learning Objectives == By the end of this module, you should be able to: {| class="wikitable" style="width:100%;" |- ! Objective ! Description |- | Monitor system health | Use built-in Status pages..."

Training Lab 9: Traffic Shaping

2026-04-23T07:10:26Z

Justinaquino: Imported from FUND001-LIVE-Lab9-TrafficShaping.pdf

__NOTOC__

<div style="background:#005500; color:white; padding:12px; border-radius:6px; margin-bottom:16px;">
'''Netgate pfSense Plus Fundamentals — Lab 9: Traffic Shaping'''<br/>
<small>Training lab manual: FUND001-LIVE-Lab9-TrafficShaping.pdf</small>
</div>

== Overview ==

This lab covers limiters and traffic shaping at an introductory level.

We will configure limiters to restrict HQ LAN hosts to '''2 Mb down / 512 Kb up'''. The mask option of limiters is used to configure this limit on a '''per-IP basis''' — so each IP in the LAN gets its own 2 Mb down, 512 Kb up pipe.

== Understanding Limiter Direction ==

Limiters are applied to firewall rules by specifying them under '''In''' and '''Out''' in the advanced options. The direction of traffic is from the perspective of that interface of the firewall.

* '''Traffic coming into the LAN NIC''' = upload traffic
* '''Traffic leaving the LAN NIC''' = download traffic

The mask of limiters can be configured on a '''source address''' or '''destination address''' basis:

{| class="wikitable"
! Limiter !! Mask Setting !! Reason
|-
| Download (2M-down) || Destination addresses || Traffic leaving the LAN interface has internal clients' IPs as the destination.
|-
| Upload (512K-up) || Source addresses || Traffic entering the LAN interface is sourced from internal clients' IPs.
|}

== Configuring Limiters ==

On '''fw1-HQ''', browse to '''Firewall → Traffic Shaper → Limiters''' tab. Click '''New Limiter''' to add a new limiter.

=== Download Limiter ===

{| class="wikitable"
! Setting !! Value
|-
| Name || 2M-down
|-
| Enable || (checked)
|-
| Bandwidth || 2 Mbit/s
|-
| Mask || Destination addresses
|-
| Description || 2 Mb down per-IP
|}

Leave the remainder at defaults and click '''Save'''.

=== Upload Limiter ===

{| class="wikitable"
! Setting !! Value
|-
| Name || 512K-up
|-
| Enable || (checked)
|-
| Bandwidth || 512 Kbps
|-
| Mask || Source addresses
|-
| Description || 512 Kb up per-IP
|}

Leave the remainder at defaults, click '''Save''', then '''Apply Changes'''.

== Applying Limiters to Firewall Rules ==

Just configuring the limiters doesn't make them active. They must be assigned to a firewall rule to be applied.

# Browse to '''Firewall → Rules → LAN'''.
# Edit the '''"Default allow LAN to any"''' rule.
# Scroll down under '''Advanced''', and click the '''Advanced''' button to the right of '''In/Out'''.
# For the '''In''' limiter, choose '''512K-up'''.
# For the '''Out''' limiter, choose '''2M-down'''.
# Click '''Save''' and '''Apply Changes'''.

Back at the LAN firewall rules screen, you'll see the '''(a)''' icon to the left of the default LAN rule, meaning one or more advanced options are specified on that rule. Hover your mouse cursor over that button to see what is configured.

== Testing Limiters ==

# Pull up '''Status → Traffic Graph → WAN''' on fw1-HQ.
# Run a speed test (e.g., speedtest.net).
# You should see speeds of approximately '''2 Mb down, 512 Kb up'''.

== Traffic Shaper Basic Configuration (Wizard) ==

In this section we configure a basic traffic shaping setup prioritizing VoIP over all else at the branch location (fw1-branch).

=== Wizard Setup ===

# Browse to '''Firewall → Traffic Shaper → Wizards'''.
# Choose '''traffic_shaper_wizard_multi_all.xml'''.
# At the first screen, specify '''1''' for the number of WAN and LAN connections and click '''Next'''.
# Choose '''PRIQ''' for both download and upload schedulers.
# Specify connection bandwidth as '''100 Mbit/s''' upload and download.
# Click '''Next'''.
# Check '''"Prioritize Voice over IP traffic"'''. Fill in '''128 Kbit/s''' for upload and download bandwidth (not actually used with PRIQ).
# Click '''Next''' three times past penalty box, peer-to-peer networking, and network games.
# At the '''"Raise or lower other applications"''' screen, enable it and choose '''VNC''' as higher priority.
# Click '''Finish'''.

== Reviewing Firewall Rule Shaping Configuration ==

Browse to '''Firewall → Rules → Floating''' to see the traffic shaper rules added by the wizard. These are match rules which specify the appropriate queue for each type of traffic.

* The VoIP traffic classification ends up as a rule matching all UDP traffic from any source to any destination, with queue '''qVoIP'''.
* All traffic not matching a floating rule specifying a queue will go into the '''default queue'''.

== Reviewing Shaper Queue Configuration ==

Browse to '''Firewall → Traffic Shaper'''. The '''By Interface''' and '''By Queue''' tabs both show configured queues (two different layouts of the same data).

* '''By Queue''' is typically used for manual configuration.
* '''By Interface''' is the standard review view.
* You can click '''"Remove Shaper"''' on the '''By Interface''' tab to remove and disable traffic shaping.

== Testing and Checking Status ==

# Reset all states: '''Diagnostics → States → Reset States''' tab → click '''Reset'''.
# Browse to '''Status → Queues''' and monitor while generating traffic.
# Run a speed test — the speed test traffic will fall into the '''default queue'''.

== Generating SIP Traffic ==

Use '''SIPp''' on the test systems:

On '''remote-host''' (100.64.0.50):
<pre>
training@remote-host:~$ sipp -sn uas
</pre>

On '''branch-client''' (172.18.1.100):
<pre>
training@branch-client:~$ sipp -sn uac 100.64.0.50
</pre>

These commands initiate 10 SIP calls per second indefinitely. View '''Status → Queues''' while running to see traffic in the VoIP queue.

== Long-term Monitoring ==

When traffic shaping is enabled, RRD graphs include queue statistics and queue drops.

# Browse to '''Status → Monitoring''' and click the wrench icon.
# For '''Left Axis''', choose '''Queues'''.
# The '''Queue Drops''' graph shows packets dropped from each queue.

Ideally, you want to see '''0 drops''' across all high-priority queues, with drops limited to lower or default priority traffic.

----

<div style="background:#f0f8ff; padding:10px; border-left:4px solid #005500;">
'''Previous Module:''' [[Training:_Traffic_Shaping|Section 9 — Traffic Shaping (Slides)]]
</div>

== Source Attribution ==

* '''Document:''' FUND001-LIVE-Lab9-TrafficShaping.pdf
* '''Course:''' pfSense Plus Fundamentals and Practical Applications
* '''Copyright:''' © 2021 Rubicon Communications, LLC (Netgate)
* '''Extracted and formatted for internal training wiki.'''

Training: Traffic Shaping

2026-04-23T07:10:06Z

Justinaquino: Imported from FUND001-LIVE-SLIDE-SEG9-SHAPE.pdf

__NOTOC__

<div style="background:#003366; color:white; padding:12px; border-radius:6px; margin-bottom:16px;">
'''Netgate pfSense Plus Fundamentals — Section 9: Traffic Shaping'''<br/>
<small>Training slide deck: FUND001-LIVE-SLIDE-SEG9-SHAPE.pdf</small>
</div>

== Traffic Shaping — Overview ==

Traffic shaping is a form of '''managed unfairness of bandwidth'''. It helps avoid the default FIFO queueing behavior imposed by ISPs.

* '''Queues''' define traffic priorities.
* '''Rules''' assign traffic to queues.
* There are two separate methods for shaping:
** '''Limiters''' (dummynet pipes)
** '''Traffic Shaper''' (ALTQ)

== Limiters ==

Limiters provide a quick, easy means of imposing '''hard bandwidth limits'''.

* Can be applied on a '''group or per-IP basis'''.
* Optionally '''schedule-based'''.
* Advanced options include:
** Queue size
** Delay
** Packet Loss

== Traffic Shaping Rules ==

* Rules are evaluated from the '''point of view of traffic leaving an interface'''.
* Typically use '''floating rules''' to apply shaping.
* '''In/Out''' options under advanced rule options are used to assign queues.
* Matches only assign queues — they do not control access.

== Traffic Shaping Wizards ==

The wizards offer an easy way to implement queueing and attempt to automate common scenarios.

{| class="wikitable"
! Wizard Type !! Description
|-
| Multiple LAN/WAN || Most common scenario
|-
| Dedicated Links || For dedicated link configurations
|}

== Traffic Shaping Schedulers ==

Schedulers are methods of handling queueing. The following schedulers are available:

{| class="wikitable"
! Scheduler !! Notes
|-
| HFSC || Hierarchical Fair Service Curve
|-
| CBQ || Class-Based Queueing
|-
| FAIRQ || Legacy scheduler
|-
| CODELQ || Legacy scheduler
|-
| PRIQ || '''Easiest solution — recommended wherever possible'''
|}

== Section 9 Summary ==

* Try to keep configurations as simple as possible.
* Use '''PRIQ''' wherever possible.
* Limiter rules can be on a schedule.
* Limiters can be per-IP or per-network (masking).
* Ensure appropriate rule matches.
* Clear states if needed after making changes.
* Check the Traffic-Shaping section of the book for more details.

----

<div style="background:#f0f8ff; padding:10px; border-left:4px solid #003366;">
'''Next Module:''' [[Training_Lab_9:_Traffic_Shaping|Lab 9 — Traffic Shaping (Hands-on)]]
</div>

== Source Attribution ==

* '''Document:''' FUND001-LIVE-SLIDE-SEG9-SHAPE.pdf
* '''Course:''' pfSense Plus Fundamentals and Practical Applications
* '''Copyright:''' © 2017 Rubicon Communications, LLC dba Netgate
* '''Extracted and formatted for internal training wiki.'''

Training Lab 7: WireGuard

2026-04-23T07:09:24Z

Justinaquino: Created page with "__NOTOC__ <div style="background:#e7f3ff;border:1px solid #a3c6ff;padding:10px;margin-bottom:15px;"> '''Training Lab 7: WireGuard Site-to-Site VPN''' — pfSense Plus Fundamentals and Practical Application </div> == Overview == This lab goes through an example configuration of WireGuard for site-to-site VPNs. WireGuard has no concept of sessions or connections. The protocol uses public and private keys to authenticate and route traffic. WireGuard instances consist of..."

__NOTOC__

<div style="background:#e7f3ff;border:1px solid #a3c6ff;padding:10px;margin-bottom:15px;">
'''Training Lab 7: WireGuard Site-to-Site VPN''' — pfSense Plus Fundamentals and Practical Application
</div>

== Overview ==

This lab goes through an example configuration of WireGuard for site-to-site VPNs.

WireGuard has no concept of sessions or connections. The protocol uses public and private keys to authenticate and route traffic. WireGuard instances consist of a tunnel and one or more peer definitions which contain the necessary keys and other configuration data that allows the two sides to communicate.

== Step 1: Delete OpenVPN ==

First, since we have an OpenVPN configured here already, we need to delete it so it doesn’t interfere with our WireGuard setup. On both fw1-HQ and fw1-branch, browse to '''VPN → OpenVPN''' and delete all client and server instances.

== Step 2: Configure WireGuard Settings ==

Browse to '''VPN → WireGuard → Settings''' on both firewalls and:

* Click the '''Enable''' checkbox
* For Interface Group Membership, choose '''Only Unassigned Tunnels'''
* Uncheck '''Hide Secrets''' and '''Hide Peers'''
* Scroll down and click '''Save'''

== Step 3: Add a New Tunnel on Both Firewalls ==

On FW1-HQ and Branch-FW, navigate to '''VPN → WireGuard → Tunnels''' and click the green '''+Add Tunnel''' button.

{| class="wikitable"
|-
! Setting !! Value
|-
| Enabled || checked
|-
| Description || Site-to-Site VPN
|-
| Listen Port || 51820
|-
| Interface Keys || Press the blue Generate button
|}

Make a note of the public key on '''BOTH''' firewalls, as this will be required later. Then click '''Save'''.

== Step 4: Configure a Peer on FW1-HQ ==

Edit the tunnel on FW1-HQ and click '''+Add Peer'''.

{| class="wikitable"
|-
! Setting !! Value
|-
| Enable || checked
|-
| Description || Branch Office Peer
|-
| Dynamic Endpoint || unchecked
|-
| Endpoint || 203.0.113.10
|-
| Endpoint Port || 51820
|-
| Public Key || (paste public key from Branch-FW)
|-
| Pre-shared Key || (blank)
|-
| Allowed IPs || 10.6.210.0/30 (Tunnel Network), 172.18.1.0/24 (Branch LAN)
|}

Scroll down and click '''Save Peer'''.

== Step 5: Configure a Peer on Branch-FW ==

Edit the tunnel on Branch-FW and click '''+Add Peer'''.

{| class="wikitable"
|-
! Setting !! Value
|-
| Enable || checked
|-
| Description || HQ Peer
|-
| Dynamic Endpoint || unchecked
|-
| Endpoint || 192.0.2.2
|-
| Endpoint Port || 51820
|-
| Public Key || (paste public key from FW1-HQ)
|-
| Pre-shared Key || (blank)
|-
| Allowed IPs || 10.6.210.0/30 (Tunnel Network), 172.17.1.0/24 (HQ LAN)
|}

Scroll down and click '''Save Peer'''.

== Step 6: Assign Interfaces ==

=== Select Default Gateways ===

On both firewalls, navigate to '''System → Routing''' and set Default Gateway IPv4 to a specific gateway, such as WANGW. Click '''Save''' and '''Apply'''.

=== Assign WireGuard Interface on FW1-HQ ===

Navigate to '''Interfaces → Assignments''', choose the tun_gw0 interface, and click '''+Add''' (creates OPT4). Configure OPT4:

{| class="wikitable"
|-
! Setting !! Value
|-
| Enable || checked
|-
| Description || BRANCH_VPN
|-
| IPv4 Configuration Type || Static IPv4
|-
| IPv4 Address || 10.6.210.1/30
|-
| Gateway Name || VPN_BRANCHGW
|-
| Gateway IPv4 || 10.6.210.2
|}

=== Assign WireGuard Interface on Branch-FW ===

Navigate to '''Interfaces → Assignments''', choose the tun_gw0 interface, and click '''+Add''' (creates OPT1). Configure OPT1:

{| class="wikitable"
|-
! Setting !! Value
|-
| Enable || checked
|-
| Description || HQ_VPN
|-
| IPv4 Configuration Type || Static IPv4
|-
| IPv4 Address || 10.6.210.2/30
|-
| Gateway Name || VPN_HQGW
|-
| Gateway IPv4 || 10.6.210.1
|}

== Step 7: Create Firewall Rules on WAN ==

On both firewalls, navigate to '''Firewall → Rules → WAN''' and add a rule to the top:

{| class="wikitable"
|-
! Setting !! Value
|-
| Action || Pass
|-
| Protocol || UDP
|-
| Source || Any
|-
| Destination || WAN Address
|-
| Destination Port || 51820
|-
| Description || Pass traffic to WireGuard
|}

Click '''Save''' and '''Apply Changes'''.

== Step 8: Add Routing Between Sites ==

=== HQ-FW1 Static Route ===

Navigate to '''System → Routing → Static Routes''' and click '''+Add''':
* Destination Network: 172.18.1.0/24
* Gateway: VPN_BRANCHGW

=== Branch-FW Static Route ===

Navigate to '''System → Routing → Static Routes''' and click '''+Add''':
* Destination Network: 172.17.1.0/24
* Gateway: VPN_HQGW

== Step 9: Allow Tunnel Traffic ==

=== HQ-FW1 Tunnel Rule ===

On HQ-FW1, navigate to '''Firewall → Rules → BRANCH_VPN''' and add:

{| class="wikitable"
|-
! Setting !! Value
|-
| Action || Pass
|-
| Interface || BRANCH_VPN
|-
| Protocol || Any
|-
| Source || Any
|-
| Destination || Any
|-
| Description || Allow WireGuard VPN Traffic
|}

=== Branch-FW Tunnel Rule ===

On Branch-FW, navigate to '''Firewall → Rules → HQ_VPN''' and add the same rule (Interface: HQ_VPN).

== Step 10: Testing ==

WireGuard doesn’t have much status information. In most cases it either works if you configured it properly, or it does not. One place to look is for the existence of a recent “handshake.”

=== Check Status ===

On each firewall, navigate to '''VPN → WireGuard → Status'''. One of the only indicators that the VPN is up is the presence of the peer’s handshake.

=== Try to Ping Across ===

From the HQ-Client, try to ping the Branch-FW LAN interface at '''172.18.1.1'''. If the tunnel is up, your pings should be successful.

If the pings failed, you have a configuration issue and need to check your configuration.

== Troubleshooting ==

Due to its stateless nature, WireGuard doesn’t have status screens, and there is very little logging to be consulted. If your tunnel fails:

* Check the peer settings on both sides, paying particular attention to the public keys of the far-end peers
* Check for an active WireGuard state by navigating to '''Diagnostics → States''' and searching for a state that matches port 51820

The existence of this state can indicate that the VPN is connected. This state may age out, so you may need to try your ping again to bring it back up.

Once you are satisfied that WireGuard is working, you may delete it in order to simplify the next labs.

== Next Module ==
* [[Training: WireGuard|← Back to Training: WireGuard]]

----
<small>'''Source:''' Netgate pfSense Training — FUND001-LIVE-Lab7-WireGuard.pdf (© 2015-2021 Electric Sheep Fencing LLC)</small>

Training: WireGuard

2026-04-23T07:09:24Z

Justinaquino: Created page with "__NOTOC__ <div style="background:#e7f3ff;border:1px solid #a3c6ff;padding:10px;margin-bottom:15px;"> '''Training Module: WireGuard (Section 7)''' — pfSense Plus Fundamentals and Practical Application </div> == Introduction == WireGuard is a very new VPN technology that is entirely stateless. * Tends to be very performant * Lives in the kernel space * Uses “Crypto-Key Routing” * Ensures routing traffic to correct destination * Very little status info — it work..."

__NOTOC__

<div style="background:#e7f3ff;border:1px solid #a3c6ff;padding:10px;margin-bottom:15px;">
'''Training Module: WireGuard (Section 7)''' — pfSense Plus Fundamentals and Practical Application
</div>

== Introduction ==

WireGuard is a very new VPN technology that is entirely stateless.

* Tends to be very performant
* Lives in the kernel space
* Uses “Crypto-Key Routing”
* Ensures routing traffic to correct destination
* Very little status info — it works or it doesn’t
* Easy roaming between networks
* Endpoint IP always updated
* Configuration may be more time-consuming

== Simplified Codebase ==

WireGuard has a dramatically smaller codebase compared to traditional VPN solutions:

{| class="wikitable"
|-
! Protocol !! Lines of Code
|-
| IPsec || ~ 400,000
|-
| OpenVPN || ~ 600,000
|-
| '''WireGuard''' || '''~ 4,000'''
|}

Less Code = Greater Efficiency

== Rigid Crypto Protocols ==

WireGuard uses modern, rigidly defined cryptographic protocols:

* '''ChaCha20''' for symmetric encryption, authenticated with '''Poly1305'''
* '''Curve25519''' for ECDH
* '''BLAKE2s''' for hashing and keyed hashing
* '''SipHash24''' for hashtable keys
* '''HKDF''' for key derivation

== Site-to-Site ==

WireGuard creates a local wg0 interface. Peers have their own public & private keys.

* Exchange public key with peers
* Crypto-key routing — looks up peer wg0 address and public key
* Forwards traffic out local wg0 interface to peer

== Local Setup ==

Some assembly required:

# Activate the service
# Give wg0 a local IP/mask
# Generate Public/Private keys
# Assign wg0 to an OPT interface
# Create a gateway
# Open WG port on firewall
# Create firewall rules to allow traffic

== Peer Setup ==

Required information for peer configuration:

* Peer’s initial end-point IP
* Peer’s public key
* Peer’s wg0 IP (typically same as allowed IPs)

Assuming peer’s firewall is setup, try ping!

== Summary ==

* WireGuard is completely stateless
* Updated crypto protocols
* Uses crypto-key routing — routing table not a factor
* Requires its own OPT interface and gateway
* Very limited status information
* '''It works, or it doesn’t'''

== Next Module ==
* [[Training Lab 7: WireGuard|Lab 7: WireGuard — Site-to-Site VPN Configuration]]

----
<small>'''Source:''' Netgate pfSense Training — FUND001-LIVE-SLIDE-SEG7-WG.pdf (© 2017 Rubicon Communications dba Netgate)</small>

Training Lab 6: OpenVPN

2026-04-23T07:08:32Z

Justinaquino: Automated upload of Netgate pfSense training content

__NOTOC__

<div style="background:#e7f3ff; border-left:6px solid #2196F3; padding:10px; margin-bottom:15px;">
'''Training Lab 6: OpenVPN'''<br/>
Hands-on lab covering site-to-site SSL/TLS VPN, remote access VPN, certificate infrastructure, and testing in pfSense.
</div>

== Overview ==

This lab goes through example configurations of OpenVPN for site-to-site and remote access.

== OpenVPN SSL/TLS Site-to-Site VPN ==

We’re going to configure OpenVPN to connect the HQ and branch networks. HQ will run the server, and the branch will be the client.

There is no functional difference in whether HQ or branch runs the server side. Most often people put the server instances on the main location’s end. If one end has a dynamic IP and one static, run the server on the static IP side. If one end is behind NAT, that end should be the client. In this case, the server side will be on the fw1-hq firewall.

=== Delete IPsec ===

First, since we have an IPsec VPN configured here already, IPsec needs to be disabled. On both fw1-HQ and fw1-branch, browse to '''VPN > IPsec'''. Put a check mark by each IPsec tunnel and click '''Delete P1s'''. Click '''Save''', then '''Apply Changes'''.

=== Create the Certificate Infrastructure ===

OpenVPN makes use of a certificate infrastructure in authenticating the session as well as routing traffic to and from member sites. On the server we must create a new Certificate Authority (CA), as well as server and client certificate/key pairs. This will be done on fw1-hq.

==== Create the Certificate Authority (CA) ====

Navigate to '''System > Cert Manager''' and click the green '''+Add''' button to add a new CA.

{| class="wikitable"
! Field !! Value
|-
| Descriptive Name || S2SCA
|-
| Method || Create an Internal Certificate Authority
|-
| Randomize Serial || (checked)
|-
| Key Type || RSA 2048
|-
| Digest Algorithm || sha256
|-
| Lifetime || 3650
|-
| Common Name || S2SCA
|}

(Leave the rest blank and click '''Save'''.)

==== Create the Server Certificate ====

Next, click on the '''Certificates''' tab, and click the green '''+Add/Sign''' button near the bottom.

{| class="wikitable"
! Field !! Value
|-
| Method || Create an internal server certificate
|-
| Descriptive Name || VPNserver
|-
| Certificate Authority || S2SCA
|-
| Key Type || RSA 2048
|-
| Digest Algorithm || sha256
|-
| Lifetime || 398
|-
| Common Name || VPNserver
|-
| Certificate Type || Server Certificate
|}

Scroll down and click '''Save'''.

==== Create the Client Certificate ====

While still on the '''Certificates''' tab, click the green '''+Add/Sign''' button near the bottom to create the client certificate.

{| class="wikitable"
! Field !! Value
|-
| Method || Create an internal certificate
|-
| Descriptive Name || VPNclient
|-
| Certificate Authority || S2SCA
|-
| Key Type || RSA 2048
|-
| Digest Algorithm || sha256
|-
| Lifetime || 3650
|-
| Common Name || VPNclient
|-
| Certificate Type || User Certificate
|}

Scroll down and click '''Save'''.

==== Export Certificates and Keys ====

The next task is to export the certificates and keys which the client requires when connecting to the OpenVPN server.

# Navigate to '''System > Cert Manager > CAs''' and find the S2SCA. Click the export button to save the CA certificate to the downloads folder on HQ-Client.
# Next, click on the '''Certificates''' tab and scroll down until you see the VPNclient certificate entry. Click the export button to save the certificate data and the key data to the Downloads folder on HQ-Client.

=== Configure Server on fw1-HQ ===

Browse to '''VPN > OpenVPN''' on fw1-HQ. On the '''Server''' tab, click '''+Add''' to add a new server instance.

{| class="wikitable"
! Field !! Value
|-
| Server Mode || Peer to Peer (SSL/TLS)
|-
| Description || HQ to Branch VPN
|-
| TLS Configuration || (checked)
|-
| Automatically generate TLS key || (checked)
|-
| Peer Certificate Authority || S2SCA
|-
| Server Certificate || VPNserver
|-
| IPv4 Tunnel Network || 172.17.6.0/24
|-
| IPv4 Local Network(s) || 172.17.1.0/24, 172.17.2.0/24, 172.18.1.0/24
|-
| IPv4 Remote Network(s) || 172.18.1.0/24
|-
| Inactive || 0 (connections can stay up indefinitely)
|}

Click '''Save''' at the bottom, then click the edit icon to edit the server you just created. Highlight and copy the entire contents of the '''TLS Key''' box. Paste it into a file called '''TLS.key'''.

This TLS key will be needed on the client side of the connection.

=== Create Client-Specific Overrides ===

The purpose of the Client-Specific Override (CSO) is to tie a client’s subnet to their certificate. Navigate to '''VPN > OpenVPN''' and click the '''Client Specific Overrides''' tab. Click the green '''+Add''' button.

{| class="wikitable"
! Field !! Value
|-
| Server List || HQ to Branch VPN
|-
| Common Name || VPNclient
|-
| IPv4 Remote Network || 172.18.1.0/24
|}

Leave everything else blank or default, scroll down and click '''Save'''.

=== Permit Traffic to Server ===

Now we need to add a firewall rule to permit the outside portion of the VPN, from the client to the server. On fw1-HQ, browse to '''Firewall > Rules > WAN'''. Click '''Add'''.

{| class="wikitable"
! Field !! Value
|-
| Action || Pass
|-
| Interface || WAN
|-
| Protocol || UDP
|-
| Source || 203.0.113.10
|-
| Source port || any
|-
| Destination || WAN address
|-
| Destination port || 1194
|-
| Description || allow branch OpenVPN site to site
|}

Then click '''Save''' and '''Apply Changes'''.

=== Permit Traffic within VPN ===

Traffic within OpenVPN connections is filtered by the firewall rules on the OpenVPN tab. Browse to '''Firewall > Rules > OpenVPN'''. Click '''Add'''.

{| class="wikitable"
! Field !! Value
|-
| Interface || OpenVPN
|-
| Protocol || Any
|-
| Source || Network, 172.18.0.0/16
|-
| Destination || any
|-
| Description || allow branch network
|}

Click '''Save''' and '''Apply Changes'''.

The server-side configuration is now complete.

=== Configure Client on fw1-branch ===

Before we can create the client side of the VPN, we must first import the CA and Client Certificate and Keys into the fw1-branch firewall.

==== Import the CA Certificate ====

Click on '''System > Cert Manager''' and click the green '''+Add''' button.

{| class="wikitable"
! Field !! Value
|-
| Descriptive Name || S2SCA
|-
| Method || Import an existing Certificate Authority
|-
| Certificate Data || Paste contents of S2SCA.crt
|}

Highlight all the contents of the '''S2SCA.crt''' file, and paste it into the '''Certificate Data''' field on fw1-branch, and click '''Save'''.

==== Import the Client Certificate and Key ====

Click on the '''Certificates''' tab and click the green '''+Add/Sign''' button near the bottom to import your Client Certificate.

{| class="wikitable"
! Field !! Value
|-
| Method || Import an existing certificate
|-
| Descriptive Name || VPNclient
|-
| Certificate Data || Paste contents of VPNclient.crt
|-
| Certificate Key || Paste contents of VPNclient.key
|}

Click '''Save'''.

==== Create the OpenVPN Client ====

Navigate to '''VPN > OpenVPN''' and click on the '''Clients''' tab. Click the green '''+Add''' button.

{| class="wikitable"
! Field !! Value
|-
| Server Mode || Peer to Peer (SSL/TLS)
|-
| Device Mode || tun
|-
| Server host or address || 192.0.2.2
|-
| Description || Branch to HQ VPN
|-
| Automatically generate a TLS key || UNCHECKED
|-
| Peer Certificate Authority || S2SCA
|-
| Client Certificate || VPNclient
|}

(Here, you will edit the OpenVPN server configuration on fw1-hq, and copy the TLS key data from that server configuration into this client’s TLS key box. You may have saved this file on your HQ-Client as '''TLS.key'''.)

Scroll down and click '''Save'''.

==== Permit Traffic within VPN ====

Add a firewall rule to permit traffic within the VPN, same as the other side but changing the source to HQ’s 172.17.0.0/16.

{| class="wikitable"
! Field !! Value
|-
| Action || Pass
|-
| Interface || OpenVPN
|-
| Protocol || Any
|-
| Source || 172.17.0.0/16
|-
| Destination || any
|-
| Description || Allow HQ
|}

'''Save''' and '''Apply Changes'''.

=== Check Status and Test ===

On fw1-branch, browse to '''Status > OpenVPN'''. There you should see the status as up. If not, skip to the troubleshooting section.

'''Testing:'''

From HQ-client, try to ping fw1-branch and branch-client:

<pre>
training@hq-client:~$ ping -c 3 172.18.1.1
PING 172.18.1.1 (172.18.1.1) 56(84) bytes of data.
64 bytes from 172.18.1.1: icmp_seq=1 ttl=63 time=2.40 ms
...
--- 172.18.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 2.406/3.841/4.843/1.043 ms

training@hq-client:~$ ping -c 3 172.18.1.100
PING 172.18.1.100 (172.18.1.100) 56(84) bytes of data.
64 bytes from 172.18.1.100: icmp_seq=1 ttl=62 time=4.26 ms
...
--- 172.18.1.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.783/4.309/4.877/0.447 ms
</pre>

Then from branch-client, try to ping HQ-client and server1:

<pre>
training@branch-client:~$ ping -c 3 172.17.1.100
PING 172.17.1.100 (172.17.1.100) 56(84) bytes of data.
64 bytes from 172.17.1.100: icmp_seq=1 ttl=62 time=3.73 ms
64 bytes from 172.17.1.100: icmp_seq=2 ttl=62 time=5.21 ms
64 bytes from 172.17.1.100: icmp_seq=3 ttl=62 time=5.14 ms
--- 172.17.1.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.730/4.698/5.219/0.685 ms

training@branch-client:~$ ping -c 3 172.17.2.10
PING 172.17.2.10 (172.17.2.10) 56(84) bytes of data.
64 bytes from 172.17.2.10: icmp_seq=1 ttl=62 time=4.02 ms
64 bytes from 172.17.2.10: icmp_seq=2 ttl=62 time=4.01 ms
64 bytes from 172.17.2.10: icmp_seq=3 ttl=62 time=5.19 ms
--- 172.17.2.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 4.011/4.408/5.192/0.554 ms
</pre>

You can also try browsing to server1 from branch-client: <code>http://172.17.2.10</code>

=== Troubleshooting ===

If the client side status doesn’t show as up, check the troubleshooting section of the OpenVPN chapter in the book for guidance. The most likely causes are an incorrect or missing firewall rule on the WAN of the server (port 1194 rule created above). Check fw1-HQ firewall logs for any blocks. If it’s not getting blocked, and connectivity between the sites works in general, something in the OpenVPN server or client configuration is the likely cause. Double check your configuration on both the client and server, and ensure the shared key was pasted over correctly.

== OpenVPN Remote Access VPN ==

In this section we’re going to set up an OpenVPN remote access server for remote mobile clients.

=== Server Setup Wizard ===

On fw1-HQ, browse to '''VPN > OpenVPN''', and click the '''Wizard''' tab.

=== Authentication Backend ===

Choose '''Local User Access''' and click '''Next'''.

=== Create New Certificate Authority ===

Fill in these values as desired. The locale information has no functional impact and generally isn’t visible anywhere unless you go looking for it.

=== Create New Server Certificate ===

Again, fill in these values as desired.

=== OpenVPN Server Configuration ===

Most things can be left at defaults here. The port must be changed, since we’re already using port 1194 for the site-to-site VPN server.

{| class="wikitable"
! Field !! Value
|-
| Local Port || 1195
|-
| Description || Remote Access VPN
|-
| Tunnel Network || 172.17.4.0/24
|-
| Local Network || 172.16.0.0/12
|-
| DNS Server 1 || 172.17.1.1
|}

Leave everything not listed above at defaults and click '''Next'''.

=== Firewall Rule Configuration ===

The last step of the wizard prompts whether you want to add a rule to allow traffic from clients to the OpenVPN server, and allow traffic inside the VPN from clients when connected. Check both boxes and click '''Next'''.

Click '''Finish''' on the last page.

=== Configuration Complete ===

The configuration is now complete. The last screen reminds you to install the OpenVPN Client Export package if you’d like to use it. It’s already pre-installed on this system to save time. Click '''Finish'''.

Browse to '''Firewall > Rules''' to see the rules added by the wizard. On the '''WAN''' tab, you’ll see the rule allowing traffic to reach the OpenVPN server instance. Then click the '''OpenVPN''' tab to see the rule added to permit traffic from the connected clients.

This may be overly-permissive for real world scenarios since it allows all traffic coming in via OpenVPN from any source to any destination. In a real world setup, you may need to restrict this rule.

=== Special Configuration for Older Clients ===

Although this is rarely necessary, some older OpenVPN clients, like the one installed on your remote-host, will require some extra configuration in the OpenVPN server. Click the '''Edit''' button under the Remote Access VPN, and scroll down to the bottom of the screen. Place this into the '''Custom Options''' box and Save:

<pre>
tls-version-min 1.0;
tls-cipher DEFAULT:@SECLEVEL=0
</pre>

=== User Setup ===

Users need a certificate from the RemoteVPNCA to connect. We’ll add a certificate to the '''vpntest''' account created during the IPsec lab. Browse to '''System > User Manager''', and edit the vpntest user. Then click the '''Add''' button next to '''User Certificate''' to create the certificate.

Choose method '''Create an internal certificate.''' Both '''Descriptive name''' and '''Common Name''' should be set to the username. The other fields can be left to defaults.

{| class="wikitable"
! Field !! Value
|-
| User || vpntest
|-
| Certificate Method || Create an internal certificate
|-
| Descriptive Name || vpntest
|-
| Common Name || vpntest
|}

Click '''Save'''. Back at the user edit screen, you’ll see the user’s certificate. Click '''Save''' to save the user changes.

=== Client Configuration ===

The OpenVPN Client Export utility eases the process of client configuration. It’s a package that comes pre-installed on the lab VMs, but will need to be installed under '''System > Packages''' on your other systems.

Browse to '''VPN > OpenVPN''', and click the '''Client Export''' tab.

For our lab purposes, all other settings can be left at their defaults. Scroll down to the bottom to find the vpntest user’s client export options.

For Windows systems, the Windows installer is what you’ll want. Choose x86 for 32 bit versions of Windows and x64 for 64 bit versions. The Viscosity bundle is for Windows or Mac OS X clients running the Viscosity client. The inline configuration options are most commonly used for iOS and Android clients.

The '''Standard Configuration''' Archive option downloads a zip containing the user’s certificate, TLS key for the server, and OpenVPN config file.

Here you will see the remote access server just created in the wizard. Because the RemoteHost’s VPN client is older, we need to scroll down the page and make sure to put a check mark on '''Legacy Client'''.

=== Testing ===

In this lab environment, the only machine that’s available in the circumstance of a typical client out on the Internet is the remote-host VM. First, add it to the '''RemoteAdmin''' alias on fw1-HQ so you can log into fw1-HQ from that host to ease getting the OpenVPN configuration onto the client. Browse to '''Firewall > Aliases''', and edit the RemoteAdmin alias. Add '''100.64.0.50/32''' to that alias, save, then apply changes.

Now connect with VNC to '''100.64.0.50''' (remote-host) to begin the client-side setup. Bring up its web browser and browse to '''https://192.0.2.2'''. Log in and browse to '''VPN > OpenVPN > Client Export''' tab. Export the '''Configuration Archive''' option for the vpntest user.

Make a folder called OpenVPN in your Documents folder, and save the zip file there. Right click the zip file and choose '''Extract Here'''.

Click the Network Manager icon → VPN Connections → Configure VPN.

Click '''Add''' and scroll down to '''Import a Saved Configuration'''.

Navigate to the folder where the OpenVPN configuration archive was extracted. Click on the '''.ovpn''' file and choose '''Open'''.

Fill in the username and password portions of the next screen, and click '''Save'''.

You may get prompted to choose a password for a new keyring. If so, just enter “password” in both blanks and click '''Continue''' and then '''Close'''.

Now connect to the OpenVPN server by clicking on the Network Manager → VPN Connections and choosing your VPN configuration.

Enter your password and click '''Ok'''.

Now you should verify you can reach things on the HQ LAN and DMZ networks. Try HQ-client at '''172.17.1.100''', server1 at '''172.17.2.10''' and server2 at '''172.17.2.20'''.

Once you have verified that the OpenVPN connection is functioning as expected, please disconnect the OpenVPN session on the remote host.

== Conclusion ==

This concludes Lab 6.

== Source Attribution ==

''Source: Netgate pfSense Training Material — FUND001-LIVE-Lab6-OpenVPN.pdf © 2021 Rubicon Communications, LLC (Netgate)''

Training: OpenVPN

2026-04-23T07:08:32Z

Justinaquino: Automated upload of Netgate pfSense training content

__NOTOC__

<div style="background:#e7f3ff; border-left:6px solid #2196F3; padding:10px; margin-bottom:15px;">
'''Training Module: OpenVPN (Section 6)'''<br/>
This page covers the fundamentals of OpenVPN in pfSense — intro, site-to-site, remote access, and the Client Export Utility.
</div>

== Introduction ==

OpenVPN is an SSL/TLS open source VPN solution.

* '''Not''' a browser-based SSL VPN
* Supports site-to-site and remote access
* Uses client and server roles
* Runs over TCP or UDP (UDP is preferable)
* Built on a client/server relationship

== Remote Access ==

The OpenVPN Wizard in pfSense takes all the guess-work out of configuration.

* Install the '''Client Export Utility'''
* Users will need a '''user certificate'''
* Simple status screen
* Log files for troubleshooting

== Site-to-Site ==

=== Server-Side Requirements ===

* Must have a publicly-reachable TCP or UDP port
* Static IP is preferred (dynamic DNS is possible)

=== Client-Side Requirements ===

* Only needs outbound Internet access
* Works behind NAT or firewall with no issue
* Setup is initiated by Client → Server
* Remarkably simple configuration

=== Important Changes ===

* Peer-to-Peer (Shared Key) mode is '''deprecated'''
* Peer-to-Peer (SSL/TLS) is the only supported mode moving forward
* This opens the door to new capabilities like '''DCO''' (Data Channel Offload)

=== Configuration Checklist ===

{| class="wikitable"
! colspan="2" | Server Information Needed
|-
| CA and Certificate Infrastructure || Required for trust
|-
| Server and Client Certificates || Authenticate both ends
|-
| Server Mode || Peer to Peer (SSL/TLS)
|-
| TLS Key || Automatically created
|-
| Tunnel Network || Subnet for the VPN tunnel
|-
| Local Network || Networks on the server side
|-
| Remote Network || Networks on the client side
|-
| Client-Specific Overrides || Tie client subnets to certificates
|-
| Firewall Rules || Don’t forget to allow traffic!
|}

{| class="wikitable"
! colspan="2" | Client Information Needed
|-
| CA and Certificate/Keys from server || Import the server's CA
|-
| Server Mode || Peer to Peer (SSL/TLS)
|-
| TLS Key || Copy from the server side
|-
| Server IP Address || Public address of the server
|-
| Peer CA || Same CA as server
|-
| Client Certificate/Key || Generated for this client
|-
| Firewall Rules || Don’t forget to allow traffic!
|}

== Section Summary ==

* Pay attention to crypto settings — they '''must agree''' on both sides
* Very simple setup
* Very tenacious — comes up and recovers quickly
* Routed VPN instead of policy-based
* Can co-exist with IPsec
* '''Cannot''' route the same networks! (Policy > Routed)
* Still need firewall rules to allow traffic to pass

== Next Module ==

→ Continue to '''[[Training_Lab_6:_OpenVPN|Lab 6: OpenVPN]]'''

== Source Attribution ==

''Source: Netgate pfSense Training Material — FUND001-LIVE-SLIDE-SEG6-OVPN.pdf © 2017 Rubicon Communications dba Netgate''

Training Lab 5: IPsec VPN

2026-04-23T07:07:12Z

Justinaquino: Imported from Netgate pfSense training PDF via bot

__NOTOC__

<div style="background-color: #fff3cd; border-left: 6px solid #ffc107; padding: 10px; margin-bottom: 15px;">
<strong>Netgate pfSense Plus Fundamentals — Lab 5: IPsec VPN</strong><br/>
Hands-on lab covering site-to-site IPsec with pre-shared key and mobile IPsec remote access configuration.
</div>

= Lab 5: IPsec =

In this lab, we connect the '''HQ''' and '''branch''' networks with a site-to-site IPsec VPN, then configure mobile IPsec to offer a remote access option for mobile clients.

'''Lab topology references:'''
* HQ WAN IP: '''192.0.2.2'''
* Branch WAN IP: '''203.0.113.10'''
* HQ network: 172.17.0.0/16
* Branch network: 172.18.0.0/16

= Part 1: IPsec Pre-Shared Key Site-to-Site VPN =

== Enable fw1-HQ IPsec ==

On '''fw1-HQ''', browse to '''VPN > IPsec'''. Click '''+Add P1''' to add a new Phase 1 configuration.

=== HQ Phase 1 Configuration ===

At the resulting Edit Phase 1 screen:
* '''Remote Gateway:''' Branch WAN IP (203.0.113.10)
* '''Interface:''' WAN
* '''Description:''' (your choice)

=== Phase 1 Proposal Configuration ===

Scroll down to the Phase 1 proposal configuration.

'''Generating Pre-Shared Key:'''
* Click the yellow button to generate your pre-shared key automatically
* Make note of it — it will be needed to configure the other end of the VPN

'''Advanced Options:'''
* Leave '''NAT Traversal''' to '''Auto'''
* The underlying strongSwan service will determine if NAT-T is required and automatically enable it if so

Leave the other settings at their defaults, then click '''Save'''.

== Adding HQ Phase 2 ==

Back at the IPsec Tunnels tab, click the '''+''' under the newly-created Phase 1 to expose the Phase 2 configuration, then click '''+Add P2'''.

=== Configuring HQ Phase 2 ===

For local and remote networks, use the /16 network summarizing all available IP subnets for each location:
* '''Local Network:''' Type: Network, '''172.17.0.0/16'''
* '''Remote Network:''' Type: Network, '''172.18.0.0/16'''

=== Phase 2 Proposal Configuration ===

Choose specific parameters for each area rather than having multiple options enabled. This is always best for site-to-site VPNs.

{| class="wikitable"
! Setting !! Recommendation
|-
| Encryption || AES-256 (single option)
|-
| Hash || SHA256 (single option)
|-
| PFS || On (match group)
|}

Having multiple options enabled could lead to a less secure, slower algorithm like 3DES being chosen over a faster, more secure option like AES-256.

=== Automatically Ping Host ===

Enter an IP address within the remote subnet to keep the VPN alive:
* Use '''fw1-branch LAN IP''' (e.g., 172.18.1.1)
* IPsec is "dial-on-demand" — it doesn't try to connect unless traffic is trying to traverse the VPN
* The IP doesn't have to reply; it's the initiation of the request that triggers the VPN to come up

Then click '''Save''', and at the main IPsec Tunnels screen click '''Apply Changes'''.

== Configure HQ IPsec Firewall Rules ==

Traffic coming in via IPsec is filtered by the firewall rules on the '''IPsec tab'''. By default, this contains no rules, so all VPN traffic will be blocked.

Browse to '''Firewall > Rules''', IPsec tab. Click '''Add''' and configure:

{| class="wikitable"
! Field !! Value
|-
| Action || Pass
|-
| Interface || IPsec
|-
| Protocol || any
|-
| Source || 172.18.0.0/16
|-
| Destination || any
|-
| Description || allow branch network in via IPsec
|}

Click '''Save''', and '''Apply Changes'''.

'''Notes:'''
* The outer portion of the VPN requires UDP port 500 and ESP protocol on WAN — these rules are handled automatically
* Traffic is allowed out from HQ to branch by the default LAN rule
* The HQ DMZ subnet will not be able to initiate connections to the remote branch network because of the DMZ rule rejecting private network destinations

== Configure fw1-branch IPsec ==

Browse to '''https://172.18.1.1''' to reach fw1-branch.

=== Add Phase 1 Entry ===

Add a new Phase 1 entry for the HQ VPN:
* '''Remote Gateway:''' fw1-HQ's WAN IP — '''192.0.2.2'''
* Match all other parameters exactly with fw1-HQ

=== Phase 1 Proposal and Advanced ===

All Phase 1 proposal settings must match exactly to fw1-HQ. After matching up everything, click '''Save'''.

=== Branch Phase 2 Configuration ===

Add a new Phase 2 entry under the Phase 1 just added. Everything is identical to HQ's Phase 2, except flip local and remote networks:
* '''Local Network:''' 172.18.0.0/16
* '''Remote Network:''' 172.17.0.0/16

Leave '''Automatically ping host''' blank on this side (the other end will keep the tunnel active).

Then click '''Save''', and '''Apply Changes'''.

=== Add IPsec Firewall Rule ===

Browse to '''Firewall > Rules''', IPsec tab, and add an allow-all rule:

{| class="wikitable"
! Field !! Value
|-
| Action || Pass
|-
| Interface || IPsec
|-
| Protocol || any
|-
| Source || Network, 172.17.0.0/16
|-
| Destination || any
|-
| Description || allow HQ in via VPN
|}

Save and Apply Changes.

== Testing the VPN ==

Browse to '''Status > IPsec''' on the branch firewall. If the status shows "Disconnected", click the '''Connect VPN''' button.

Once something attempts to bring up the VPN, it should change status to '''ESTABLISHED'''.

=== Troubleshooting ===

If the VPN does not come up:
* Closely review all settings in Phase 1 and Phase 2 on both sides
* Check for typos in IP addresses
* Verify the pre-shared key was pasted correctly
* Ensure no inadvertently mismatched settings

=== Passing Traffic Across VPN ===

On '''HQ-client''', test connectivity:
<pre>
training@hq-client:~$ ping -c 3 172.18.1.1
training@hq-client:~$ ping -c 3 172.18.1.100
</pre>

On '''branch-client''', ping back:
<pre>
training@branch-client:~$ ping -c 3 172.17.1.1
training@branch-client:~$ ping -c 3 172.17.1.100
training@branch-client:~$ ping -c 3 172.17.2.10
</pre>

You should also be able to browse to web servers in the HQ DMZ network from branch-client.

= Part 2: IPsec Remote Access VPN =

Next, configure IPsec for mobile clients. This works with any standard IPsec clients, specifically focused towards the Cisco IPsec clients built into Mac OS X and Apple iOS. The Shrew Soft client is used in this lab.

== User and Group Setup ==

IPsec remote-access users require the '''"IPsec xauth Dialin"''' privilege.

=== Add IPsec Mobile Group ===

On '''fw1-HQ''', browse to '''System > User Manager''', Groups tab. Click '''+Add''':
* Give the group a name (e.g., "Mobile_IPsec") and description
* Save
* Edit the group and under '''Assigned Privileges''', click '''Add'''
* Choose only the '''"VPN - IPsec xauth Dialin"''' privilege
* Save again

=== Creating User for VPN ===

Go to the Users tab, click '''+Add''':
* '''Username:''' vpntest
* '''Password:''' password
* '''Group:''' Mobile_IPsec
* Save

== Server Configuration ==

On '''fw1-HQ''', browse to '''VPN > IPsec''', click the '''Mobile clients''' tab:

{| class="wikitable"
! Setting !! Value
|-
| Enable IPsec Mobile Client Support || Checked
|-
| User Authentication || Local Database
|-
| Group Authentication || Checked
|-
| Authentication Groups || Rights for Mobile IPsec (Mobile_IPsec)
|-
| Virtual Address Pool || 172.17.5.0/24
|-
| Network List || Checked — "Provide a list of accessible networks to clients"
|-
| DNS Default Domain || example.com
|-
| DNS Servers || 172.17.1.1
|}

Leave all other fields at defaults and click '''Save'''.

== Phase 1 Creation ==

After saving, you will see a prompt to create a Phase 1 definition for mobile clients. Click '''Create Phase 1'''.

{| class="wikitable"
! Parameter !! Value
|-
| Key Exchange Version || IKEv1
|-
| Description || Mobile clients
|-
| Authentication Method || Mutual PSK + Xauth
|-
| My Identifier || My IP address
|-
| Peer Identifier || User distinguished name, vpn@example.com
|-
| Pre-Shared Key || Generate new (make note)
|-
| Encryption Algorithm || AES 128 bit
|-
| Hash Algorithm || SHA1
|-
| DH Group || 2
|-
| Lifetime || 86400
|-
| NAT Traversal || Force
|}

Leave all else at defaults, and click '''Save'''.

== Configure Phase 2 ==

Back at the IPsec Tunnels screen, expand the mobile Phase 1 and click '''+Add P2''':

{| class="wikitable"
! Parameter !! Value
|-
| Mode || Tunnel IPv4
|-
| Local Network || Type: Network, 0.0.0.0/0
|-
| Encryption || AES 128
|-
| Hash || SHA1
|-
| PFS || off
|-
| Lifetime || 28800
|}

'''Note:''' The Phase 2 "Local Network" determines what networks are sent to the client. '''0.0.0.0/0''' sends all traffic across the VPN. To send only internal traffic, use '''172.17.0.0/16''' or '''172.16.0.0/12'''.

Then click '''Save''', and '''Apply Changes'''. The server-side IPsec configuration is now complete.

== Firewall Rule Configuration ==

Browse to '''Firewall > Rules''', IPsec tab. Add a new rule:

{| class="wikitable"
! Field !! Value
|-
| Action || Pass
|-
| Interface || IPsec
|-
| Protocol || Any
|-
| Source || Network 172.17.5.0/24
|-
| Destination || any
|-
| Description || allow in mobile client IPsec
|}

Then Save and Apply Changes.

== Client Configuration ==

On '''remote-host''', launch '''Shrew Soft VPN Access Manager'''. Click '''Add''' to create a new configuration.

=== General Tab ===
* Fill in the WAN IP of fw1-HQ: '''192.0.2.2'''
* Leave all else at defaults

=== Authentication Tab ===
* '''Authentication Method:''' Mutual PSK + XAuth
* '''Local Identity:''' User Fully Qualified Domain Name — '''vpn@example.com'''

=== Remote Identity Tab ===
* Choose '''Identification type:''' IP address

=== Credentials Tab ===
* Enter or paste the PSK generated during Phase 1 creation

=== Phase 1 Tab ===
* Change '''DH Exchange''' to '''group 2'''
* Leave all else at defaults

=== Phase 2 Tab ===
* Set '''Lifetime''' to '''28800''' seconds
* Leave everything else at defaults

Then click '''Save'''. You can rename the connection (e.g., "HQ VPN").

== Testing ==

Select the connection and click '''Connect'''. Fill in:
* '''Username:''' vpntest
* '''Password:''' password

Then click '''Connect'''. If you see "tunnel enabled" as the last line in the status, it's connected successfully.

Try to ping across to HQ-client (172.17.1.100) and server1 (172.17.2.10).

This concludes the IPsec lab.

= Next Module =

* [[Training:_IPsec_VPN|Section 5: IPsec VPN Concepts]] (review)

= Source Attribution =

* '''Document:''' FUND001-LIVE-Lab5-IPsec.pdf
* '''Course:''' pfSense Plus Fundamentals and Practical Application
* '''Copyright:''' © 2021 Rubicon Communications, LLC (Netgate)
* '''Extracted:''' 2026-04-23 via pdftotext

Training: IPsec VPN

2026-04-23T07:07:11Z

Justinaquino: Imported from Netgate pfSense training PDF via bot

__NOTOC__

<div style="background-color: #e7f3fe; border-left: 6px solid #2196F3; padding: 10px; margin-bottom: 15px;">
<strong>Netgate pfSense Plus Fundamentals — Section 5: VPNs and IPsec</strong><br/>
This page covers VPN concepts, IPsec remote access, site-to-site configurations, and IKE phase negotiations.
</div>

= VPNs and IPsec =

== VPNs — Remote Access ==

Remote access VPNs provide connectivity for mobile or remote users, enabling secure tunneling over untrusted networks.

'''Use cases:'''
* Tunneling for access or performance reasons
* Additional wireless protection

'''Available options:'''
{| class="wikitable"
! Option !! Best For
|-
| IPsec || Built-in clients (OS X, iOS, Android)
|-
| OpenVPN || Ease of client configuration
|-
| WireGuard || Good performance for simple setup
|}

The best option is largely a matter of '''personal preference''' and the specific client ecosystem in use.

== VPNs — Site to Site ==

Site-to-site VPNs provide a permanent connection between networks, commonly used for:
* Multiple company offices or data centers
* Service providers
* Partners

'''Available options:'''
{| class="wikitable"
! Option !! Best For
|-
| IPsec || Widely interoperable
|-
| OpenVPN || Client behind NAT
|-
| WireGuard || Client behind NAT, modern crypto
|}

Again, the best option depends on personal preference and a weighing of strengths and weaknesses. If a client is behind NAT, OpenVPN or WireGuard may be preferable. For wide interoperability, IPsec is the standard.

= About IPsec =

IPsec is a widely interoperable VPN protocol that typically offers higher performance than most alternatives.

'''Key characteristics:'''
* Peer-to-peer relationship
* Typically '''policy-based''' (but can be '''VTI / route-based''')
* '''Phase 1''' protects IKE messages between peers
* '''Phase 2''' protects IP traffic between endpoints
* Establishes a '''Security Association (SA)''' between networks
* The SA determines which traffic traverses the tunnel

== IPsec Phase 1 ==

Phase 1 protects IKE messages between peers.

'''Key points:'''
* Peers are typically a single IP address
* Encryption and authentication protocols are required
* Common example: '''AES-256 / SHA256'''
* Provides a secure path for Phase 2 negotiation

{| class="wikitable"
! Parameter !! Typical Value
|-
| Encryption || AES-256
|-
| Authentication || SHA256
|-
| DH Group || 14 (2048-bit) or higher
|}

== IPsec Phase 2 ==

Phase 2 protects IP traffic between endpoints.

'''Key points:'''
* Security Association is formed between networks
* Encryption is optional for Phase 2 traffic — but strongly recommended
* Authentication method is still required

= IPsec — How It Looks =

Conceptually, IPsec creates an encrypted tunnel between two peer gateways:

<pre>
[Network A] --- [Gateway A] ====== encrypted tunnel ====== [Gateway B] --- [Network B]
↑ ↑
Phase 1 (IKE) Phase 1 (IKE)
Phase 2 (ESP/AH) Phase 2 (ESP/AH)
</pre>

= Section 5 Summary =

{| class="wikitable"
! Point !! Detail
|-
| Style || Peer-to-peer VPN
|-
| Routing || Can be policy-based or route-based (VTI)
|-
| Routing table || Not considered if policy-based
|-
| Agreement || As long as both sides agree, the tunnel will come up
|-
| Firewall || Still need a firewall rule to allow tunnel traffic
|-
| Performance || Consider taking advantage of AES-NI for performance
|}

= Next Module =

* [[Training_Lab_5:_IPsec_VPN|Lab 5: IPsec VPN Hands-On]]

= Source Attribution =

* '''Document:''' FUND001-LIVE-SLIDE-SEG5-IPSEC.pdf
* '''Course:''' pfSense Plus Fundamentals and Practical Application
* '''Copyright:''' © 2017 Rubicon Communications, LLC dba Netgate
* '''Extracted:''' 2026-04-23 via pdftotext

Training Lab 10: High Availability

2026-04-23T07:07:10Z

Justinaquino: Created from Netgate pfSense training PDF

__NOTOC__
<div style="background:#003366; color:#ffffff; padding:10px; border-radius:5px; margin-bottom:15px;">
'''Netgate pfSense Plus Fundamentals — Lab 10: High Availability'''
</div>

== Overview ==

In this lab, we add high availability at HQ by configuring a secondary firewall ('''fw2-HQ''') to operate as the backup in an active/passive HA pair.

== Configuring fw2-HQ ==

From your machine or HQ-client, log into fw2-HQ at '''https://172.17.1.3'''.

=== Interface Assignment ===

On fw2-HQ, browse to '''Interfaces > Assign''' and verify that your 5 interfaces are assigned correctly.

=== Interface Configuration ===

==== WAN ====

{| class="wikitable"
! Setting !! Value
|-
| Description || WAN
|-
| IPv4 Configuration Type || Static IPv4
|-
| IPv4 Address || 192.0.2.3/24
|-
| Gateway || GW_WAN — 192.0.2.1 (default gateway)
|}

Then Save and Apply Changes.

==== DMZ ====

{| class="wikitable"
! Setting !! Value
|-
| Description || DMZ
|-
| IPv4 Configuration Type || Static IPv4
|-
| IPv4 Address || 172.17.2.3/24
|}

Save and Apply Changes.

==== WAN2 ====

{| class="wikitable"
! Setting !! Value
|-
| Description || WAN2
|-
| IPv4 Configuration Type || Static IPv4
|-
| IPv4 Address || 198.51.100.3/24
|-
| Gateway || GW_WAN2 — 198.51.100.1 (not default gateway)
|}

Save and Apply Changes.

==== SYNC ====

{| class="wikitable"
! Setting !! Value
|-
| Description || SYNC
|-
| IPv4 Configuration Type || Static IPv4
|-
| IPv4 Address || 172.17.3.3/24
|}

Save and Apply Changes.

=== HA Sync Configuration (fw2-HQ) ===

Browse to '''System > High Avail Sync'''. Only the top portion is configured on the secondary, enabling it to send and receive state synchronization traffic.

* Check '''Synchronize States'''
* Choose '''Synchronize Interface''' = SYNC
* '''pfsync Synchronize Peer IP''': 172.17.3.2

Then click Save at the very bottom of the page.

=== Increase FW2 GUI Processes ===

Navigate to '''System > Advanced''' and change '''Max Processes''' from the default 2 to '''5''', to account for the extra work of sync and configuration.

=== Firewall Rule Configuration (fw2-HQ) ===

Browse to '''Firewall > Rules''', SYNC tab, and click Add to allow the initial config sync:

{| class="wikitable"
! Setting !! Value
|-
| Action || Pass
|-
| Interface || SYNC
|-
| Protocol || any
|-
| Source || any
|-
| Destination || any
|}

Then Save and Apply Changes.

fw2-HQ is now ready.

== Configuring fw1-HQ ==

Switch over to fw1-HQ to continue the configuration.

=== Assign and Configure Sync Interface ===

Browse to '''Interfaces > Assign''' and verify the SYNC interface is assigned.

Browse to '''Interfaces > OPT3''' and configure:

{| class="wikitable"
! Setting !! Value
|-
| Enable || checked
|-
| Description || SYNC
|-
| IPv4 Configuration Type || Static IPv4
|-
| IPv4 Address || 172.17.3.2/24
|}

Save and Apply Changes.

=== Add Sync Firewall Rules (fw1-HQ) ===

Browse to '''Firewall > Rules''', Sync tab. Add:

{| class="wikitable"
! Setting !! Value
|-
| Action || Pass
|-
| Interface || Sync
|-
| Protocol || any
|-
| Source || any
|-
| Destination || any
|-
| Description || allow sync
|}

Save and apply changes.

=== Change Interface IPs (fw1-HQ) ===

The gateway IPs on the internal interfaces need to be CARP IPs so they fail over. Change the LAN and DMZ interface IPs:

* '''LAN''': change from 172.17.1.1 to '''172.17.1.2'''
* '''DMZ''': change from 172.17.2.1 to '''172.17.2.2'''

The .1 IPs will be added back as CARP IPs in the next step. Save and apply changes after each interface.

=== Add CARP VIPs (fw1-HQ) ===

Browse to '''Firewall > Virtual IPs''', and click '''+Add'''.

==== LAN CARP VIP ====

{| class="wikitable"
! Setting !! Value
|-
| Type || CARP
|-
| Interface || LAN
|-
| IP Address || 172.17.1.1/24
|-
| Virtual IP Password || random characters (syncs automatically)
|}

Leave the remainder at defaults. Save and Apply Changes.

==== DMZ CARP VIP ====

{| class="wikitable"
! Setting !! Value
|-
| Type || CARP
|-
| Interface || DMZ
|-
| IP Address || 172.17.2.1/24
|-
| Virtual IP Password || random string
|}

Note the VHID group increments to 2. Save and apply changes.

=== Edit Existing WAN VIPs (fw1-HQ) ===

==== WAN .4 VIP ====

Edit 192.0.2.4: change type from IP Alias to CARP, subnet mask /24, VHID Group 3, random Virtual IP Password. Save.

==== WAN .5 and .6 VIPs ====

Edit 192.0.2.5 and 192.0.2.6: keep as IP Alias but change parent interface to the WAN CARP IP (192.0.2.4). Save and apply changes.

==== WAN2 CARP VIPs ====

Change 198.51.100.4 to CARP, and change the interface of 198.51.100.5 and .6 to 198.51.100.4.

=== Configure HA Sync (fw1-HQ) ===

Browse to '''System > High Avail. Sync''':

{| class="wikitable"
! Setting !! Value
|-
| Synchronize States || checked
|-
| Synchronize Interface || SYNC
|-
| pfsync Synchronize Peer IP || 172.17.3.3
|-
| Synchronize Config to IP || 172.17.3.3
|-
| Remote System Username || admin
|-
| Remote System Password || pfsense
|}

Click '''toggle all''' to check all synchronize configuration boxes, then click Save.

Configuration and state synchronization are now fully enabled. Do not make config changes directly on the secondary from here out, as they’ll be overwritten by the primary.

=== Configure Outbound NAT ===

Browse to '''Firewall > NAT''', Outbound tab. Edit rules so traffic is NATed to IPs that fail over:

* Edit "HQ 172.17./16 out via WAN IP" — change Translation to '''192.0.2.6'''
* Edit "HQ 172.17./16 out via WAN2 IP" — change Translation to '''198.51.100.6'''

=== Configure LAN DHCP ===

Browse to '''Services > DHCP Server''', LAN tab:

* Set default gateway to the LAN CARP VIP '''172.17.1.1'''
* Set '''Failover Peer IP''' to fw2-HQ LAN IP '''172.17.1.3'''
* Save

== Check Status ==

Browse to '''Status > CARP''' on both fw1-HQ and fw2-HQ. All CARP IPs should show:
* '''master''' status on fw1-HQ
* '''backup''' status on fw2-HQ

== Testing Failover ==

=== Force Failover by Disabling CARP on Primary ===

On fw1-HQ, browse to '''Status > CARP''' and click '''Temporarily Disable CARP'''. After reload, all CARP IPs change to "disabled." Check fw2-HQ — they should all show master status.

=== Force Failover by Simulating Power Removal ===

Navigate to '''Diagnostics > Halt System''' and click '''Reboot''' on the primary. Within a second after rebooting, fw2-HQ should show master status on all CARP IPs. After fw1-HQ reboots, it will regain master status automatically.

<div style="background:#e6f2ff; padding:10px; border-left:4px solid #003366; margin-top:15px;">
'''Previous Module:''' [[Training: High Availability|Training: High Availability — HA Overview and Concepts]]
</div>

== Source Attribution ==

* ''Netgate pfSense Plus Fundamentals and Practical Application''
* © 2021 Rubicon Communications, LLC (Netgate)
* Source PDF: FUND001-LIVE-Lab10-HA.pdf
* Reference fw2-HQ IPs: WAN 192.0.2.3, LAN 172.17.1.3, DMZ 172.17.2.3

Training: High Availability

2026-04-23T07:07:10Z

Justinaquino: Created from Netgate pfSense training PDF

__NOTOC__
<div style="background:#003366; color:#ffffff; padding:10px; border-radius:5px; margin-bottom:15px;">
'''Netgate pfSense Plus Fundamentals — Section 10: High Availability'''
</div>

== Overview ==

High Availability (HA) in pfSense uses an '''active/passive pair''' of firewalls to provide hardware redundancy. This architecture offers:

* Increased redundancy options
* Less painful upgrades
* Seamless failover capabilities

HA relies on '''three separate functions''' working together:

{| class="wikitable"
! Function !! Purpose
|-
| '''CARP''' || Provides redundant IP addresses (Virtual IPs) shared between HA members
|-
| '''pfSync''' || Synchronizes the state table between HA members for seamless failover
|-
| '''XMLRPC''' || Synchronizes configuration from the primary to secondary firewalls
|}

== CARP (Common Address Redundancy Protocol) ==

* Uses multicast for announcements
* Every CARP VIP has a unique '''VHID''' (Virtual Host ID)
* CARP VIP is shared between VHID members
* VHID groups are password protected
* At least '''3 public IPs required''' per WAN
* WAN needs at least a '''/29''' subnet

== pfSync ==

* Syncs state table between the two HA members
* Enables seamless failover during an outage
* Can use multicast or unicast for updates
* No authentication for updates
* '''Likes a dedicated interface''' (recommended)

== XMLRPC (Configuration Sync) ==

* Syncs configuration between HA members
* Syncs from primary to secondaries
* Only need to configure one firewall
* May not sync everything — '''packages are responsible for their own config sync'''

== CARP Configuration Requirements ==

* At least one CARP VIP on WAN
* At least one CARP VIP on LAN
* Manual Outbound NAT to CARP VIP
* DHCP adjustments needed (use CARP VIP as default gateway)

== Typical Topology ==

=== Single WAN ===
<pre>
ISP1
|
[ HA Pair ] — LAN
</pre>

=== Multi-WAN ===
<pre>
ISP1 ISP2
| |
[ HA Pair ] — LAN
</pre>

== Common Failures ==

* '''Dual master''' on CARP VIPs
* Loss of active connections on failover
* Loss of connectivity on failover

== Section 10 Summary ==

* Active/Passive pair
* Will need at least '''/29''' of network space per WAN
* Use a '''unique VHID''' for every CARP VIP
* Use a '''separate private interface''' for pfSync data
* Packages are responsible for their own config sync
* Outbound NAT to CARP VIP
* DHCP adjusted for CARP VIP as default gateway

<div style="background:#e6f2ff; padding:10px; border-left:4px solid #003366; margin-top:15px;">
'''Next Module:''' [[Training Lab 10: High Availability|Training Lab 10: High Availability — Hands-on Configuration and Failover Testing]]
</div>

== Source Attribution ==

* ''Netgate pfSense Plus Fundamentals and Practical Application''
* © 2017–2021 Rubicon Communications, LLC (Netgate)
* Source PDF: FUND001-LIVE-SLIDE-SEG10-HA.pdf

Training Lab 8: Multi-WAN

2026-04-23T07:06:59Z

Justinaquino: Created page with "__NOTOC__ <div style="background:#fff3e6;border:1px solid #ff9900;padding:10px;margin-bottom:15px;"> '''Netgate pfSense Plus Fundamentals — Lab 8: Multi-WAN'''<br/> <i>Adding WAN2, configuring gateway groups, failover, failback, firewall rules, NAT, and testing.</i> </div> This lab covers adding a second WAN interface to HQ, configuring the interface, gateway groups, firewall rules, NAT and related topics for multi-WAN, then testing its failover and failback. == Con..."

__NOTOC__

<div style="background:#fff3e6;border:1px solid #ff9900;padding:10px;margin-bottom:15px;">
'''Netgate pfSense Plus Fundamentals — Lab 8: Multi-WAN'''<br/>
<i>Adding WAN2, configuring gateway groups, failover, failback, firewall rules, NAT, and testing.</i>
</div>

This lab covers adding a second WAN interface to HQ, configuring the interface, gateway groups, firewall rules, NAT and related topics for multi-WAN, then testing its failover and failback.

== Configuring WAN2 Interface ==

=== Adding the WAN2 Interface ===

Browse to '''Interfaces > Assign''', and verify that your OPT2 interface is assigned to vtnet3. Browse to '''Interfaces > OPT2'''. Configure the interface as follows:

{| class="wikitable"
! Setting !! Value
|-
| Enable || check
|-
| Description || WAN2
|-
| IPv4 Type || Static
|-
| IPv4 Address || 198.51.100.2/24
|-
| Gateway || add new
|-
| — Name || GW_WAN2
|-
| — IP || 198.51.100.1
|}

Save and Apply Changes.

=== Verifying WAN2 Connectivity ===

After adding a new WAN, the fastest way to verify it’s online is by browsing to '''Status > Gateways'''. It should show green and online there. To verify Internet connectivity, browse to '''Diagnostics > Ping'''. Enter any Internet host that replies to pings in the “Host” box (such as google.com), choose Source Address '''WAN2''', and click Ping. You should receive replies.

== Configuring DNS Servers ==

At least one DNS server must be reachable via each WAN so a single connection's failure doesn't result in DNS failing.

* In a production environment, at least one DNS server should be assigned to each WAN.
* In this lab network, DNS servers are local to the WAN and WAN2 networks, so we will not assign them to specific gateways.

Browse to '''System > General Setup'''. There you will see the existing entry for 192.0.2.1. In a real production environment, you may consider assigning this to GW_WAN, however that is not possible or necessary here as 192.0.2.1 exists in the same network as the WAN.

Add '''198.51.100.1''' as a secondary DNS server. In a real production environment, you may consider assigning this to GW_WAN2, however that is not possible or necessary here as 198.51.100.1 exists in the same network as the WANs.

Click Save.

== Configuring Monitor IPs ==

The system will ping its monitor IP for each gateway to determine gateway status. By default, the gateway's IP is used. For multi-WAN scenarios, that is probably not a good choice.

* Your default gateway may be a local router within your facility, unlikely to ever go down when your Internet goes down.
* Or problems in your ISP's network further upstream could cause loss of connectivity.
* Using an IP out on the Internet as the monitor IP offers a better test of connectivity.

Use of anycasted IPs is best:
* Google public DNS: 8.8.8.8 and 8.8.4.4
* OpenDNS: 208.67.220.220 and 208.67.222.222

Browse to '''System > Routing'''. Edit '''GW_WAN'''. For monitor IP, fill in '''8.8.8.8'''. Save. Then edit '''GW_WAN2''', and set its monitor IP to '''8.8.4.4'''. Save, then Apply Changes.

== Configuring Gateway Groups ==

Configure three gateway groups for use at HQ:
# One that prefers WAN and fails over to WAN2.
# One that prefers WAN2 and fails over to WAN.
# One that load balances across both.

Browse to '''System > Routing''', and click the '''Groups''' tab. Click '''+Add''' to add a new group.

=== WAN to WAN2 ===

This gateway group prefers WAN (tier 1) and fails over to WAN2 (tier 2). Then click Save.

=== WAN2 to WAN ===

Click the duplicate symbol to the right of the WANtoWAN2 group to create a new group based on this one, then flip the tiers, group name and description. This prefers WAN2, and fails over to WAN.

=== Load Balance ===

This load balances across both WAN and WAN2. If a WAN fails, it's removed from the load balancing pool.

== Configure NAT for Multi-WAN ==

The NAT configuration is all on a per-interface basis, specifying one particular interface and having IP information that's specific to that interface. When you add a new WAN, you also need NAT configuration specific to that new WAN.

=== Configuring Virtual IPs on WAN2 ===

WAN2 will have 3 virtual IPs configured as IP aliases:

{| class="wikitable"
! IP/mask !! Description
|-
| 198.51.100.4/32 || server1 WAN2 external address
|-
| 198.51.100.5/32 || server2 WAN2 external address
|-
| 198.51.100.6/32 || extra WAN2 external address
|}

Repeat the process for the remaining IPs.

=== Configuring Port Forwards on WAN2 ===

To open the same ports on WAN2 as on WAN, duplicate the existing port forward entries and change their interface from WAN to WAN2.

Browse to '''Firewall > NAT''', '''Port Forwards''' tab. Click the duplicate symbol to the right of the “VNC to hqclient” entry. In the resulting screen, change the interface from WAN to WAN2. Note how the destination address automatically changes to “WAN2 address.” Verify that change, update the description if desired, then save.

Repeat that process for the port 222 SSH port forward to hq-client.

=== Configuring 1:1 NAT on WAN2 ===

Configure 1:1 NAT for server1 and server2 on WAN2.

{| class="wikitable"
! Setting !! server1 !! server2
|-
| Interface || WAN2 || WAN2
|-
| External IP || 198.51.100.4 || 198.51.100.5
|-
| Internal IP || 172.17.2.10 || 172.17.2.20
|-
| Description || server1.example.com WAN2 || server2.example.com WAN2
|}

Save and apply changes.

=== Configuring Outbound NAT on WAN2 ===

Since the configuration is using manual outbound NAT, add outbound NAT rules for WAN2.

Browse to '''Firewall > NAT''', '''Outbound''' tab. Click the duplicate symbol to the right of “hq-client out via .6” to add a new entry based on that one. Change the interface to WAN2, and the Translation address to 198.51.100.6.

Repeat the same process for the two other outbound NAT rules.

== Configuring WAN2 Firewall Rules ==

We want the same external access on WAN2 as is already active on WAN, permitting certain traffic through the 1:1 NATs for server1 and server2. Interface groupings do not support return routing at this time, so the rules must be kept on each WAN separately.

Browse to '''Firewall > Rules''', WAN tab. Click the duplicate symbol to the right of “allow web ports to public web servers” to duplicate it, change the interface from WAN to WAN2, and click Save. Because the NAT applies first, the firewall rule is otherwise identical to the one on WAN.

Repeat the same process for rules “allow pings to public web servers” and “allow SSH to web servers from remote admin.”

== Configure Firewall Rules for Outbound Traffic ==

In a multi-WAN environment, outbound traffic is directed to a particular WAN or gateway group via policy routing with firewall rules.

=== Test WAN2 with Single Client ===

First, send only HQ-client out via WAN2. It's generally best to first test a new WAN with a single client.

Browse to '''Firewall > Rules''', LAN tab, and click Add to add a rule to the top of the list:

{| class="wikitable"
! Setting !! Value
|-
| Action || Pass
|-
| Interface || LAN
|-
| Protocol || any
|-
| Source || Single host or alias, 172.17.1.100
|-
| Destination || any
|-
| Description || hq-client1 prefer WAN2
|-
| Gateway (Advanced Options) || WAN2toWAN
|}

Save and apply changes.

=== Testing LAN out WAN2 ===

Open hq-client1's web browser and browse to http://100.64.0.50. You should be able to connect, and see you're coming from 198.51.100.6, the WAN2 VIP where hq-client1 is NATed.

=== Configure LAN for Failover Group ===

The “hq-client1 prefer WAN2” rule was only for testing. Delete that rule now.

Then edit the “Default allow LAN to any” rule, and choose Gateway '''WANtoWAN2'''. Verify Internet connectivity is still functioning from hq-client1.

=== LAN to DMZ Connectivity ===

Try to ping 172.17.2.10 from hq-client1. You won't receive a successful reply because traffic matching a firewall rule specifying a gateway is forced to that gateway. The attempt to get to DMZ is actually being sent to the WAN ISP's router, which can't route internal traffic.

=== Add LocalNetworks Alias ===

Add an alias containing destinations that will not be policy-routed to the Internet.

Browse to '''Firewall > Aliases''' and click '''+Add''':

{| class="wikitable"
! Setting !! Value
|-
| Name || LocalNetworks
|-
| Description || networks that will not be policy routed to Internet
|-
| Type || Network
|-
| Network 1 || 172.17.0.0/16 (HQ)
|-
| Network 2 || 172.18.0.0/16 (branch)
|}

Save and apply changes.

=== Add Firewall Rule for Negation ===

Browse to '''Firewall > Rules''', LAN, and click Add to add a new rule to the top of the list:

{| class="wikitable"
! Setting !! Value
|-
| Action || Pass
|-
| Interface || LAN
|-
| Protocol || any
|-
| Source || LAN net
|-
| Destination || Single host or alias, LocalNetworks alias
|-
| Description || allow local networks with no policy routing
|-
| Gateway || Leave at default
|}

Start a new ping to 172.17.2.10 and it will reply. If you still aren't getting a ping reply, it's probably because of an old firewall state. Reset states under '''Diagnostics > States''', or delete those specific states, and try again.

== Default Gateway Switching ==

At this point, all traffic sourced from inside the LAN or DMZ destined for the internet will follow the policy route. However, the default route on the firewall is still pointing to WAN1. In the event of a WAN1 failure, traffic sourced by the firewall itself will not be able to reach the internet.

Navigate to '''System > Routing''' and set '''Default gateway IPv4''' to '''Automatic''' and click Save.

== Testing Failover ==

Now that failover is configured, it's important to test it. Create a failure on WAN to verify it switches over to WAN2.

In the virtual lab environment, shutdown the WAN1 NIC on “Lab Internet router.” Point your web browser to your Lab Internet Router (http://100.64.0.1) and browse to '''Interfaces > HQ_WAN1'''. Uncheck the Enable box at the top and click OK, then Apply.

Now browse to '''Status > Gateways''' on fw1-HQ. Within a few seconds, WAN should show as offline. Once it does, try to browse out from LAN to the Internet. You should now be using WAN2.

Once tested, normalize your lab by logging back into your Lab Internet Router (http://100.64.0.1) and check the Enable box in the HQ-WAN1 interface. Your WAN gateway should then come back online.

This completes the multi-WAN lab.

----

<div style="background:#f0f0f0;border:1px solid #ccc;padding:8px;">
'''Source:''' Netgate pfSense Plus Fundamentals and Practical Application — Lab 8 (Multi-WAN).<br/>
© 2021 Rubicon Communications, LLC (Netgate).<br/>
'''Reference WAN2 IP:''' 198.51.100.2/24, Gateway: 198.51.100.1
</div>

'''Previous Module:''' [[Training:_Multi-WAN|Training: Multi-WAN]]

Training: Multi-WAN

2026-04-23T07:06:59Z

Justinaquino: Created page with "__NOTOC__ <div style="background:#e6f3ff;border:1px solid #0066cc;padding:10px;margin-bottom:15px;"> '''Netgate pfSense Plus Fundamentals — Section 8: Multi-WAN'''<br/> <i>Overview, redundancy, load balancing, gateway groups, and best practices for multiple Internet connections.</i> </div> == Multi-WAN Overview == Use of multiple Internet connections for: * '''Redundancy''' (common) * '''Bandwidth aggregation''' * '''Load balancing''' == Multi-WAN Best Practices ==..."

__NOTOC__

<div style="background:#e6f3ff;border:1px solid #0066cc;padding:10px;margin-bottom:15px;">
'''Netgate pfSense Plus Fundamentals — Section 8: Multi-WAN'''<br/>
<i>Overview, redundancy, load balancing, gateway groups, and best practices for multiple Internet connections.</i>
</div>

== Multi-WAN Overview ==

Use of multiple Internet connections for:
* '''Redundancy''' (common)
* '''Bandwidth aggregation'''
* '''Load balancing'''

== Multi-WAN Best Practices ==

Internet connectivity selection considerations:

{| class="wikitable"
! Consideration !! Description
|-
| Performance || Evaluate throughput, latency, and reliability of each link.
|-
| Cable path || Use physically diverse paths to avoid single points of failure.
|-
| Disparate ISP networks || Use different ISPs to reduce the risk of a common outage.
|-
| Plan for failure! || Always design with failure scenarios in mind.
|-
| Usage scenarios for load balancing || Understand traffic patterns before implementing load balancing.
|}

== Multi-WAN Gateways ==

Each gateway defines an Internet connection.

* Monitor IP can be changed.
* Advanced parameters available (latency and packet loss thresholds).

== Multi-WAN Gateway Groups ==

Gateway groups are containers of gateways (Internet connections).

{| class="wikitable"
! Attribute !! Description
|-
| Tiers 1-5 || Lowest tier number is highest priority.
|-
| One or more gateways per tier || Multiple gateways can share a tier.
|-
| Usage || Applied via policy routing, IPsec, OpenVPN, Dynamic DNS.
|}

== Multi-WAN Outbound Traffic ==

Controlled via '''policy routing''':

* Firewall rules specifying a gateway.
* Matching traffic is forced to the specified gateway.
* Overrides routing table in all circumstances.

== Multi-WAN Inbound Traffic ==

* Port forwards and 1:1 NAT are specific to one WAN.
* Duplicate port forwards for additional WANs.
* Add 1:1 NAT entries for additional WANs.
* Update how traffic comes in (DNS updates).
* Dynamic DNS on gateway group.
* Multiple inbound options always live (e.g., email — one MX record per WAN).

== Section 8 Summary ==

{| class="wikitable"
! Key Point !! Detail
|-
| Rule ordering || First match wins.
|-
| Bypass rule || A bypass rule may be required.
|-
| Gateway forcing || Matching traffic is forced to gateway.
|-
| Monitor IP || Use appropriate monitor IP per WAN.
|-
| Load balancing || Load-balance over equal-size links.
|-
| Per-flow balancing || Load-balancing is per-flow, not per-packet.
|-
| Reference || Check the Multi-WAN section of the book!
|}

----

<div style="background:#f0f0f0;border:1px solid #ccc;padding:8px;">
'''Source:''' Netgate pfSense Plus Fundamentals and Practical Application — Section 8 (Multi-WAN).<br/>
© 2017 Rubicon Communications, LLC dba Netgate.
</div>

'''Next Module:''' [[Training_Lab_8:_Multi-WAN|Training Lab 8: Multi-WAN]]

Training Lab 4: Services and Branch Network

2026-04-23T07:01:36Z

Justinaquino: Created from Netgate pfSense training PDFs

__NOTOC__

<div style="background-color: #fff3cd; border-left: 6px solid #ffc107; padding: 15px; margin-bottom: 20px;">
<strong>Lab:</strong> Lab 4 — Services and Branch Network Setup<br>
<strong>Course:</strong> Netgate FUND001-LIVE — pfSense Plus Fundamentals and Practical Application<br>
<strong>Objective:</strong> Configure common pfSense Plus services (DNS Resolver, DHCP Server) and bring up a branch network for use in the next lab.
</div>

== Lab Overview ==

In this lab, we will go through a couple of the common services used on pfSense Plus, then bring up the branch network to be used in the next lab.

The exercises cover:

* Configuring the '''DNS Resolver''' (domain overrides, host overrides)
* Configuring the '''DHCP Server''' (changing scope, adding static mappings)
* '''Branch network setup''' and remote management

== Prerequisites ==

* Access to fw1-HQ (172.17.1.1)
* Access to HQ-client (DHCP client on HQ-LAN)
* Access to branch firewall (172.18.1.1)
* Default admin/pfsense credentials

== Exercise 1: DNS Resolver Configuration ==

The DNS Resolver provides a local caching DNS resolver on the firewall. On smaller networks with no local DNS servers, using the local DNS Resolver as your clients' DNS server — rather than directly assigning DNS servers on the Internet — is preferable.

It provides:

* A local DNS cache
* Ability to query multiple DNS servers simultaneously, returning the fastest response
* Security protections such as DNS rebinding protection and DNSSEC

=== 1.1 DNS Server Configuration ===

By default, the DNS Resolver queries root DNS servers directly and does not use DNS servers configured under '''System > General Setup''' or those obtained automatically from a dynamic WAN.

'''Step 1:''' Browse to '''System > General Setup''' on fw1-HQ.

'''Step 2:''' Review the DNS server configuration. Currently, fw1-HQ is statically configured to use the DNS Resolver on lab-internet-router.

'''Step 3:''' The '''"Allow DNS server list to be overridden by DHCP/PPP on WAN"''' checkbox is checked by default. Since these systems do not have dynamic WANs, this option has no effect. '''Uncheck''' this option.

'''Step 4:''' Leave the remaining settings as they are and click '''Save'''.

=== 1.2 Domain Overrides ===

Domain overrides allow you to configure specific DNS servers to use for particular domains.

In this exercise, we will forward '''example.lan''' to '''172.17.2.10'''. This is functionally equivalent to what you would do in a Small Business Server (SBS) scenario for Active Directory.

'''Step 1:''' On HQ-client, open a terminal and test resolution '''before''' adding the domain override:

<pre>
training@HQ-client:~$ host server1.example.lan
Host server1.example.lan not found: 3(NXDOMAIN)
training@HQ-client:~$ host server2.example.lan
Host server2.example.lan not found: 3(NXDOMAIN)
training@HQ-client:~$ host hq-client.example.lan
Host hq-client.example.lan not found: 3(NXDOMAIN)
</pre>

NXDOMAIN means "no such name exists." To resolve example.lan, we must tell the DNS Resolver where to send those queries.

'''Step 2:''' On fw1-HQ, browse to '''Services > DNS Resolver'''.

'''Step 3:''' Scroll down to '''Domain Overrides''' and click '''+Add'''.

'''Step 4:''' Configure the domain override:

{| class="wikitable"
! Field
! Value
|-
| Domain
| example.lan
|-
| IP Address
| 172.17.2.10
|}

'''Step 5:''' Click '''Save'''.

=== 1.3 Testing Domain Override ===

'''Step 1:''' On HQ-client, open a terminal and test resolution again:

<pre>
training@hq-client:~$ host server1.example.lan
server1.example.lan has address 172.17.2.10
training@hq-client:~$ host server2.example.lan
server2.example.lan has address 172.17.2.20
training@hq-client:~$ host hq-client.example.lan
hq-client.example.lan has address 172.17.1.100
</pre>

These queries go to the DNS Resolver on fw1-HQ, which uses the domain override to send example.lan queries to server1. Server1 replies to the DNS Resolver, which replies back to HQ-client.

=== 1.4 Host Overrides ===

Host overrides allow you to configure how a specific hostname is resolved by the DNS Resolver. A common use is '''split DNS''': resolving public DNS hostnames to private IPs internally to eliminate the need for NAT reflection.

In this lab:

* www.example.com is hosted in the HQ DMZ on server1
* www.example.com publicly resolves to 192.0.2.4
* Without NAT reflection, HQ internal hosts cannot reach 192.0.2.4
* We will add a host override to resolve www.example.com to the internal IP 172.17.2.10

'''Step 1:''' On fw1-HQ, browse to '''Services > DNS Resolver''', scroll down to '''Host Overrides''', and click '''+Add'''.

'''Step 2:''' Configure the host override:

{| class="wikitable"
! Field
! Value
|-
| Host
| (leave blank)
|-
| Domain
| example.com
|-
| IP address
| 172.17.2.10
|-
| Alias Host
| www
|-
| Alias Domain
| example.com
|}

'''Step 3:''' Click '''Save''' and '''Apply Changes'''.

=== 1.5 Testing Host Override ===

'''Step 1:''' On HQ-client, test resolution:

<pre>
training@HQ-client:~$ host www.example.com
www.example.com has address 172.17.2.10
training@HQ-client:~$ host example.com
example.com has address 172.17.2.10
</pre>

'''Step 2:''' Open '''www.example.com''' in your web browser on HQ-client. The page should load, showing it is from server1 and displaying your source IP.

== Exercise 2: DHCP Server Configuration ==

The DHCP Server comes enabled by default on LAN, assigning IP information, a default gateway, and DNS server to LAN clients.

HQ-client is a DHCP client currently obtaining an IP from the general pool. Because it is the first and only device on HQ-LAN, it gets the first IP: '''172.17.1.100'''. We want to ensure HQ-client is always assigned the .100 IP and that it cannot be assigned to any other host.

=== 2.1 Checking DHCP Status ===

'''Step 1:''' On fw1-HQ, browse to '''Status > DHCP Leases'''.

'''Step 2:''' Locate the lease for HQ-client.

=== 2.2 Changing DHCP Scope ===

The underlying DHCP server (ISC dhcpd) requires statically mapped IPs to be '''outside of the DHCP scope'''. Since .100 is part of the currently active range, we must change the range to exclude it.

Note: Doing so will not immediately impact HQ-client. It will retain its existing .100 IP until its next renewal.

'''Step 1:''' Browse to '''Services > DHCP Server''' and click the '''LAN''' tab.

'''Step 2:''' Change the '''Start of the range''' to '''172.17.1.101'''.

'''Step 3:''' Click '''Save'''.

Now .100 will be available for a DHCP reservation.

=== 2.3 Adding DHCP Static Mapping for HQ-client ===

First, we need to renew the DHCP lease on HQ-client so it re-populates in the DHCP leases screen (its lease for .100 was deleted after changing the scope).

'''Step 1:''' On HQ-client, click the network icon in the top right corner and click '''"Ifupdown (eth0)"''' to renew the lease.

Note: Your VNC session will be dropped. Wait a few seconds.

'''Step 2:''' On fw1-HQ, refresh '''Status > DHCP Leases'''. After 20-30 seconds, you should see HQ-client obtained a lease for '''172.17.1.101'''. Reconnect to VNC using the .101 IP.

'''Step 3:''' Browse to '''Status > DHCP Leases'''.

'''Step 4:''' Click the '''+''' to the right of the HQ-client lease to add a DHCP static mapping.

'''Step 5:''' At the "Edit static mapping" screen, fill in:

{| class="wikitable"
! Field
! Value
|-
| IP address
| 172.17.1.100
|}

'''Step 6:''' Click '''Save''' and '''Apply Changes'''.

=== 2.4 Renewing DHCP Lease on HQ-client ===

'''Step 1:''' Force HQ-client to renew its DHCP lease again (click network icon → "Ifupdown (eth0)").

Note: This will drop your VNC session again. Wait a few seconds for it to pick up the lease for the static mapping, then reconnect using '''172.17.1.100'''.

'''Step 2:''' Browse to '''Status > DHCP Leases''' on fw1-HQ and verify HQ-client's static mapping status.

== Exercise 3: Branch Network Setup ==

Here we will bring the branch network online to be ready for use in the next lab.

=== 3.1 Initial Branch Firewall Access ===

'''Step 1:''' Browse to '''https://172.18.1.1''' from your system.

'''Step 2:''' Add an exception for the self-signed certificate.

'''Step 3:''' Log in with the default credentials '''admin / pfsense'''.

Note: This will not trigger the setup wizard, as this VM comes pre-configured past that point.

=== 3.2 Setting Up Remote Management ===

We will have a VPN connected into this location in the next lab. However, it is usually best to have a means into remote offices' firewalls without requiring a VPN, limited to specific trusted source IPs.

==== Add RemoteAdmin Alias ====

'''Step 1:''' Browse to '''Firewall > Aliases''' and click '''+Add'''.

'''Step 2:''' Create the alias with the following parameters:

{| class="wikitable"
! Parameter
! Value
|-
| Name
| RemoteAdmin
|-
| Type
| Networks
|-
| Members
| 192.0.2.0/24 (HQ WAN)<br>198.51.100.0/24 (HQ WAN2)
|}

'''Step 3:''' Click '''Save''' and '''Apply Changes'''.

==== Add Firewall Rule ====

'''Step 1:''' Browse to '''Firewall > Rules''', click the '''WAN''' tab, and click '''Add'''.

'''Step 2:''' Configure the rule:

{| class="wikitable"
! Parameter
! Value
|-
| Action
| Pass
|-
| Interface
| WAN
|-
| Protocol
| any
|-
| Source
| Single host or alias → RemoteAdmin
|-
| Destination
| WAN address
|-
| Description
| allow remote administration from trusted IPs
|}

'''Step 3:''' Click '''Save''' and '''Apply Changes'''.

=== 3.3 Test Remote Administration ===

'''Step 1:''' On HQ-client, browse to '''https://203.0.113.10'''.

'''Step 2:''' It should load, allowing you to log in and manage the branch system from HQ.

You have now reached the end of this lab.

== Lab Summary ==

{| class="wikitable"
! Exercise
! What We Did
! Key Takeaway
|-
| DNS Resolver
| Configured domain overrides and host overrides
| Use overrides for internal domains and split DNS
|-
| DHCP Server
| Changed scope and added static mapping
| Static IPs must be outside the DHCP pool
|-
| Branch Setup
| Brought branch firewall online, added remote admin access
| Restrict remote admin to trusted source IPs
|}

== Next Module ==

Continue to the next lab for VPN configuration and connecting the branch network.

----

''Source: Netgate FUND001-LIVE-Lab4-Services.pdf''

[[Category:Training]]
[[Category:pfSense]]
[[Category:Networking]]
[[Category:Lab]]

Training: pfSense Services

2026-04-23T07:01:36Z

Justinaquino: Created from Netgate pfSense training PDFs

__NOTOC__

<div style="background-color: #e7f3fe; border-left: 6px solid #2196F3; padding: 15px; margin-bottom: 20px;">
<strong>Module:</strong> Section 4 — pfSense Plus Services<br>
<strong>Course:</strong> Netgate FUND001-LIVE — pfSense Plus Fundamentals and Practical Application<br>
<strong>Topics Covered:</strong> DHCP, DNS Resolver/Forwarder, Dynamic DNS, NTP, SNMP, UPnP / NAT-PMP, IGMP Proxy, PPPoE Server, Wake on LAN<br>
<strong>Objective:</strong> Understand the built-in services available on pfSense Plus and how to configure and secure them.
</div>

== Learning Objectives ==

By the end of this module, you will be able to:

* Identify the core network services built into pfSense Plus
* Understand the difference between DHCP Server and DHCP Relay
* Configure the DNS Resolver for local caching and recursion
* Explain the purpose of Dynamic DNS, NTP, SNMP, and UPnP
* Apply security best practices for exposed services

== Overview of pfSense Plus Services ==

pfSense Plus includes a rich set of network services that can be enabled and configured as needed. These services help manage client connectivity, name resolution, time synchronization, monitoring, and more.

The available services include:

* '''DHCP Server''' — Assigns IP addresses and network information to clients
* '''DHCP Relay''' — Forwards DHCP requests to servers on another network
* '''DNS Forwarder (legacy)''' — Forwards DNS queries to external servers
* '''DNS Resolver''' — Caching DNS resolver with recursion support
* '''Dynamic DNS''' — Updates DNS records automatically when the WAN IP changes
* '''IGMP Proxy''' — Forwards IGMP multicast traffic between interfaces
* '''NTP Server''' — Provides Network Time Protocol services to local clients
* '''PPPoE Server''' — Terminates PPPoE client connections
* '''SNMP''' — Integrates with network monitoring systems
* '''UPnP / NAT-PMP''' — Allows internal clients to automatically open NAT ports
* '''Wake on LAN''' — Sends magic packets to wake up sleeping devices

== DHCP Service ==

=== DHCP Server ===

The DHCP Server assigns IP addresses and other network information (subnet mask, gateway, DNS) to clients. It is '''enabled by default on the LAN interface'''.

Key points:

* Supports many extensible options (custom DHCP options)
* Static mappings can reserve specific IPs for known MAC addresses
* The underlying server is ISC dhcpd

=== DHCP Relay ===

DHCP Relay sends DHCP requests from clients on one network to DHCP server(s) on another network, then returns the DHCP reply to the requesting client.

* Simple concept but very useful in segmented networks
* Only one of DHCP Server or DHCP Relay can be enabled on an interface (not both)

== DNS Resolver ==

The DNS Resolver (unbound) is the '''recommended DNS solution''' for pfSense Plus.

* It is a '''caching DNS resolver'''
* Requires DNS servers for recursion (queries root servers directly by default)
* Queries all configured DNS servers and takes the fastest response
* Should be configured for '''internal-only access''' to avoid reflected DDoS exploit risks
* Supports DNSSEC for verifiable and trustworthy DNS results
* Offers DNS rebinding protection

Key configuration options:

* '''Domain Overrides''' — Forward queries for specific domains to specific DNS servers
* '''Host Overrides''' — Resolve specific hostnames to custom IPs (useful for split DNS)
* '''DNS Query Forwarding''' — Optionally forward all queries to upstream DNS servers instead of querying roots directly

== DNS Forwarder (Legacy) ==

The DNS Forwarder (dnsmasq) is the legacy DNS option. The DNS Resolver is preferred for new deployments.

== Dynamic DNS ==

Dynamic DNS automatically updates DNS records when the WAN IP address changes. This is essential for:

* Hosting services on dynamic IP connections
* Remote access to networks with non-static public IPs

== NTP Server ==

The Network Time Protocol (NTP) Server provides time synchronization services to local clients.

* Time synchronization is '''very important''' for logging, certificates, and authentication
* Supports serial GPS as a time source
* The host's own NTP server is configured under '''System > General Setup'''
* Status can be checked under '''Status > NTP'''
* It is easy to offer NTP services to clients — enable the service and allow the traffic

== SNMP ==

SNMP (Simple Network Management Protocol) integrates pfSense Plus with network monitoring platforms.

Best practices:

* Use a '''strong community string'''
* Configure to send traps and allow polling as needed
* '''Protect with firewall rules''' or bind to specific interfaces
* '''Do not expose SNMP to the WAN!'''

== UPnP / NAT-PMP ==

UPnP (Universal Plug and Play) and NAT-PMP (NAT Port Mapping Protocol) allow internal clients to automatically request port forwards from the firewall.

* Useful for gaming consoles, VoIP, and peer-to-peer applications
* Can be a security risk if not properly restricted
* Consider limiting to specific interfaces and restricting port ranges

== Other Services ==

=== IGMP Proxy ===

Forwards IGMP multicast traffic between interfaces. Used for IPTV and other multicast applications.

=== PPPoE Server ===

Terminates PPPoE client connections. Used in ISP and WISP environments.

=== Wake on LAN ===

Sends magic packets to wake up sleeping devices on the local network.

== Security Best Practices ==

{| class="wikitable"
! Service
! Best Practice
|-
| DNS Resolver
| Bind to internal interfaces only; enable DNSSEC
|-
| SNMP
| Use strong community strings; do not expose to WAN
|-
| NTP
| Restrict to internal networks; use authenticated NTP where possible
|-
| UPnP
| Limit to trusted interfaces; restrict port ranges
|-
| DHCP
| Use static mappings for critical infrastructure
|}

== Summary ==

* Use the '''DNS Resolver''' as your primary DNS solution — it can point to internal DNS servers and offers caching, DNSSEC, and security protections
* Integrate pfSense Plus with '''network monitoring platforms''' via SNMP
* '''Protect SNMP, NTP, and DNS Resolver''' with firewall rules and interface bindings
* '''Offer NTP services to clients''' — it is easy to enable and critical for network operations
* Choose between DHCP Server and DHCP Relay based on your network topology
* Restrict or avoid exposing services to the WAN unless absolutely necessary

== Next Module ==

Continue to '''[[Training_Lab_4:_Services_and_Branch_Network|Lab 4: Services and Branch Network Setup]]''' for hands-on exercises configuring the DNS Resolver, DHCP Server, and bringing up a branch network.

----

''Source: Netgate FUND001-LIVE-SLIDE-SEG4-SERVICES.pdf''

[[Category:Training]]
[[Category:pfSense]]
[[Category:Networking]]

Training Lab 3: NAT and Virtual IPs

2026-04-23T06:58:56Z

Justinaquino: Created from Netgate pfSense training PDF

__NOTOC__

<div style="background-color: #fff3e0; border-left: 6px solid #FF9800; padding: 16px; margin-bottom: 20px;">
<strong>Lab Overview:</strong> This hands-on lab covers Virtual IPs, Port Forwards, 1:1 NAT, and Outbound NAT in pfSense Plus. You will configure VIPs on the WAN subnet <code>192.0.2.0/24</code> and implement various NAT scenarios using Virtual IPs <code>192.0.2.4</code>–<code>192.0.2.6</code>.
</div>

== Lab Environment ==

{| class="wikitable"
|+ WAN Subnet Allocation
|-
! IP Address !! Purpose
|-
| 192.0.2.1 || ISP router (default gateway)
|-
| 192.0.2.2 || fw1-HQ WAN IP
|-
| 192.0.2.3 || Reserved for fw2-HQ (Advanced Application class)
|-
| 192.0.2.4 || Virtual IP — server1 WAN external address
|-
| 192.0.2.5 || Virtual IP — server2 WAN external address
|-
| 192.0.2.6 || Virtual IP — hq-client / VoIP PBX alternate outbound
|}

== Exercise 1: Configuring Virtual IPs ==

At HQ, we have a /24 public IP subnet assigned by our ISP: <code>192.0.2.0/24</code>. In most real-world networks, this will be a smaller subnet such as a /29, /28, or /27. The concepts are the same regardless of subnet size.

Our WAN1 ISP router has IP <code>192.0.2.1</code>, used as the default gateway. fw1-HQ has a WAN IP of <code>192.0.2.2</code>. In order for us to use additional IPs in the WAN1 subnet, the firewall must answer ARP requests for those addresses — this tells the ISP router to send traffic destined to those addresses to the firewall.

=== Step 1.1 — Add VIP 192.0.2.4 ===

On fw1-HQ, browse to '''Firewall → Virtual IPs'''.

Click '''+ Add''' to add a new VIP.

{| class="wikitable"
|+ VIP Configuration for server1
|-
! Field !! Value
|-
| Type || IP alias
|-
| Interface || WAN
|-
| IP Address || 192.0.2.4/32
|-
| Description || server1 WAN external address
|}

'''Note:''' You can enter the IP without choosing a mask; the JavaScript on the page will automatically set the mask to /32 after detecting an IPv4 address.

Click '''Save''', then click '''+ Add''' again to add the second VIP.

=== Step 1.2 — Add VIP 192.0.2.5 ===

{| class="wikitable"
|+ VIP Configuration for server2
|-
! Field !! Value
|-
| Type || IP alias
|-
| Interface || WAN
|-
| IP Address || 192.0.2.5/32
|-
| Description || server2 WAN external
|}

Click '''Save''', then add the third VIP.

=== Step 1.3 — Add VIP 192.0.2.6 ===

{| class="wikitable"
|+ VIP Configuration for PBX / alternate outbound
|-
! Field !! Value
|-
| Type || IP alias
|-
| Interface || WAN
|-
| IP Address || 192.0.2.6/32
|-
| Description || VoIP PBX / alternate outbound IP
|}

Click '''Save''', then click '''Apply Changes'''.

Now <code>192.0.2.4</code>, <code>192.0.2.5</code>, and <code>192.0.2.6</code> are available for use. Adding VIPs only makes the firewall answer on the configured addresses; they are not yet used for NAT.

== Exercise 2: Configuring a Basic Port Forward ==

We will set up a port forward allowing remote desktop access from the host machine to hq-client using VNC.

'''Warning:''' Opening VNC to the Internet is not recommended in production. Use a VPN instead. This is for demonstration purposes only.

=== Step 2.1 — Create VNC Port Forward ===

On fw1-HQ, browse to '''Firewall → NAT''', Port Forward tab. Click '''Add'''.

{| class="wikitable"
|+ VNC Port Forward Rule
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || any
|-
| Destination || WAN address
|-
| Destination port || 5900
|-
| Redirect target IP || 172.17.1.100
|-
| Redirect target port || 5900
|-
| Description || forward VNC to hq-client
|}

Click '''Save''', and '''Apply Changes'''.

=== Step 2.2 — Verify the Port Forward ===

From your host OS or the internet-host VM, connect to <code>192.0.2.2:5900</code> with VNC Viewer.

On fw1-HQ, browse to '''Diagnostics → States''' and filter for <code>:5900</code>. You will see two states: inbound (WAN) and outbound (LAN).

== Exercise 3: Port Forward on a Different External Port ==

Sometimes you need to use a different external port than the internal port. For example, opening SSH on port 222 externally to port 22 internally reduces SSH brute-force log noise.

=== Step 3.1 — Create Alternate SSH Port Forward ===

Instead of clicking '''Add''', click the '''copy''' icon to the right of the VNC port forward to duplicate it. Then change:

{| class="wikitable"
|+ Alternate SSH Port Forward Rule
|-
! Field !! Value
|-
| Destination port || 222
|-
| Redirect target port || 22
|-
| Description || external SSH port 222 to hq-client
|}

Click '''Save''' and '''Apply Changes'''.

=== Step 3.2 — Test SSH Connection ===

From your computer, run:

<pre>
ssh -p 222 training@192.0.2.2
</pre>

Or from Windows, use PuTTY with IP <code>192.0.2.2</code> and port <code>222</code>, ensuring SSH is selected.

== Exercise 4: Restricted Source Port Forward ==

Restrict the hq-client VNC port forward to the RemoteAdmins alias.

=== Step 4.1 — Edit VNC Port Forward ===

Edit the VNC port forward. In the '''Source''' field, click '''Advanced'''.

* Type: '''Single host or alias'''
* Address: Type <code>r</code> to populate the '''RemoteAdmin''' alias
* Source port: '''any'''

Save and apply changes.

=== Step 4.2 — Verify Restriction ===

* From the remote-host VM (if not in RemoteAdmin alias): connection should fail
* From the host OS (if in RemoteAdmin alias): connection should succeed

== Exercise 5: Alternate External IP Port Forward ==

Use the Virtual IPs added earlier instead of the WAN IP.

=== Step 5.1 — Create HTTP Port Forward on VIP ===

Click '''Add''' to add a new port forward.

{| class="wikitable"
|+ HTTP to server1 via VIP
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || any
|-
| Destination || 192.0.2.4
|-
| Destination port || 80
|-
| Redirect target IP || 172.17.2.10
|-
| Redirect target port || 80
|-
| Description || HTTP to server1
|}

Save and apply changes.

=== Step 5.2 — Verify HTTP Access ===

Browse to <code>http://192.0.2.4</code> from your host OS or internet-host VM. It should display the server1 page.

'''Note:''' Reflection is not yet configured, so this will only work from outside the network.

== Exercise 6: Configuring 1:1 NAT ==

1:1 NAT maps one external IP to one internal IP. Port forwards take precedence over 1:1 NAT where they overlap.

=== Step 6.1 — Delete Overlapping Port Forward ===

First, delete the '''HTTP to server1''' port forward entry, then apply changes. This is preferable to letting 1:1 NAT handle the traffic.

=== Step 6.2 — Configure 1:1 NAT for server1 ===

Browse to '''Firewall → NAT''', 1:1 tab. Click '''Add'''.

{| class="wikitable"
|+ 1:1 NAT for server1
|-
! Field !! Value
|-
| Interface || WAN
|-
| External || 192.0.2.4
|-
| Internal || 172.17.2.10
|-
| Description || server1
|}

Save and apply changes.

'''Important:''' Adding a 1:1 NAT entry only defines how traffic is translated. Without firewall rules, no traffic will pass in or out.

=== Step 6.3 — Configure 1:1 NAT for server2 ===

Click '''Add''' to add another 1:1 NAT entry.

{| class="wikitable"
|+ 1:1 NAT for server2
|-
! Field !! Value
|-
| Interface || WAN
|-
| External || 192.0.2.5
|-
| Internal || 172.17.2.20
|-
| Description || server2.example.com
|}

Save and apply changes.

== Exercise 7: Firewall Rules for 1:1 NAT ==

=== Step 7.1 — Allow Pings to Public Web Servers ===

Browse to '''Firewall → Rules''', WAN tab. Click '''Add'''.

{| class="wikitable"
|+ ICMP Rule for Web Servers
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || ICMP
|-
| ICMP Type || Echo request
|-
| Source || any
|-
| Destination || Single host or alias — WebServers alias
|-
| Description || allow pings to public web servers
|}

Save and apply changes.

Test by pinging <code>192.0.2.4</code> from your host machine:

<pre>
ping 192.0.2.4
</pre>

Leave the ping running and browse to '''Diagnostics → States'''. Filter for <code>192.0.2.100:</code> (if from host OS) and observe the states. Traffic sourced from <code>192.0.2.100</code> to <code>192.0.2.4</code> is translated to <code>172.17.2.10</code>.

=== Step 7.2 — Allow SSH to Web Servers from RemoteAdmins ===

{| class="wikitable"
|+ SSH Rule for RemoteAdmins
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || Single host or alias — RemoteAdmins alias
|-
| Destination || Single host or alias — WebServers alias
|-
| Destination port || 22
|-
| Description || allow SSH to web servers from remote admin
|}

Save and apply changes.

From your host machine, test:

<pre>
ssh training@192.0.2.4
</pre>

=== Step 7.3 — Allow Web Access to Public Web Servers ===

{| class="wikitable"
|+ HTTP/HTTPS Rule for Web Servers
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || any
|-
| Destination || Single host or alias — WebServers
|-
| Destination port || WebPorts alias
|-
| Description || allow web ports to public web servers
|}

Save and apply changes.

Now browse to <code>http://192.0.2.4</code> (server1) and <code>http://192.0.2.5</code> (server2).

== Exercise 8: Configuring Outbound NAT ==

Outbound NAT defines whether and how the source IP of matching traffic will be translated when it leaves an interface.

=== Step 8.1 — Switch to Manual Outbound NAT ===

Browse to '''Firewall → NAT''', Outbound tab. Select '''Manual Outbound NAT''', then click '''Save'''.

The system auto-populates the outbound NAT ruleset with the rules it was automatically generating previously. The configured manual rules take effect only upon applying changes.

=== Step 8.2 — Clean Up Auto-Generated Rules ===

The auto-generated rules include:

* LAN subnet, DMZ subnet, and loopback <code>127.0.0.0/8</code>
* IPv6 rules
* Static port for UDP port 500 (for non-NAT-T IPsec VPN clients)

Clean up by:

* Deleting the <code>127.0.0.0/8</code> rule (unusual circumstance)
* Deleting IPv6 rules (not using IPv6)
* Deleting UDP port 500 rules (nearly unheard of today)
* Replacing LAN and DMZ subnets with the summarized <code>172.17.0.0/16</code>

Edit the '''LAN to WAN''' rule:

{| class="wikitable"
|+ Consolidated Outbound NAT Rule
|-
! Field !! Value
|-
| Interface || WAN
|-
| Source || 172.17.0.0/16
|-
| Destination || any
|-
| Translation || Interface address
|}

Delete all other outbound NAT rules. Your list should have one rule.

'''Important:''' 1:1 NAT entries take precedence over outbound NAT. server1 traffic goes out via <code>192.0.2.4</code> and server2 via <code>192.0.2.5</code> regardless of outbound NAT rules.

=== Step 8.3 — Send hq-client Out via Alternate IP ===

Click the top '''Add''' button to add the new rule at the top of the list.

{| class="wikitable"
|+ Outbound NAT for hq-client
|-
! Field !! Value
|-
| Interface || WAN
|-
| Source || 172.17.1.100/32
|-
| Destination || any
|-
| Translation || 192.0.2.6
|-
| Description || hq-client out via .6
|}

Ensure this rule is above the <code>172.17.0.0/16</code> rule, since the first match wins.

=== Step 8.4 — Static Port for VoIP PBX ===

NAT can break VoIP. If rewriting source ports breaks SIP/RTP, configure static port for the PBX.

Assume a PBX at <code>172.17.1.200</code>. Click the '''copy''' icon next to the hq-client outbound NAT rule, then change:

{| class="wikitable"
|+ Outbound NAT for VoIP PBX
|-
! Field !! Value
|-
| Source || 172.17.1.200/32
|-
| Destination || any
|-
| Translation || Address 192.0.2.6, Static port checked
|-
| Description || VoIP PBX static port
|}

Ensure this rule is above the <code>172.17.0.0/16</code> rule.

== Lab Summary ==

In this lab, you learned to:

* Configure IP Alias Virtual IPs on the WAN interface
* Create Port Forwards (same port, alternate port, restricted source, alternate external IP)
* Configure 1:1 NAT mappings
* Add firewall rules to permit traffic through 1:1 NAT
* Switch from Automatic to Manual Outbound NAT
* Configure alternate outbound IPs and static port for VoIP

== Next Module ==

Proceed to the next training module. Return to the '''[[Training:_NAT_and_Virtual_IPs|NAT and Virtual IPs — Lecture Slides]]''' for review.

----

''Source: Netgate FUND001-LIVE-SLIDE-SEG3-NATVIP.pdf / FUND001-LIVE-Lab3-NATandVIPs.pdf''

Training: NAT and Virtual IPs

2026-04-23T06:58:55Z

Justinaquino: Created from Netgate pfSense training PDF

__NOTOC__

<div style="background-color: #e7f3ff; border-left: 6px solid #2196F3; padding: 16px; margin-bottom: 20px;">
<strong>Module Overview:</strong> This module covers Network Address Translation (NAT) and Virtual IPs (VIPs) in pfSense Plus. You will learn the different types of NAT, how NAT interacts with firewall rules, and best practices for configuring translation in production networks.
</div>

== Learning Objectives ==

By the end of this module, you will be able to:

* Explain what NAT is and how it modifies IP packet headers
* Identify common uses for NAT (Internet access, conflicting networks, routing issues)
* Distinguish between NAT rules and firewall rules
* Describe Port Forwards, 1:1 NAT, and Outbound NAT
* Understand NAT Reflection and why it should be avoided
* Troubleshoot common NAT problems

== What is NAT? ==

'''Network Address Translation (NAT)''' is the modification of IP packet headers. It involves the replacement of:

* Source and/or destination IP addresses
* Source and/or destination ports for TCP and UDP

=== Common Uses of NAT ===

* Internet access for private networks
* Connection of conflicting networks (overlapping IP ranges)
* Working around routing issues

== NAT and Firewall Rules ==

NAT rules are '''not''' firewall rules. NAT rules only define translation. You still need firewall rules to allow traffic to pass.

=== Key Points ===

* NAT rules and firewall rules are matched in a top-down fashion
* '''LAN rules''' are evaluated '''pre-NAT''' (using private source IPs)
* '''WAN rules''' are evaluated '''post-NAT''' (using private destination IPs)
* Port forwards — pfSense Plus can automatically add corresponding firewall rules

== Types of NAT ==

=== Port Forwards ===

Port forwards provide traffic redirection. Common use cases include:

* Traditional port forward (e.g., external port to internal server)
* Transparent HTTP proxy
* Redirection of SMTP, DNS

=== 1:1 NAT ===

1:1 NAT is a mapping of one internal IP to one external IP. Key characteristics:

* Can also map one internal network to one external network
* Configured on a per-interface basis
* Can optionally be limited to specific destinations

{| class="wikitable"
|+ 1:1 NAT Example
|-
! Type !! External IP !! Internal IP
|-
| Host || 200.100.1.12 || 192.168.1.99
|}

=== Outbound NAT ===

Outbound NAT controls how traffic leaving the firewall is translated.

* '''Automatic outbound''' — Default behavior; pfSense Plus automatically creates rules
* '''Manual outbound''' — Administrator defines all rules explicitly
* '''Hybrid mode''' — Combines automatic and manual rules

Outbound NAT rule options include:

* '''Static port''' — Preserve the original source port
* '''Pool options''' — Distribute translation across multiple IPs

== NAT Reflection ==

NAT Reflection allows accessing services via their public IP from inside the network.

'''Best Practice:''' NAT Reflection should be avoided whenever possible because it:

* Adds unnecessary overhead
* Loses the original source IP information

'''Alternative:''' Use Split DNS (internal DNS server resolving to private IPs) instead.

== Troubleshooting NAT ==

Remember these key troubleshooting steps:

* '''First match wins''' — Rules are evaluated top-down
* Ensure the correct interface is selected
* Review firewall states (Diagnostics → States)
* Verify Virtual IP configuration if applicable
* Use Packet Capture for detailed inspection
* See the troubleshooting section in the NAT chapter of the pfSense book

== Summary ==

* NAT rules are '''not''' firewall rules
* Both are still matched in a top-down fashion
* You still need firewall rules to allow traffic to pass
* NAT Reflection is suboptimal — use an internal DNS server instead
* 1:1 NAT can be host-to-host or network-to-network
* NAT is interface-specific

== Next Module ==

Continue to '''[[Training_Lab_3:_NAT_and_Virtual_IPs|Lab 3: NAT and Virtual IPs]]''' for hands-on exercises configuring Virtual IPs, Port Forwards, 1:1 NAT, and Outbound NAT.

----

''Source: Netgate FUND001-LIVE-SLIDE-SEG3-NATVIP.pdf / FUND001-LIVE-Lab3-NATandVIPs.pdf''

Training Lab 2: Firewall Rules and Aliases

2026-04-23T06:58:28Z

Justinaquino: Created page with "__NOTOC__ <div style="background-color:#fff3e6; border:1px solid #cc6600; padding:10px; margin-bottom:15px;"> '''Lab 2: Interfaces, Firewall Rules, and Aliases'''<br> This hands-on lab covers configuring the HQ DMZ interface, building firewall rules, creating aliases, and applying restrictive access policies. All configuration is performed on '''fw1-HQ''' at <code>https://172.17.1.1</code>. </div> == Prerequisites == * Lab topology from Training_Lab_1:_Initial_Confi..."

__NOTOC__

<div style="background-color:#fff3e6; border:1px solid #cc6600; padding:10px; margin-bottom:15px;">
'''Lab 2: Interfaces, Firewall Rules, and Aliases'''<br>
This hands-on lab covers configuring the HQ DMZ interface, building firewall rules, creating aliases, and applying restrictive access policies. All configuration is performed on '''fw1-HQ''' at <code>https://172.17.1.1</code>.
</div>

== Prerequisites ==

* Lab topology from [[Training_Lab_1:_Initial_Configuration|Training Lab 1]] is in place
* '''HQ LAN:''' <code>172.17.1.0/24</code>
* '''HQ DMZ:''' <code>172.17.2.0/24</code>
* Access to fw1-HQ web interface and VPN connection

== Lab Overview ==

This lab starts with configuring the DMZ interface at HQ, going through the steps to assign and configure a new interface. This new interface will be used as an example of configuring an additional internal interface treated as a DMZ, with significant restrictions to the other internal networks.

Then we'll go through use cases and examples for firewall rules and aliases. Some firewall rules come in the context of NAT, which is covered in a later lab.

== Exercise 1: Configure the DMZ Interface ==

=== Step 1: Review Interface Assignments ===

Browse to '''Interfaces > Assign'''.

The firewall's interfaces are assigned in order, from <code>vtnet0</code> to <code>vtnet4</code>. Our DMZ interface will be '''OPT1''', which is assigned to <code>vtnet2</code>.

=== Step 2: Enable and Configure OPT1 ===

Browse to '''Interfaces > OPT1''' and configure:

{| class="wikitable"
! Setting
! Value
|-
| Enable
| ✓ Checked
|-
| Description
| DMZ
|-
| IPv4 Configuration Type
| Static IPv4
|-
| IPv4 Address
| 172.17.2.1/24
|}

'''Save and Apply Changes.'''

After saving, OPT1 is still the underlying identifier in <code>config.xml</code>, but the interface is displayed as '''DMZ'''.

== Exercise 2: Test Connectivity to DMZ ==

=== Ping the DMZ Gateway ===

From the HQ-Client VM:

<pre>
training@hq-client:~$ ping 172.17.2.1
PING 172.17.2.1 (172.17.2.1) 56(84) bytes of data.
64 bytes from 172.17.2.1: icmp_seq=1 ttl=64 time=0.298 ms
64 bytes from 172.17.2.1: icmp_seq=2 ttl=64 time=0.979 ms
64 bytes from 172.17.2.1: icmp_seq=3 ttl=64 time=1.27 ms
</pre>

=== Ping server1 from HQ-Client ===

<pre>
training@hq-client:~$ ping -c 5 172.17.2.10
PING 172.17.2.10 (172.17.2.10) 56(84) bytes of data.
64 bytes from 172.17.2.10: icmp_seq=1 ttl=63 time=0.711 ms
64 bytes from 172.17.2.10: icmp_seq=2 ttl=63 time=1.75 ms
...
5 packets transmitted, 5 received, 0% packet loss
</pre>

This ping traverses two virtual networks, so latency is roughly doubled. Steady replies indicate good connectivity.

== Exercise 3: Connectivity from DMZ Network ==

=== Verify Default Block Behavior ===

Newly-added interfaces have '''no firewall rules by default'''. All traffic initiated on that interface is blocked.

Log in to server1 via SSH from HQ-client:

<pre>
training@hq-client:~$ ssh training@172.17.2.10
Password for training@server1: password
</pre>

From server1, attempt to ping:

<pre>
training@server1:~ % ping -c 5 172.17.2.1
PING 172.17.2.1 (172.17.2.1): 56 data bytes
--- 172.17.2.1 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

training@server1:~ % ping google.com
ping: cannot resolve google.com: Host name lookup failure
</pre>

=== Troubleshooting: Check ARP Cache ===

Check the ARP cache to confirm Layer 2 connectivity:

<pre>
training@server1:~ % arp -an
? (172.17.2.10) at 08:00:27:ec:c0:6b on em0 permanent [ethernet]
? (172.17.2.1) at 08:00:27:59:b4:35 on em0 expires in 139 seconds [ethernet]
</pre>

A valid MAC address for the gateway confirms the server is on the correct network segment. An '''incomplete''' entry indicates a Layer 2 issue.

=== Check Firewall Logs ===

Browse to '''Status > System Logs > Firewall''' on fw1-HQ to see blocked traffic.

=== Add Temporary Allow-All Rule ===

On '''Firewall > Rules > DMZ''', add a temporary rule:

{| class="wikitable"
! Setting
! Value
|-
| Action
| Pass
|-
| Interface
| DMZ
|-
| Protocol
| any
|-
| Source
| any
|-
| Destination
| any
|}

'''Save and Apply Changes.'''

Verify connectivity from server1:

<pre>
training@server1:~ % ping -c 3 172.17.2.1
training@server1:~ % ping -c 3 google.com
training@server1:~ % ping -c 3 172.17.1.100
</pre>

All three should succeed with the allow-all rule in place.

== Exercise 4: Create Aliases ==

Aliases ease management by grouping IPs, networks, or ports.

Browse to '''Firewall > Aliases'''.

=== Alias: PrivateNetworks ===

{| class="wikitable"
! Field
! Value
|-
| Name
| PrivateNetworks
|-
| Description
| All RFC1918 private IP space
|-
| Type
| Network
|-
| Members
| 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
|}

=== Alias: server1 ===

{| class="wikitable"
! Field
! Value
|-
| Name
| server1
|-
| Description
| server1.example.com
|-
| Type
| Host
|-
| Member
| 172.17.2.10
|}

=== Alias: server2 ===

{| class="wikitable"
! Field
! Value
|-
| Name
| server2
|-
| Description
| server2.example.com
|-
| Type
| Host
|-
| Member
| 172.17.2.20
|}

=== Alias: DNSservers ===

{| class="wikitable"
! Field
! Value
|-
| Name
| DNSservers
|-
| Type
| Host
|-
| Members
| server1, server2
|}

=== Alias: SMTPservers ===

{| class="wikitable"
! Field
! Value
|-
| Name
| SMTPservers
|-
| Description
| authorized outbound SMTP servers
|-
| Type
| Host
|-
| Members
| server1
|}

=== Alias: RemoteAdmin ===

{| class="wikitable"
! Field
! Value
|-
| Name
| RemoteAdmin
|-
| Description
| IPs authorized for remote management
|-
| Type
| Host
|-
| Members
| 192.0.2.100 (student's system)
|}

=== Alias: WebServers ===

{| class="wikitable"
! Field
! Value
|-
| Name
| WebServers
|-
| Description
| publicly-reachable web servers
|-
| Type
| Host
|-
| Members
| server1, server2
|}

=== Alias: WebPorts ===

{| class="wikitable"
! Field
! Value
|-
| Name
| WebPorts
|-
| Description
| allowed ports to public web servers
|-
| Type
| Ports
|-
| Members
| 80, 443
|}

'''Save each alias, then Apply Changes.'''

== Exercise 5: Allow Remote Firewall Administration ==

Add a rule on '''Firewall > Rules > WAN''':

{| class="wikitable"
! Setting
! Value
|-
| Interface
| WAN
|-
| Protocol
| any
|-
| Source
| Single host or alias — RemoteAdmin
|-
| Destination
| WAN address
|-
| Description
| allow all from remote admin IPs
|}

'''Save and Apply Changes.'''

Verify from your host:

<pre>
$ ping 192.0.2.2
$ curl -I https://192.0.2.2
</pre>

== Exercise 6: Configure Restrictive DMZ Rules ==

Remove the temporary allow-all rule (or ensure it is at the top, to be deleted later). Then add the following rules in order using the '''Add''' button (add to bottom):

=== Rule 1: Allow Ping to Firewall DMZ IP ===

{| class="wikitable"
! Setting
! Value
|-
| Action
| Pass
|-
| Interface
| DMZ
|-
| Protocol
| ICMP
|-
| ICMP Type
| Echo request
|-
| Source
| DMZ net
|-
| Destination
| DMZ address
|-
| Description
| Allow ping to firewall's DMZ IP
|}

=== Rule 2: Allow DNS to DMZ IP ===

{| class="wikitable"
! Setting
! Value
|-
| Action
| Pass
|-
| Interface
| DMZ
|-
| Protocol
| TCP/UDP
|-
| Source
| DMZ net
|-
| Destination
| DMZ address
|-
| Destination Port
| DNS (53)
|-
| Description
| Allow DNS lookups to DNS Resolver
|}

=== Rule 3: Reject All Else to Private Networks ===

{| class="wikitable"
! Setting
! Value
|-
| Action
| Reject
|-
| Interface
| DMZ
|-
| Protocol
| any
|-
| Source
| any
|-
| Destination
| Single host or alias — PrivateNetworks
|-
| Log
| ✓ Checked
|-
| Description
| Reject all else from DMZ to private networks
|}

This prevents DMZ hosts from reaching any other internal services and logs blocked attempts.

=== Rule 4: Allow DNS Outbound to Internet ===

{| class="wikitable"
! Setting
! Value
|-
| Action
| Pass
|-
| Interface
| DMZ
|-
| Protocol
| TCP/UDP
|-
| Source
| Single host or alias — DNSservers
|-
| Destination
| any
|-
| Destination Port
| DNS (53)
|-
| Description
| Allow recursive queries from DNS servers to Internet
|}

=== Rule 5: Allow SMTP Outbound to Internet ===

{| class="wikitable"
! Setting
! Value
|-
| Action
| Pass
|-
| Interface
| DMZ
|-
| Protocol
| TCP
|-
| Source
| Single host or alias — SMTPservers
|-
| Destination
| any
|-
| Destination Port
| SMTP (25)
|-
| Description
| Allow SMTP servers to send to Internet
|}

=== Rule 6: Allow HTTP Outbound for Management (Disabled) ===

{| class="wikitable"
! Setting
! Value
|-
| Action
| Pass
|-
| Disabled
| ✓ Checked
|-
| Interface
| DMZ
|-
| Protocol
| TCP
|-
| Source
| DMZ net
|-
| Destination
| any
|-
| Destination Port
| HTTP (80)
|-
| Description
| Management — temp allow HTTP outbound from servers
|}

This rule is disabled by default and should only be enabled during updates.

'''Save and Apply Changes after each rule.'''

== Exercise 7: Verify Restrictive Ruleset ==

=== Review Rule Order ===

Ensure the temporary allow-all rule is at the top. With it at the top, all traffic matches it first and the restrictive rules are ineffective.

From server1, start a constant ping to HQ-client:

<pre>
training@server1:~ % ping 172.17.1.100
</pre>

Replies confirm the allow-all rule is passing traffic.

=== Delete Allow-All Rule ===

Delete the temporary allow-all rule and '''Apply Changes'''.

The restrictive ruleset is now enforced for all '''new''' connections. The running ping is still permitted because the firewall is stateful — already-permitted connections are never re-evaluated.

=== Kill the Ping State ===

Browse to '''Diagnostics > States'''. Filter for <code>172.17.2.10:</code> (note the colon to avoid matching similar IPs). Click the '''✕''' symbol next to the ping state to delete it.

The ping stops immediately.

=== Check Firewall Logs ===

Browse to '''Status > System Logs > Firewall'''. Log entries show the blocked traffic.

Click the red '''X''' in the Action column on a log entry to see which rule blocked the connection. User-defined rules show <code>USER_RULE</code> with the configured description.

== Troubleshooting Reference ==

{| class="wikitable"
! Symptom
! Likely Cause
! Resolution
|-
| Cannot ping gateway from DMZ host
| No firewall rules on DMZ interface
| Add pass rule or verify existing rules
|-
| Cannot resolve DNS from DMZ
| DNS port blocked; no DNS rule
| Add TCP/UDP pass rule to DMZ address port 53
|-
| Can reach Internet but not HQ LAN
| Reject rule to PrivateNetworks is working
| Verify rule order and alias contents
|-
| Ping stops after deleting allow-all rule
| Stateful firewall; existing state was killed
| Expected behavior — new connections follow current rules
|-
| Cannot SSH to server1
| Layer 2 / ARP issue or VPN problem
| Check <code>arp -an</code> on server1; verify MAC address
|-
| Firewall web UI unreachable from WAN
| No WAN allow rule for remote admin
| Add WAN rule with RemoteAdmin alias as source
|}

== IP Addressing Quick Reference ==

{| class="wikitable"
! Host / Network
! IP Address / Range
|-
| fw1-HQ LAN
| 172.17.1.1/24
|-
| fw1-HQ DMZ
| 172.17.2.1/24
|-
| fw1-HQ WAN
| 192.0.2.2
|-
| HQ-Client
| 172.17.1.100
|-
| server1
| 172.17.2.10
|-
| server2
| 172.17.2.20
|-
| RemoteAdmin
| 192.0.2.100
|-
| HQ LAN Network
| 172.17.1.0/24
|-
| HQ DMZ Network
| 172.17.2.0/24
|}

== Lab Completion Checklist ==

* [ ] DMZ interface enabled and configured (172.17.2.1/24)
* [ ] Connectivity tested from HQ-Client to DMZ
* [ ] Default block behavior verified from DMZ
* [ ] Aliases created (PrivateNetworks, DNSservers, SMTPservers, RemoteAdmin, WebServers, WebPorts, server1, server2)
* [ ] Remote admin rule added on WAN
* [ ] Restrictive DMZ rules configured and applied
* [ ] Stateful behavior demonstrated (ping continues after rule change, stops after state kill)
* [ ] Firewall logs reviewed and interpreted

This concludes Lab 2.

----

'''Previous Module:''' [[Training:_Interfaces_and_Firewall_Rules|Section 2 — Interfaces and Firewall Rules]]

''Source: Netgate FUND001-LIVE-Lab2-Rules.pdf''

Training: Interfaces and Firewall Rules

2026-04-23T06:58:28Z

Justinaquino: Created page with "__NOTOC__ <div style="background-color:#e6f3ff; border:1px solid #0066cc; padding:10px; margin-bottom:15px;"> '''Module: FUND001-LIVE Section 2 — Interfaces, VIPs, and Firewall Rules'''<br> This training module covers pfSense interface configuration, Virtual IP types, firewall rules, aliases, and best practices for rule management. </div> == Learning Objectives == By the end of this module, you will be able to: * Understand OS interface names versus pfSense interfa..."

__NOTOC__

<div style="background-color:#e6f3ff; border:1px solid #0066cc; padding:10px; margin-bottom:15px;">
'''Module: FUND001-LIVE Section 2 — Interfaces, VIPs, and Firewall Rules'''<br>
This training module covers pfSense interface configuration, Virtual IP types, firewall rules, aliases, and best practices for rule management.
</div>

== Learning Objectives ==

By the end of this module, you will be able to:

* Understand OS interface names versus pfSense interface identifiers
* Configure and manage interfaces in pfSense
* Identify and apply appropriate Virtual IP (VIP) types
* Create and manage firewall rules with proper ordering
* Use aliases to simplify and streamline rulesets
* Apply firewall best practices and troubleshooting techniques

== Interfaces ==

=== OS Interface Names vs. Interface Identifiers ===

In pfSense, network interfaces have two naming conventions:

* '''OS Interface Names''' — Physical or virtual NIC names assigned by the operating system (e.g., <code>igb0</code>, <code>re1</code>, <code>ixl2</code>)
* '''Interface Identifiers''' — User-friendly labels assigned within pfSense (e.g., <code>LAN</code>, <code>WAN</code>, <code>OPT1</code>)

Key tasks:
* Interface Assignments — mapping OS names to pfSense identifiers
* Configuring Interfaces — setting IP addresses, enabling/disabling, and renaming

== Virtual IPs (VIPs) ==

Virtual IPs allow multiple IP addresses to be assigned to a single interface.

=== VIP Types ===

{| class="wikitable"
! VIP Type
! MAC Address Binding
! NAT Service
! ARP
! HA
! Ping
! Single/Range
|-
| IP Alias
| Parent NIC
| Yes
| Yes
| Yes
| Yes
| Single
|-
| CARP
| Shared vMAC
| Yes
| Yes
| Yes
| Yes
| Single
|-
| Proxy ARP
| Parent NIC
| Yes
| No
| No
| No
| Either
|-
| Other
| N/A
| No
| No
| Yes
| No
| Either
|}

* '''IP Alias''' — Most common type; binds additional IPs to the parent NIC
* '''CARP''' — Used for high availability; shares a virtual MAC address between redundant firewalls
* '''Proxy ARP''' — Responds to ARP requests on behalf of another IP; no service binding
* '''Other''' — For miscellaneous purposes such as 1:1 NAT without ARP

== Firewall Rules ==

=== Core Concepts ===

* Rules apply '''inbound''' on the interface where traffic is sourced
* '''First match wins''' — all subsequent rules are ignored for matching traffic
* '''Stateful filtering''' — pfSense tracks connection states automatically
* Actions: '''Pass''', '''Block''', and '''Reject'''

=== Default Rules ===

The following default rules are present on a new installation:

* '''Block private networks''' — Blocks RFC 1918 traffic on WAN
* '''Block bogon networks''' — Blocks unassigned/reserved IP space
* '''Anti-lockout rule''' — Prevents administrators from locking themselves out
* '''Default LAN Allow rule''' — Permits all outbound traffic from LAN

=== Rule Evaluation Order ===

# Floating Rules
# Interface Group Rules
# Single Interface Rules

=== Floating Rules ===

* Can apply to '''all interfaces'''
* Checked '''first''' in evaluation order
* Extra '''"match"''' action available
* Can set traffic attributes (limiters, queues, etc.)
* '''Not meant for regular access rules''' — primarily for traffic-shaping and advanced filtering

=== Interface Groups ===

* Association of multiple interfaces
* '''Shared firewall ruleset''' across grouped interfaces
* Eliminates need to duplicate rules between interfaces

=== Advanced Settings ===

Firewall rules support numerous advanced options:

* Source OS (TCP only)
* Diffserv Code Point (DSCP)
* State type
* TCP flags
* No XMLRPC Sync
* 802.1p
* Schedule
* Gateway
* Limiters (In/Out)
* ACK queue / Queue

== Aliases ==

Aliases simplify firewall rule management by grouping IPs, networks, hostnames, or ports under a single name.

=== Benefits ===

* Ease management
* Faster, less error-prone updates
* Shorter, more manageable rulesets

=== Configuration Options ===

* Statically configured
* URL — one-time import, suitable for small lists
* URL table — configurable update frequency, supports large and small lists
* Nesting of aliases (aliases within aliases)
* Bulk import

== Best Practices ==

* Follow '''default deny philosophy''' — allow only what is required, block all else
* Keep rulesets '''short and clean'''
* '''Periodic review''' of rules (recommended: quarterly)
* Remember rules apply on the '''interface where traffic is sourced'''
* Use '''aliases''' extensively in your rules

== Troubleshooting ==

When diagnosing firewall issues:

* Remember: '''first match wins'''
* Verify rules apply on the correct interface
* '''Enable logging''' on suspect rules
* Check '''states''' (Diagnostics > States)
* Review '''System Logs > Firewall''' for blocked traffic

== Summary ==

{| class="wikitable"
! Key Takeaway
! Details
|-
| VIP Selection
| Use appropriate VIP types (IP Alias, CARP, Proxy ARP) based on needs
|-
| Rule Ordering
| Evaluation order: Floating → Interface Group → Single Interface
|-
| Aliases
| Use aliases to keep rulesets manageable and reduce errors
|-
| Review Schedule
| Check rules quarterly for accuracy and relevance
|-
| Interface Awareness
| Rules apply on the interface where traffic is sourced
|-
| Floating Rules
| Primarily for traffic-shaping, not regular access control
|}

This concludes Section 2.

----

'''Next Module:''' [[Training_Lab_2:_Firewall_Rules_and_Aliases|Lab 2 — Firewall Rules and Aliases]]

''Source: Netgate FUND001-LIVE-SLIDE-SEG2-RULES.pdf''

Training Lab 1: Introduction and Backup Restore

2026-04-23T06:52:40Z

Justinaquino: Convert FUND001 Lab1 to wiki training lab

__NOTOC__
<div style="background:#e8f5e9; border:1px solid #a5d6a7; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Hands-On Lab: Phase 1, Day 2''' — Lab Environment Introduction, Initial Configuration, Backup and Restore. Based on Netgate FUND001-LIVE-Lab1-Intro.
</div>

== Learning Objectives ==
By the end of this lab, you will be able to:
* Navigate the virtual lab environment and understand its topology
* Complete the pfSense setup wizard
* Verify basic connectivity through the firewall
* Create manual configuration backups
* Enable and configure AutoConfigBackup
* Restore a previous configuration from web interface and console

== Lab Environment Overview ==
This lab uses a simulated corporate network with headquarters (HQ) and one branch office.

'''Network Topology:'''
* '''4 firewalls''' — fw1-HQ, fw2-HQ (HA pair), fw1-branch, lab-internet-router
* '''2 desktops''' — HQ-client, Branch-client
* '''2 servers''' — server1, server2 (DMZ)
* '''1 simulated Internet host''' — RemoteHost
* '''8 total networks''' — WAN, LAN, DMZ, sync, remote access, branch LAN, etc.

'''Lab access:'''
In the Netgate original lab, desktops are accessed via NoVNC at http://100.64.0.100/remote. In Comfac's virtual lab, you will access your student sandbox through the NoVNC portal.

== IP Addressing Scheme ==
'''Public/"Internet" IPs (RFC 5737 documentation ranges):'''
{| class="wikitable"
! Subnet !! Assignment
|-
| 192.0.2.0/24 || HQ WAN
|-
| 198.51.100.0/24 || HQ WAN2
|-
| 203.0.113.0/24 || Branch WAN
|-
| 100.64.0.0/24 || Remote Internet (CGNAT range)
|}

'''Private Internal IPs (RFC 1918):'''
{| class="wikitable"
! Subnet !! Assignment
|-
| 172.17.1.0/24 || HQ LAN
|-
| 172.17.2.0/24 || HQ DMZ
|-
| 172.17.3.0/24 || HQ Sync (HA)
|-
| 172.17.4.0/24 || HQ Remote Access OpenVPN
|-
| 172.17.5.0/24 || HQ Remote Access IPsec
|-
| 172.17.6.0/24 || OpenVPN Site-to-Site tunnel
|-
| 172.18.1.0/24 || Branch LAN
|}

'''Why use obscure subnets?''' Using 172.17.x.x instead of common 192.168.1.x minimizes VPN conflicts when remote users connect from home networks.

== Firewall VM Details ==
'''Default credentials for all firewalls:'''
* Username: '''admin'''
* Password: '''netgate'''

=== fw1-HQ (Primary HQ Firewall) ===
{| class="wikitable"
! Interface !! Assignment !! Initial IP !! HA IP (later)
|-
| vtnet0 || WAN || 192.0.2.2 || no change
|-
| vtnet1 || LAN || 172.17.1.1 || 172.17.1.2
|-
| vtnet2 || DMZ || 172.17.2.1 || 172.17.2.2
|-
| vtnet3 || WAN2 || 198.51.100.2 || no change
|-
| vtnet4 || Sync || 172.17.3.2 || no change
|}

=== fw2-HQ (Secondary HQ Firewall) ===
Initially inactive; configured in Advanced/HA lab later.
* WAN: 192.0.2.3
* LAN: 172.17.1.3
* DMZ: 172.17.2.3
* WAN2: 198.51.100.3
* Sync: 172.17.3.3

=== fw1-branch (Branch Office Firewall) ===
* WAN: 203.0.113.10
* LAN: 172.18.1.1

=== lab-internet-router (Simulated ISP) ===
Represents 4 ISP routers + Internet. Pre-configured; no lab changes needed.
* HQ-WAN1: 192.0.2.1
* HQ-WAN2: 198.51.100.1
* Branch-WAN: 203.0.113.1
* Remote Internet: 100.64.0.1

== Client & Server VMs ==
'''HQ-client (Xubuntu Linux desktop):'''
* IP: 172.17.1.100
* Credentials: training / password
* Purpose: Primary management workstation

'''Branch-client (Xubuntu Linux desktop):'''
* IP: 172.18.1.100
* Credentials: training / password

'''Internet host / RemoteHost (Xubuntu):'''
* IP: 100.64.0.50
* Credentials: training / password
* Purpose: Simulated external client + web server for testing

'''server1 & server2 (FreeBSD):'''
* server1: 172.17.2.10
* server2: 172.17.2.20
* Credentials: training / password (root: password)
* Pre-configured with nginx/PHP and BIND DNS

== Exercise 1: Initial Setup Wizard ==
'''Prerequisites:''' Your student environment should have fw1-HQ and HQ-client running.

'''Steps:'''
# From HQ-client, open browser and navigate to https://172.17.1.1
# Accept the self-signed certificate warning
# Log in with admin / netgate
# The setup wizard will launch automatically

'''Wizard configuration:'''
# '''General Information''' — Leave defaults (hostname: fw1-hq.example.com, DNS: lab-internet-router)
# '''Time Information''' — Leave NTP server as 0.pfsense.pool.ntp.org; set timezone as needed (e.g., Asia/Manila)
# '''WAN Configuration''' — Verify static IP: 192.0.2.2/24, gateway 192.0.2.1
#* '''Important:''' Leave "Block bogon networks" and "Block private networks" unchecked (these are documentation IPs, not real public IPs)
# '''LAN Configuration''' — Verify 172.17.1.1/24
# '''Admin Password''' — Change to a secure password (or leave default for lab)
# '''Reload''' — Click Reload to apply settings

'''Verification:'''
* HQ-client should be able to browse the real Internet through NAT
* Try browsing to any external website to confirm

== Exercise 2: Manual Configuration Backup ==
# Browse to Diagnostics -> Backup & Restore
# Click Download configuration as XML
# Save the config.xml file to HQ-client
# '''What this contains:''' Entire system configuration — interfaces, rules, NAT, users, certificates, etc.

== Exercise 3: Config History ==
# Stay on Diagnostics -> Backup & Restore
# Click the Config History tab
# You should see at least one revision (from the setup wizard)
# Click the diff icon to compare two revisions
# This shows exactly what changed between configurations

== Exercise 4: AutoConfigBackup (ACB) ==
AutoConfigBackup is Netgate's encrypted cloud backup service. Every configuration change is automatically backed up offsite.

'''Preparation (lab-specific step):'''
# Go to Diagnostics -> Command Prompt
# Run: rm /etc/ssh/ssh_host_* && /etc/rc.restart_sshd
# This regenerates SSH keys for ACB compatibility in the lab environment
#* ''Note: Not needed in production environments''

'''Enable ACB:'''
# Go to Services -> AutoConfigBackup
# Check Enable ACB
# Enter an encryption password (remember this!)
# Optional: Add a plain-text identifier to help Netgate support locate your backups
# Click Save

'''Verify backup:'''
# Click the Backup Now tab -> Backup
# Go to Restore tab — your backup should appear in the list
# Note your Device ID — save it securely with your encryption password

'''Important:''' If you lose the encryption password, backups are unrecoverable. If you lose the Device ID, Netgate support can help locate it using your identifier.

== Exercise 5: Configuration Restore ==
'''Scenario:''' You misconfigured something and need to roll back.

'''Method A — Web Interface (if you can still reach it):'''
# Diagnostics -> Backup & Restore -> Config History
# Find the revision before your mistake
# Click Restore

'''Method B — AutoConfigBackup (longer history):'''
# Services -> AutoConfigBackup -> Restore tab
# Select a previous backup
# Click Restore

'''Method C — Console (emergency, no web access):'''
# Access console via SSH or physical access
# Choose option 15: "Restore recent configuration"
# Choose option 1 to view recent configs
# Choose option 2 to restore a specific revision
# Enter the revision number
# Confirm with Y
# Reboot (option 5) to ensure clean application

== Troubleshooting ==
{| class="wikitable"
! Problem !! Solution
|-
| Can't reach https://172.17.1.1 || Check HQ-client IP (should be DHCP 172.17.1.x); verify cable/VLAN
|-
| Wizard doesn't start || Already completed; go to System -> Setup Wizard to re-run
|-
| No Internet from HQ-client || Verify WAN IP/gateway; check lab-internet-router is running
|-
| ACB won't enable || Run SSH key regeneration command first
|-
| Restore fails || Ensure restoring to equal or newer version; check encryption password
|}

== Verification Checklist ==
Before finishing this lab, confirm:
* [ ] Setup wizard completed successfully
* [ ] HQ-client can browse Internet
* [ ] Manual config backup downloaded
* [ ] Config History shows revisions
* [ ] AutoConfigBackup enabled and backup completed
* [ ] Device ID recorded
* [ ] Successfully restored a previous configuration (optional practice)

== Key Takeaways ==
* The lab simulates a real multi-site corporate network
* Using RFC 5737 documentation IPs prevents accidentally affecting real networks
* Always backup before making changes
* AutoConfigBackup provides 100 revisions of encrypted offsite backups
* Console restore (option 15) is your emergency recovery method

== Next Module ==
* [[Training: Interfaces and Firewall Rules]] — Phase 1, Day 3
* [[Training Lab 2: Firewall Rules and Aliases]] — Hands-on lab

----
''Source: Netgate FUND001-LIVE-Lab1-Intro.pdf''
''Comfac Virtual Lab Adaptation: VMs provisioned via Ansible; NoVNC access through student portal''

Training: pfSense Introduction

2026-04-23T06:50:06Z

Justinaquino: Convert FUND001 SEG1 Introduction slides to wiki training module

__NOTOC__
<div style="background:#e3f2fd; border:1px solid #90caf9; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Training Module: Phase 1, Day 1''' — Introduction to pfSense Plus. Based on Netgate FUND001-LIVE-SLIDE-SEG1.
</div>

== Learning Objectives ==
By the end of this module, you will be able to:
* Explain what pfSense Plus is and its core value proposition
* Describe the project history and difference between pfSense CE and pfSense Plus
* Identify supported platforms and hardware requirements
* Perform initial setup using the web-based setup wizard
* Create and restore configuration backups
* Understand upgrade procedures and risks

== What is pfSense Plus? ==
pfSense Plus is a commercial, FreeBSD-based network firewall and routing platform developed by Netgate. It ties together multiple open-source networking components into a unified, entirely web-managed system.

'''Key Characteristics:'''
* '''FreeBSD-based''' — Uses the same trusted OS platform as Juniper, NetApp, Citrix, and Netflix
* '''Web-managed''' — Complete configuration through a browser-based GUI; no CLI required for day-to-day tasks
* '''Feature-rich''' — Richer feature set than most commercial firewalls at a fraction of the cost
* '''Open source core''' — Built on open-source components (pf, OpenVPN, WireGuard, etc.) made easy to use

== Project History ==
{| class="wikitable"
! Year !! Milestone
|-
| 2004 || Project started as a fork of m0n0wall
|-
| Feb 2008 || pfSense 1.2 released (FreeBSD 6.2)
|-
| Sept 2011 || pfSense 2.0 released (FreeBSD 8.1)
|-
| Oct 2017 || pfSense 2.4 released (FreeBSD 11.1)
|-
| Feb 2021 || '''pfSense Plus 21.02''' forks from pfSense CE; commercial-only; adds WireGuard
|}

'''pfSense Plus vs pfSense CE:'''
* '''pfSense Plus''' — Commercial license; available on Netgate hardware or Home+Lab (non-commercial); receives updates first
* '''pfSense CE''' — Community Edition; open source; free for all uses

== Platforms & Hardware ==
'''Installation Media:'''
* Full installer (CD or USB memstick)
* 64-bit only
* No Live CD or NanoBSD (deprecated)

'''Hardware Options:'''
# '''Netgate Official Hardware''' — Pre-installed, pre-configured, fully optimized
# '''DIY/Custom Build''' — Check compatibility list at [https://docs.netgate.com/pfsense/en/latest/hardware docs.netgate.com]
# '''Home+Lab Edition''' — Free for non-commercial use; available from [https://www.pfsense.org/downloads pfsense.org]

'''Key hardware considerations:'''
* CPU selection (AES-NI support recommended for VPN performance)
* NIC quality and driver support (Intel i210/i350 preferred)
* RAM (1 GB minimum; 2+ GB for packages/VPN)
* Storage (SSD recommended; 8 GB minimum)

== Initial Setup ==
'''Default LAN configuration:'''
* LAN IP: '''192.168.1.1/24'''
* DHCP server enabled on LAN
* Web interface: '''https://192.168.1.1'''
* Default credentials: '''admin / pfsense'''

'''Setup Wizard steps:'''
# Connect to LAN port; obtain DHCP address
# Browse to https://192.168.1.1
# Log in with default credentials
# Complete wizard: General Info → Time Server → WAN Config → LAN Config → Admin Password → Reload

'''Important:''' Always change the default admin password in production.

== Configuration Backup & Restore ==
'''Why back up?'''
* Hardware failure recovery
* Pre-upgrade safety net
* Configuration migration to new hardware
* Rollback after misconfiguration

'''Backup methods:'''
{| class="wikitable"
! Method !! Location !! Retention !! Notes
|-
| Manual download || Diagnostics → Backup/Restore || N/A (local file) || Full config.xml download
|-
| Config History || Diagnostics → Backup/Restore → Config History || 30 revisions (configurable) || Local to device
|-
| AutoConfigBackup (ACB) || Services → AutoConfigBackup || 100 revisions || Cloud backup; encrypted
|}

'''Backup best practices:'''
* Always backup '''before''' upgrades
* Store encryption password and Device ID safely (for ACB)
* Never restore to an '''older''' pfSense version; only equal or newer
* When restoring to different hardware, interface assignments will differ

'''Console restore (emergency):'''
* Option 15 at console menu — "Restore recent configuration"
* Useful when web interface is unreachable
* May require reboot after restore

== Upgrades ==
'''Pre-upgrade checklist:'''
# Create configuration backup
# Read release notes
# Check upgrade guide at [https://docs.netgate.com/pfsense/en/latest/install/upgrade-guide.html docs.netgate.com]
# Verify auto-upgrade URL (for Plus)

'''Upgrade methods:'''
* '''Auto-Update''' — Web GUI: System → Update
* '''Console Update''' — Option 13 at console menu

'''Upgrade risks (rare but possible):'''
* Hardware failure during reboot
* Package complications
* Hardware-specific regressions
* Dependency on bug fixes from current version

== Key Takeaways ==
* pfSense Plus is commercial-only; Home+Lab available for non-commercial use
* Always check hardware compatibility before DIY builds
* '''Backup before every upgrade''' — non-negotiable
* Restore only to equal or newer versions
* Use AutoConfigBackup for offsite, encrypted cloud backups
* Keep encryption password and Device ID in a safe place

== Quiz (Self-Check) ==
# What operating system is pfSense Plus based on?
# What is the difference between pfSense Plus and pfSense CE?
# Why should you avoid restoring a backup to an older pfSense version?
# Where do you find the Config History feature?
# What two pieces of information must you save when using AutoConfigBackup?

== Next Module ==
* [[Training: Interfaces and Firewall Rules]] — Phase 1, Day 2–3
* [[Training Lab 1: Introduction and Backup Restore]] — Hands-on lab

----
''Source: Netgate FUND001-LIVE-SLIDE-SEG1-INTRO.pdf''

Networking PfSense Index

2026-04-23T06:38:23Z

Justinaquino: Add link to PfSense Training Project Tracker

PfSense Training Project Tracker

2026-04-23T06:37:36Z

Justinaquino: Create project tracker for pfSense practical training system implementation

__NOTOC__
<div style="background:#fff8e1; border:1px solid #ffcc80; border-radius:4px; padding:12px 16px; margin-bottom:20px;">
'''Project Tracker''' for Comfac's pfSense Practical Training System implementation. This page tracks all tasks from material conversion to infrastructure deployment and course delivery.
</div>

== Phase 0: Material Conversion (FUND001 → Wiki) ==
Convert all Netgate FUND001 training PDFs into CITWiki pages with detailed summaries. Each wiki page should include: learning objectives, key concepts, step-by-step lab instructions adapted for virtual environment, and troubleshooting tips.

=== Slide Decks ===
* [ ] '''SEG1 — Introduction to pfSense''' → [[Training: pfSense Introduction]]
* [ ] '''SEG2 — Interfaces, VIPs, and Rules''' → [[Training: Interfaces and Firewall Rules]]
* [ ] '''SEG3 — NAT and VIPs''' → [[Training: NAT and Virtual IPs]]
* [ ] '''SEG4 — pfSense Services''' → [[Training: pfSense Services]]
* [ ] '''SEG5 — VPNs and IPsec''' → [[Training: IPsec VPN]]
* [ ] '''SEG6 — OpenVPN''' → [[Training: OpenVPN]]
* [ ] '''SEG7 — WireGuard''' → [[Training: WireGuard]]
* [ ] '''SEG8 — Multi-WAN''' → [[Training: Multi-WAN]]
* [ ] '''SEG9 — Traffic Shaping''' → [[Training: Traffic Shaping]]
* [ ] '''SEG10 — High Availability''' → [[Training: High Availability]]
* [ ] '''SEG11 — Other Features''' → [[Training: Monitoring and Packages]]

=== Labs ===
* [ ] '''Lab 1 — Intro, Getting Started, Backup/Restore''' → [[Training Lab 1: Introduction and Backup Restore]]
* [ ] '''Lab 2 — Interfaces, Firewall Rules, Aliases''' → [[Training Lab 2: Firewall Rules and Aliases]]
* [ ] '''Lab 3 — Virtual IPs and NAT''' → [[Training Lab 3: NAT and Virtual IPs]]
* [ ] '''Lab 4 — Services and Branch Network Setup''' → [[Training Lab 4: Services and Branch Network]]
* [ ] '''Lab 5 — IPsec''' → [[Training Lab 5: IPsec VPN]]
* [ ] '''Lab 6 — OpenVPN''' → [[Training Lab 6: OpenVPN]]
* [ ] '''Lab 7 — WireGuard''' → [[Training Lab 7: WireGuard]]
* [ ] '''Lab 8 — Multi-WAN''' → [[Training Lab 8: Multi-WAN]]
* [ ] '''Lab 9 — Traffic Shaping''' → [[Training Lab 9: Traffic Shaping]]
* [ ] '''Lab 10 — High Availability''' → [[Training Lab 10: High Availability]]

=== Reference Materials ===
* [ ] '''the-pfsense-documentation.pdf''' → Summarize into [[Training: pfSense Complete Reference]] or link as external reference
* [ ] '''WindowsTrainingSupportFiles.zip''' → Extract and document client software requirements ([[Training: Client Software Requirements]])
* [ ] '''Training Videos (4× .mkv)''' → Catalog timestamps and link from relevant wiki pages

== Phase 1: Infrastructure Setup ==
Build the virtual training environment on Comfac's 200-core / 1TB RAM machine.

=== Host Preparation ===
* [ ] '''A.1''' Install Ubuntu Server LTS on 200-core host
* [ ] '''A.2''' Configure KVM/libvirt with storage pools (NVMe for images, SSD for ephemeral clones)
* [ ] '''A.3''' Set up network bridges: `br-mgmt`, `br-lan`, `br-wan`, `br-dmz`, `br-internet`
* [ ] '''A.4''' Configure VLANs for student isolation (one VLAN per student or per lab)
* [ ] '''A.5''' Install and configure Ansible controller (host or container)

=== Base Images ===
* [ ] '''B.1''' Download pfSense CE ISO and create qcow2 golden image (2 vCPU, 1 GB RAM, 8 GB disk)
* [ ] '''B.2''' Create Ubuntu Server 22.04/24.04 golden image (1 vCPU, 1 GB RAM, 10 GB disk)
* [ ] '''B.3''' Create Windows 10/11 thin client golden image (2 vCPU, 4 GB RAM, 40 GB disk) — OR decide to use Linux clients only
* [ ] '''B.4''' Create "Internet Router" golden image (Ubuntu with FRR/Quagga or simple static routes, 1 vCPU, 512 MB RAM)
* [ ] '''B.5''' Test each golden image boots and functions correctly

=== Automation ===
* [ ] '''C.1''' Write Ansible playbook: `lab1-student-env.yml` (1 pfSense + 1 client)
* [ ] '''C.2''' Write Ansible playbook: `lab2-student-env.yml` (1 pfSense + 1 client + 1 server)
* [ ] '''C.3''' Write Ansible playbook: `lab3-student-env.yml` (1 pfSense + 1 server + internet)
* [ ] '''C.4''' Write Ansible playbook: `lab4-student-env.yml` (2 pfSense + 2 clients + 1 server)
* [ ] '''C.5''' Write Ansible playbooks for Labs 5–10 (VPNs, Multi-WAN, Shaping, HA)
* [ ] '''C.6''' Write Ansible playbook: `cleanup-student-env.yml` (destroy VMs, free resources)
* [ ] '''C.7''' Write Ansible playbook: `reset-student-env.yml` (revert to snapshot/linked clone base)
* [ ] '''C.8''' Test all playbooks end-to-end with a single student ID

=== NoVNC Portal ===
* [ ] '''D.1''' Evaluate Kimchi vs Apache Guacamole vs custom NoVNC proxy
* [ ] '''D.2''' Install and configure chosen NoVNC solution
* [ ] '''D.3''' Integrate NoVNC with student authentication (LDAP, local wiki accounts, or simple token-based)
* [ ] '''D.4''' Build student dashboard: list of phases/labs, "Launch Lab" button, countdown timer
* [ ] '''D.5''' Test 5 concurrent NoVNC sessions for stability
* [ ] '''D.6''' Test 20 concurrent NoVNC sessions for performance

== Phase 2: Curriculum Development ==
Design the student-facing training program.

=== Introduction Course (Most Common Use Case) ===
* [ ] '''E.1''' Define "Setting Up a Firewall for Yourself" scope: home office / small business
* [ ] '''E.2''' Write Module 0: Why You Need a Firewall (threats, NAT basics, basic topology)
* [ ] '''E.3''' Write Module 1: Install pfSense on Old PC or VM (hardware requirements, USB install, first boot wizard)
* [ ] '''E.4''' Write Module 2: Basic WAN + LAN Setup (DHCP, DNS, first internet connection)
* [ ] '''E.5''' Write Module 3: Essential Firewall Rules (block incoming, allow outgoing, ICMP)
* [ ] '''E.6''' Write Module 4: Port Forwarding for Common Services (game server, camera, NAS)
* [ ] '''E.7''' Write Module 5: VPN for Remote Access (WireGuard road warrior setup)
* [ ] '''E.8''' Write Module 6: Backup and Updates (config.xml backup, update schedule)
* [ ] '''E.9''' Create hands-on lab for Introduction Course (single pfSense + 1 client VM)
* [ ] '''E.10''' Record or source video walkthroughs for each module

=== Full FUND001 Adaptation ===
* [ ] '''F.1''' Map each SEG slide deck to a wiki training page with summary + key takeaways
* [ ] '''F.2''' Adapt Netgate labs from physical/virtualbox environment to KVM/Ansible environment
* [ ] '''F.3''' Update IP addressing schema for Comfac virtual lab (avoid conflicts with production)
* [ ] '''F.4''' Write pre-lab briefing pages (what you'll learn, expected outcomes)
* [ ] '''F.5''' Write post-lab review pages (common mistakes, verification steps, "show me" checklist)
* [ ] '''F.6''' Create quiz questions for each phase (5–10 questions, auto-graded if possible)

== Phase 3: Pilot & Refinement ==
Run the training with a small group before full rollout.

=== Internal Pilot ===
* [ ] '''G.1''' Recruit 3–5 internal Comfac IT staff as pilot students
* [ ] '''G.2''' Run Phase 1 (Foundations) with pilot group — collect feedback
* [ ] '''G.3''' Run Phase 2 (NAT & Services) with pilot group — collect feedback
* [ ] '''G.4''' Run one VPN lab (IPsec or OpenVPN) with pilot group — test resource limits
* [ ] '''G.5''' Document all bugs, confusion points, and timeouts
* [ ] '''G.6''' Refine playbooks and wiki pages based on pilot feedback

=== Resource Tuning ===
* [ ] '''H.1''' Measure actual CPU/RAM/disk usage per student during pilot
* [ ] '''H.2''' Adjust VM specs if over- or under-provisioned
* [ ] '''H.3''' Test memory overcommit ratios for safe concurrency scaling
* [ ] '''H.4''' Document maximum safe concurrent student count

== Phase 4: Deployment & Operations ==
Prepare for regular training delivery.

=== Student Onboarding ===
* [ ] '''I.1''' Create student onboarding guide (how to access portal, use NoVNC, reset lab)
* [ ] '''I.2''' Create instructor guide (how to monitor progress, assist students, grade labs)
* [ ] '''I.3''' Set up scheduling system (book lab time slots, prevent over-allocation)
* [ ] '''I.4''' Create completion certificates or badges

=== Monitoring & Maintenance ===
* [ ] '''J.1''' Set up host monitoring (Prometheus/Grafana or simple `libvirt` stats)
* [ ] '''J.2''' Configure alerts for host resource exhaustion
* [ ] '''J.3''' Schedule weekly base image updates (pfSense patches, OS updates)
* [ ] '''J.4''' Document disaster recovery (rebuild host from Ansible, restore golden images)

== Quick Status Dashboard ==
{| class="wikitable"
! Phase !! Status !! % Complete !! Blockers
|-
| Phase 0: Material Conversion || 🟡 In Progress || 0% || Need bot/API access for bulk uploads
|-
| Phase 1: Infrastructure Setup || 🔴 Not Started || 0% || Need 200-core host access
|-
| Phase 2: Curriculum Development || 🔴 Not Started || 0% || Waiting on Phase 0 completion
|-
| Phase 3: Pilot & Refinement || 🔴 Not Started || 0% || Waiting on Phase 1 + 2
|-
| Phase 4: Deployment & Operations || 🔴 Not Started || 0% || Waiting on Phase 3
|}

== Resource Summary ==
'''Per-student minimum:''' 6 vCPUs, 6.5 GB RAM, 62 GB disk
'''Per-student full lab:''' 10 vCPUs, 10.5 GB RAM, 110 GB disk
'''200-core / 1TB capacity:''' 20–40 concurrent students (conservative to optimized)

'''Next Actions (This Week):'''
# Start converting FUND001-LIVE-SLIDE-SEG1-INTRO.pdf and FUND001-LIVE-Lab1-Intro.pdf to wiki
# Confirm 200-core host specifications and OS
# Evaluate Kimchi vs Guacamole for NoVNC portal

Networking PfSense Index

2026-04-23T06:36:05Z

Justinaquino: Add Practical Training System (NoVNC Virtual Lab) section with phases, resource estimates, and ZTP/IaC strategy