Vezpi/Blog
1
0
Fork 0
Code Issues 2 Pull Requests Actions Wiki Activity

Auto-update blog content from Obsidian: 2025-10-26 20:56:09
All checks were successful
Blog Deployment / Check-Rebuild (push) Successful in 6s
Details
Blog Deployment / Build (push) Has been skipped
Details
Blog Deployment / Deploy-Staging (push) Successful in 10s
Details
Blog Deployment / Test-Staging (push) Successful in 2s
Details
Blog Deployment / Merge (push) Successful in 7s
Details
Blog Deployment / Deploy-Production (push) Successful in 9s
Details
Blog Deployment / Test-Production (push) Successful in 2s
Details
Blog Deployment / Clean (push) Has been skipped
Details
Blog Deployment / Notify (push) Successful in 3s
Details

Browse Source
This commit is contained in:
Gitea Actions
2025-10-26 20:56:09 +00:00
parent 4178d55075
commit 356d6922d5
3 changed files with 30 additions and 386 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
content/post/13-opnsense-full-configuration.fr.md
View File

@@ -84,7 +84,7 @@ Il est temps de mettre à jour, dans `System` > `Firmware` > `Status`, je v
Une fois mis à jour et redémarré, je vais dans `System` > `Firmware` > `Plugins`, je coche l'option pour afficher les plugins communautaires. J'installe que le **QEMU Guest Agent**, `os-qemu-guest-agent`, pour permettre la communication entre la VM et l'hôte Proxmox. Une fois mis à jour et redémarré, je vais dans `System` > `Firmware` > `Plugins`, je coche l'option pour afficher les plugins communautaires. J'installe que le **QEMU Guest Agent**, `os-qemu-guest-agent`, pour permettre la communication entre la VM et l'hôte Proxmox.
Cela nécessite un arrêt. Dans Proxmox, j'active le `QEMU Guest Agent` dans les options de la VM : Cela nécessite un arrêt. Dans Proxmox, j'active le `QEMU Guest Agent` dans les options de la VM :
![proxmox-opnsense-enable-qemu-guest-agent.png](img/proxmox-opnsense-enable-qemu-guest-agent.png) ![Options d'une VM Proxmox avec QEMU Guest Agent activé](img/proxmox-opnsense-enable-qemu-guest-agent.png)
Finalement je redémarre la VM. Une fois démarrée, depuis la WebGUI de Proxmox, je peux voir les IPs de la VM ce qui confirme que le guest agent fonctionne. Finalement je redémarre la VM. Une fois démarrée, depuis la WebGUI de Proxmox, je peux voir les IPs de la VM ce qui confirme que le guest agent fonctionne.
@@ -92,7 +92,7 @@ Finalement je redémarre la VM. Une fois démarrée, depuis la WebGUI de Proxmox
## Interfaces ## Interfaces
Sur les deux pare‑feu, j'assigne les NIC restantes à de nouvelles interfaces en ajoutant une description. Les VMs ont 7 interfaces, je compare attentivement les adresses MAC pour éviter de mélanger les interfaces : Sur les deux pare‑feu, j'assigne les NIC restantes à de nouvelles interfaces en ajoutant une description. Les VMs ont 7 interfaces, je compare attentivement les adresses MAC pour éviter de mélanger les interfaces :
![opnsense-assign-interfaces.png](img/opnsense-assign-interfaces.png) ![Assign interfaces menu in OPNsense](img/opnsense-assign-interfaces.png)
Au final, la configuration des interfaces ressemble à ceci : Au final, la configuration des interfaces ressemble à ceci :
@@ -160,13 +160,13 @@ La HA est configurée dans `System` > `High Availability` > `Settings`
### Statut de la HA ### Statut de la HA
Dans `System` > `High Availability` > `Status`, je peux vérifier si la synchronisation fonctionne. Sur cette page je peux répliquer un ou tous les services du master vers le nœud backup : Dans `System` > `High Availability` > `Status`, je peux vérifier si la synchronisation fonctionne. Sur cette page je peux répliquer un ou tous les services du master vers le nœud backup :
![opnsense-high-availability-status.png](img/opnsense-high-availability-status.png) ![OPNsense high availability status page](img/opnsense-high-availability-status.png)
--- ---
## IPs Virtuelles ## IPs Virtuelles
Maintenant que la HA est configurée, je peux attribuer à mes réseaux une IP virtuelle partagée entre mes nœuds. Dans `Interfaces` > `Virtual IPs` > `Settings`, je crée un VIP pour chacun de mes réseaux en utilisant **CARP** (Common Address Redundancy Protocol). L'objectif est de réutiliser les adresses IP utilisées par mon instance OPNsense actuelle, mais comme elle route encore mon réseau, j'utilise des IP différentes pour la phase de configuration : Maintenant que la HA est configurée, je peux attribuer à mes réseaux une IP virtuelle partagée entre mes nœuds. Dans `Interfaces` > `Virtual IPs` > `Settings`, je crée un VIP pour chacun de mes réseaux en utilisant **CARP** (Common Address Redundancy Protocol). L'objectif est de réutiliser les adresses IP utilisées par mon instance OPNsense actuelle, mais comme elle route encore mon réseau, j'utilise des IP différentes pour la phase de configuration :
![opnsense-interface-virtual-ips.png](img/opnsense-interface-virtual-ips.png) ![Liste des IPs virtuelles dans OPNsense](img/opnsense-interface-virtual-ips.png)
ℹ️ OPNsense permet CARP par défaut, aucune règle de pare‑feu spéciale requise ℹ️ OPNsense permet CARP par défaut, aucune règle de pare‑feu spéciale requise
@@ -242,7 +242,7 @@ Pour commencer, dans `Firewall` > `Groups`, je crée 2 zones pour regrouper m
### Network Aliases ### Network Aliases
Ensuite, dans `Firewall` > `Aliases`, je crée un alias `InternalNetworks` pour regrouper tous mes réseaux internes : Ensuite, dans `Firewall` > `Aliases`, je crée un alias `InternalNetworks` pour regrouper tous mes réseaux internes :
![opnsense-create-alias-internalnetworks.png](img/opnsense-create-alias-internalnetworks.png) ![Création d'alias pour les réseaux locaux dansOPNsense](img/opnsense-create-alias-internalnetworks.png)
### Règles de Pare-feu Rules ### Règles de Pare-feu Rules
@@ -345,17 +345,17 @@ Sur le nœud backup, je le configure de la même manière, la seule différence
### Plages DHCP ### Plages DHCP
Ensuite je configure les plages DHCP. Les deux pare‑feu auront des plages différentes, le nœud backup aura des plages plus petites (10 baux devraient suffire). Sur le master, elles sont configurées comme suit : Ensuite je configure les plages DHCP. Les deux pare‑feu auront des plages différentes, le nœud backup aura des plages plus petites (10 baux devraient suffire). Sur le master, elles sont configurées comme suit :
![opnsense-dnsmasq-dhcp-ranges.png](img/opnsense-dnsmasq-dhcp-ranges.png) ![OPNsense DHCP ranges in Dnsmasq](img/opnsense-dnsmasq-dhcp-ranges.png)
### Options DHCP ### Options DHCP
Puis je définis quelques options DHCP pour chaque domaine : le `router`, le `dns-server` et le `domain-name`. Je pointe les adresses IP vers la VIP de l'interface : Puis je définis quelques options DHCP pour chaque domaine : le `router`, le `dns-server` et le `domain-name`. Je pointe les adresses IP vers la VIP de l'interface :
![opnsense-dnsmasq-dhcp-options.png](img/opnsense-dnsmasq-dhcp-options.png) ![OPNsense DHCP options in Dnsmasq](img/opnsense-dnsmasq-dhcp-options.png)
### Hôtes ### Hôtes
Enfin, dans l'onglet `Hosts`, je définis des mappings DHCP statiques mais aussi des IP statiques non gérées par le DHCP, pour qu'elles soient enregistrées dans le DNS : Enfin, dans l'onglet `Hosts`, je définis des mappings DHCP statiques mais aussi des IP statiques non gérées par le DHCP, pour qu'elles soient enregistrées dans le DNS :
![opnsense-dnsmasq-dhcp-hosts.png](img/opnsense-dnsmasq-dhcp-hosts.png) ![Hôtes DHCP de Dnsmasq dans OPNsense](img/opnsense-dnsmasq-dhcp-hosts.png)
--- ---
## DNS ## DNS
@@ -372,7 +372,7 @@ Unbound est le résolveur récursif, pour les zones locales j'effectue un forwar
### Paramètres Généraux d'Unbound ### Paramètres Généraux d'Unbound
Configurons-le, dans `Services` > `Unbound DNS` > `General` : Configurons-le, dans `Services` > `Unbound DNS` > `General` :
![opnsense-unbound-general-settings.png](img/opnsense-unbound-general-settings.png) ![OPNsense Unbound DNS general settings](img/opnsense-unbound-general-settings.png)
### Liste de Blocage DNS ### Liste de Blocage DNS
@@ -383,7 +383,7 @@ Pour maintenir le service à jour, dans `System` > `Settings` > `Cron`, j'a
### Transfert de Requêtes ### Transfert de Requêtes
Enfin je configure le transfert de requêtes pour mes domaines locaux vers Dnsmasq. Dans `Services` > `Unbound DNS` > `Query Forwarding`, j'ajoute chacun de mes domaines locaux avec leurs reverse lookups (enregistrements PTR) : Enfin je configure le transfert de requêtes pour mes domaines locaux vers Dnsmasq. Dans `Services` > `Unbound DNS` > `Query Forwarding`, j'ajoute chacun de mes domaines locaux avec leurs reverse lookups (enregistrements PTR) :
![opnsense-unbound-dns-query-forwarding.png](img/opnsense-unbound-dns-query-forwarding.png) ![Configuration du transfert de requêtes d'Unbound DNS dans OPNsense](img/opnsense-unbound-dns-query-forwarding.png)
--- ---
## VPN ## VPN

18
content/post/13-opnsense-full-configuration.md
View File

@@ -92,7 +92,7 @@ Finally I restart the VM. Once started, from the Proxmox WebGUI, I can see the I
## Interfaces ## Interfaces
On both firewalls, I assign the remaining NICs to new interfaces adding a description. The VMs have 7 interfaces, I carefully compare MAC addresses to avoid mixing interfaces: On both firewalls, I assign the remaining NICs to new interfaces adding a description. The VMs have 7 interfaces, I carefully compare MAC addresses to avoid mixing interfaces:
![opnsense-assign-interfaces.png](img/opnsense-assign-interfaces.png) ![Assign interfaces menu in OPNsense](img/opnsense-assign-interfaces.png)
In the end, the interfaces configuration looks like this: In the end, the interfaces configuration looks like this:
@@ -157,13 +157,13 @@ The HA is setup in `System` > `High Availability` > `Settings`
### HA Status ### HA Status
In the section `System` > `High Availability` > `Status`, I can verify if the synchronization is working. On this page I can replicate any or all services from my master to my backup node: In the section `System` > `High Availability` > `Status`, I can verify if the synchronization is working. On this page I can replicate any or all services from my master to my backup node:
![opnsense-high-availability-status.png](img/opnsense-high-availability-status.png) ![OPNsense high availability status page](img/opnsense-high-availability-status.png)
--- ---
## Virtual IPs ## Virtual IPs
Now that HA is configured, I can give my networks a virtual IP shared across my nodes. In `Interfaces` > `Virtual IPs` > `Settings`, I create one VIP for each of my networks using **CARP** (Common Address Redundancy Protocol). The target is to reuse the IP addresses used by my current OPNsense instance, but as it is still routing my network, I use different IPs for the configuration phase: Now that HA is configured, I can give my networks a virtual IP shared across my nodes. In `Interfaces` > `Virtual IPs` > `Settings`, I create one VIP for each of my networks using **CARP** (Common Address Redundancy Protocol). The target is to reuse the IP addresses used by my current OPNsense instance, but as it is still routing my network, I use different IPs for the configuration phase:
![opnsense-interface-virtual-ips.png](img/opnsense-interface-virtual-ips.png) ![Liste des IPs virtuelles dans OPNsense](img/opnsense-interface-virtual-ips.png)
ℹ️ OPNsense allows CARP by default, no special firewall rule required ℹ️ OPNsense allows CARP by default, no special firewall rule required
@@ -239,7 +239,7 @@ To begin, in `Firewall` > `Groups`, I create 2 zones to regroup my interfaces:
### Network Aliases ### Network Aliases
Next, in `Firewall` > `Aliases`, I create an alias `InternalNetworks` to regroup all my internal networks: Next, in `Firewall` > `Aliases`, I create an alias `InternalNetworks` to regroup all my internal networks:
![opnsense-create-alias-internalnetworks.png](img/opnsense-create-alias-internalnetworks.png) ![Création d'alias pour les réseaux locaux dansOPNsense](img/opnsense-create-alias-internalnetworks.png)
### Firewall Rules ### Firewall Rules
@@ -343,17 +343,17 @@ On the backup node, I configure it the same, the only difference will be the **D
### DHCP Ranges ### DHCP Ranges
Next I configure the DHCP ranges. Both firewalls will have different ranges, the backup node will have smaller ones (only 10 leases should be enough). On the master, they are configured as follow: Next I configure the DHCP ranges. Both firewalls will have different ranges, the backup node will have smaller ones (only 10 leases should be enough). On the master, they are configured as follow:
![opnsense-dnsmasq-dhcp-ranges.png](img/opnsense-dnsmasq-dhcp-ranges.png) ![OPNsense DHCP ranges in Dnsmasq](img/opnsense-dnsmasq-dhcp-ranges.png)
### DHCP Options ### DHCP Options
Then I set some DHCP options for each domain: the `router`, the `dns-server` and the `domain-name`. I'm pointing the IP addresses to the interface's VIP: Then I set some DHCP options for each domain: the `router`, the `dns-server` and the `domain-name`. I'm pointing the IP addresses to the interface's VIP:
![opnsense-dnsmasq-dhcp-options.png](img/opnsense-dnsmasq-dhcp-options.png) ![OPNsense DHCP options in Dnsmasq](img/opnsense-dnsmasq-dhcp-options.png)
### Hosts ### Hosts
Finally in in the `Hosts` tab, I define static DHCP mappings but also static IP not managed by the DHCP, to have them registered in the DNS: Finally in in the `Hosts` tab, I define static DHCP mappings but also static IP not managed by the DHCP, to have them registered in the DNS:
![opnsense-dnsmasq-dhcp-hosts.png](img/opnsense-dnsmasq-dhcp-hosts.png) ![Hôtes DHCP de Dnsmasq dans OPNsense](img/opnsense-dnsmasq-dhcp-hosts.png)
--- ---
## DNS ## DNS
@@ -370,7 +370,7 @@ Unbound is the recursive resolver, for local zones I forward queries to Dnsmasq.
### Unbound General Settings ### Unbound General Settings
Let's configure it, in `Services` > `Unbound DNS` > `General`: Let's configure it, in `Services` > `Unbound DNS` > `General`:
![opnsense-unbound-general-settings.png](img/opnsense-unbound-general-settings.png) ![OPNsense Unbound DNS general settings](img/opnsense-unbound-general-settings.png)
### DNS Blocklist ### DNS Blocklist
@@ -381,7 +381,7 @@ To maintain the service up to date, in `System` > `Settings` > `Cron`, I add my
### Query Forwarding ### Query Forwarding
Finally I configure query forwarding for my local domains to Dnsmasq. In `Services` > `Unbound DNS` > `Query Forwarding`, I add each of my local domains with their reverse lookup (PTR record): Finally I configure query forwarding for my local domains to Dnsmasq. In `Services` > `Unbound DNS` > `Query Forwarding`, I add each of my local domains with their reverse lookup (PTR record):
![opnsense-unbound-dns-query-forwarding.png](img/opnsense-unbound-dns-query-forwarding.png) ![Configuration du transfert de requêtes d'Unbound DNS dans OPNsense](img/opnsense-unbound-dns-query-forwarding.png)
--- ---
## VPN ## VPN

378
content/post/14-migration-opnsense-proxmox-highly-available.md
View File

@@ -81,376 +81,13 @@ While these routers are not managing the networks, I give them my current OPNsen
--- ---
## Configure OPNsense ## Configure OPNsense
Initially I thought about restoring my current OPNsense config on the VM. But as I didn't document the configuration process the first time, I take the opportunity to start over.
I'll start with the elements that needs to be configured on both firewalls, where each has its own parameters. After I'll create the OPNsense cluster, then configure the master node only as the configuration will be duplicated on the other node.
### System
I start by the basic, in `System` > `Settings` > `General`:
- **Hostname**: `cerbere-head1` (`cerbere-head2` for the second one).
- **Domain**: `mgmt.vezpi.com`.
- **Time zone**: `Europe/Paris`.
- **Language**: `English`.
- **Theme**: `opnsense-dark`.
- **Prefer IPv4 over IPv6**: tick the box to prefer IPv4.
Then, in `System` > `Access` > `Users`, I create a new user, I don't like sticking with the defaults `root`. I add this user in the `admins` group, while removing `root` from it.
In `System` > `Settings` > `Administration`, I change several things:
- **TCP port**: from `443` to `4443`, to free port 443 for the reverse proxy coming next.
- **Alternate Hostnames**: `cerbere.vezpi.com` which will be the URL to reach the firewall by the reverse proxy.
- **Access log**: enabled.
- **Secure Shell Server**: enabled.
- **Authentication Method:** permit password login (no `root` login).
- **Sudo**: `No password`.
Once I click `Save`, I follow the link given to reach the WebGUI on port `4443`.
Time for updates, in System > Firmware > Status, I click on `Check for updates`. An update is available, I close the banner, head to the bottom and click on `Update`. I'm warned that this update requires a reboot.
Once updated and rebooted, I go to `System` > `Firmware` > `Plugins`, I tick the box to show community plugins. For now I only install the QEMU guest agent, `os-qemu-guest-agent`, to allow communication between the VM and the Proxmox host.
This requires a shutdown. On Proxmox, I enable the `QEMU Guest Agent` in the VM options:
![proxmox-opnsense-enable-qemu-guest-agent.png](img/proxmox-opnsense-enable-qemu-guest-agent.png)
Finally I restart the VM. Once started, from the Proxmox WebGUI, I can see the IPs of the VM which confirms the guest agent is working.
### Interfaces
On both firewalls, I assign the remaining NICs to new interfaces adding a description. The VMs have 7 interfaces, I carefully compare the MAC addresses to not mix them up:
![opnsense-assign-interfaces.png](img/opnsense-assign-interfaces.png)
In the end, the interfaces configuration looks like this:
| Interface | Mode | `cerbere-head1` | `cerbere-head2` |
| --------- | -------------- | --------------- | --------------- |
| *LAN* | Static IPv4 | 192.168.88.2/24 | 192.168.88.3/24 |
| *WAN* | DHCPv4 + SLAAC | Enabled | Disabled |
| *User* | Static IPv4 | 192.168.13.2/24 | 192.168.13.3/24 |
| *IoT* | Static IPv4 | 192.168.37.2/24 | 192.168.37.3/24 |
| *pfSync* | Static IPv4 | 192.168.44.1/30 | 192.168.44.2/30 |
| *DMZ* | Static IPv4 | 192.168.55.2/24 | 192.168.55.3/24 |
| *Lab* | Static IPv4 | 192.168.66.2/24 | 192.168.66.3/24 |
I don't configure Virtual IP yet, I'll manage that once high availability has been setup.
### High Availability
From here we can associate both instances to create a cluster. The last thing I need to do, is to allow the communication on the *pfSync* interface. By default, no communication is allowed on the new interfaces.
From `Firewall` > `Rules` > `pfSync`, I create a new rule on each firewall:
- **Action**: Pass
- **Quick**: tick the box to apply immediately on match
- **Interface**: *pfSync*
- **Direction**: in
- **TCP/IP Version**: IPv4
- **Protocol**: any
- **Source**: *pfSync* net
- **Destination**: *pfSync* net
- **Log**: tick the box to log packets
- **Category**: OPNsense
- **Description**: pfSync
Next, I head to `System` > `High Availability` > `Settings`:
- **Master** (`cerbere-head1`):
- **Synchronize all states via**: *pfSync*
- **Synchronize Peer IP**: `192.168.44.2`
- **Synchronize Config**: `192.168.44.2`
- **Remote System Username**: `<username>`
- **Remote System Password**: `<password>`
- **Services**: Select All
- **Backup** (`cerbere-head2`):
- **Synchronize all states via**: *pfSync*
- **Synchronize Peer IP**: `192.168.44.1`
- **Synchronize Config**: `192.168.44.1`
⚠️ Do not fill the XMLRPC Sync fields, only to be filled on the master.
In the section `System` > `High Availability` > `Status`, I can verify is the synchronization is working. On this page I can replicate any or all services from my master to my backup node:
![opnsense-high-availability-status.png](img/opnsense-high-availability-status.png)
### Virtual IPs
Now that HA is configured, I can give my networks a VIP shared across my nodes. In `Interfaces` > `Virtual IPs` > `Settings`, I create one VIP for each of my networks using CARP (Common Address Redundancy Protocol). The target is to reuse the IP addresses used by my current OPNsense instance, but as it is still routing my network, I use different IPs for the configuration phase:
![opnsense-interface-virtual-ips.png](img/opnsense-interface-virtual-ips.png)
### Firewall
Let's configure the core feature of OPNsense, the firewall. I don't want to go too crazy with the rules. I only need to configure the master, thanks to the replication.
Basically I have 2 kinds of networks, those which I trust, and those which I don't. From this standpoint, I will create two zones.
Globally, on my untrusted networks, I will allow access to the DNS and to the internet, not on the other networks. On the other hand, my trusted networks would have the possibility to reach other VLANs.
To begin, in `Firewall` > `Groups`, I create 2 groups to regroup my interfaces:
- **Trusted**: *Mgmt*, *User*
- **Untrusted**: *IoT*, *DMZ*, *Lab*
Next, in `Firewall` > `Aliases`, I create an alias `InternalNetworks` to regroup all my internal networks:
![opnsense-create-alias-internalnetworks.png](img/opnsense-create-alias-internalnetworks.png)
For all my networks, I want to allow DNS querry on the local DNS. In `Firewall` > `Rules` > `Floating`, let's create the first rule:
| Field | Value |
| -------------------------- | ------------------------------------- |
| **Action** | Pass |
| **Quick** | Apply the action immediately on match |
| **Interface** | Trusted, Untrusted |
| **Direction** | in |
| **TCP/IP Version** | IPv4 |
| **Protocol** | TCP/UDP |
| **Source** | InternalNetworks |
| **Destination** | This Firewall |
| **Destination port range** | from: DNS - to: DNS |
| **Log** | Log packets |
| **Category** | DNS |
| **Description** | DNS query |
Next I want to allow connections towards the internet. At the same place I create a second rule:
| Field | Value |
| -------------------------- | ------------------------------------- |
| **Action** | Pass |
| **Quick** | Apply the action immediately on match |
| **Interface** | Trusted, Untrusted |
| **Direction** | in |
| **TCP/IP Version** | IPv4+IPv6 |
| **Protocol** | any |
| **Source** | InternalNetworks |
| **Destination / Invert** | Invert the sense of the match |
| **Destination** | InternalNetworks |
| **Destination port range** | from: any - to: any |
| **Log** | Log packets |
| **Category** | Internet |
| **Description** | Internet |
Finally, I want to allow anything from my trusted networks. In `Firewall` > `Rules` > `Trusted`, I create the rule:
| Field | Value |
| -------------------------- | ------------------------------------- |
| **Action** | Pass |
| **Quick** | Apply the action immediately on match |
| **Interface** | Trusted |
| **Direction** | in |
| **TCP/IP Version** | IPv4+IPv6 |
| **Protocol** | any |
| **Source** | Trusted net |
| **Destination** | any |
| **Destination port range** | from: any - to: any |
| **Log** | Log packets |
| **Category** | Trusted |
| **Description** | Trusted |
Great, with these 3 rules, I cover the basics. The remaining rules would be to allow specific equipment to reach out to something else. For example my home assistant instance want to connect to my TV, both are on different VLAN, hence I need a rule to allow it. I won't cover that in this post.
### DHCP
For the DHCP, I choose Dnsmasq. In my current installation I use ISC DHCPv4, but as it is now deprecated, I prefer to replace it. Dnsmasq will also act as DNS, but only for my local zones.
Beware because it is not synchronizing leases in HA. To workaround this, both firewalls will serve DHCP at the same time, with slight different configuration to not overlap.
In `Services` > `Dnsmasq DNS & DHCP` > `General`, I configure the master firewall as follow:
- **Default**
- **Enable**: Yes
- **Interface**: *Mgmt*, *User*, *IoT*, *DMZ* and *Lab*
- **DNS**
- **Listen por**t: 53053
- **DNS Query Forwarding**
- **Do not forward to system defined DNS servers**: Enabled
- **DHCP**
- **DHCP FQDN**: Enabled
- **DHCP local domain**: Enabled
- **DHCP authoritative**: Enabled
- **DHCP reply delay**: 0
- **DHCP register firewall rules**: Enabled
- **Disable HA sync**: Enabled
On the backup node, I configure it the same, the only difference will be the **DHCP reply delay** which I set to **10**. This will let the time to my master node to fulfill requests if it is alive.
Next I configure the DHCP ranges. Both firewalls will have different ranges, the backup node will have smaller ones. On the master, they are configured as follow:
![opnsense-dnsmasq-dhcp-ranges.png](img/opnsense-dnsmasq-dhcp-ranges.png)
Then I set some DHCP options for each domain: the `router`, the `dns-server` and the `domain-name`:
![opnsense-dnsmasq-dhcp-options.png](img/opnsense-dnsmasq-dhcp-options.png)
Finally in in the `Hosts` tab, I define static DHCP mappings but also static IP not managed by the DHCP, to have them registered in the DNS:
![opnsense-dnsmasq-dhcp-hosts.png](img/opnsense-dnsmasq-dhcp-hosts.png)
### DNS
For the DNS, I will use Unbound. It is a validating, recursive, caching DNS resolver built into OPNsense, which can:
- Resolve queries from the root servers.
- Cache results for faster responses.
- Check domain authenticity with DNSSEC.
- Block domains based of blacklist.
- Add custom records.
For the local zones, I will use forward the requests to Dnsmasq, hence I will not registering DHCP leases in Unbound.
Let's configure it, in `Services` > `Unbound DNS` > `General`:
![opnsense-unbound-general-settings.png](img/opnsense-unbound-general-settings.png)
Then I configure the blocklist in `Services` > `Unbound DNS` > `Blocklist`. I enable it and select the `[hagezi] Multi PRO mini` list. Initially I was using AdGuard Home, but I want to give this blocklist feature a chance.
To maintain the service of to date, in `System` > `Settings` > `Cron`, I add my first job that runs every night at 2AM to `Update Unbound DNSBLs`.
Finally I configure query forwarding for my local domains. In `Services` > `Unbound DNS` > `Query Forwarding`, I add each of my local domains with their reverse lookup (PTR record). The forwarded server is Dnsmasq which I'll configure next:
![opnsense-unbound-dns-query-forwarding.png](img/opnsense-unbound-dns-query-forwarding.png)
### VPN
When I'm not home, I still want to be able to reach my services and enjoy my DNS ad blocker. For that I'm setting up a VPN, with **WireGuard**. It's fast, secure and easy to set up.
In `VPN` > `WireGuard` > `Instances`, I create a new one:
- **Enabled**: Yes
- **Name**: *Homelan*
- **Public/Private keys**: Key-pair generated
- **Listen port**: `61337`
- **Tunnel address**: `10.13.37.1/24`
- **Depend on (CARP)**: on *lan* (vhid 1)
Once configured, I enable WireGuard and apply the configuration.
Next in the `Peer generator` tab, I fulfill the empty fields for my first device:
- **Endpoint**: `vezpi.com`
- **Name**: *S25Ultra*
- **DNS Servers**: `10.13.37.1`
Before clicking `Store and generate next`, from my device, I configure the peer by capturing the QR code. Finally I can save that peer and start over for new ones.
To allow connections from outside, I need to create a firewall rule on the WAN interface:
| Field | Value |
| -------------------------- | ------------------------------------- |
| **Action** | Pass |
| **Quick** | Apply the action immediately on match |
| **Interface** | WAN |
| **Direction** | in |
| **TCP/IP Version** | IPv4 |
| **Protocol** | UDP |
| **Source** | any |
| **Destination** | WAN address |
| **Destination port range** | from: 61337 - to: 61337 |
| **Log** | Log packets |
| **Category** | VPN |
| **Description** | WireGuard |
### Reverse Proxy
The next feature I need is a reverse proxy, to redirect incoming HTTPS requests, to reach my services, such as this blog. For that I use **Caddy**. This service is not installed by default, I need to add a plugin.
On both firewalls, In `System` > `Firmware` > `Plugins`, I tick the box to show community plugins and install `os-caddy`.
I refresh the page and, on the master, in `Services` > `Caddy` > `General Settings`:
- **Enable Caddy**: Yes
- **Enable Layer4 Proxy**: Yes
- **ACME**: `<email address>`
- **Auto HTTPS**: On (default)
There are two types of redirections, the `Reverse Proxy` and the `Layer4 Proxy`. The first one is for HTTPS only, where Caddy will manage the SSL.
#### HTTPS Proxy
In `Services` > `Caddy` > `Reverse Proxy`, I define the services directly managed by Caddy.
These services should not be exposed to everyone. In the `Access` tab, I create a list, called `Internal`, of allowed networks, including my LAN and VPN networks.
Then in the `Domains` tab, I add my domains. For example, this is here I define `cerbere.vezpi.com`, my URL to reach my OPNsense WebGUI:
- **Enable**: Yes
- **Frontend**
- **Protocol**: `https://`
- **Domain**: `cerbere.vezpi.com`
- **Port**: leave empty
- **Certificate**: Auto HTTPS
- **Description**: OPNsense
- **Access**
- **Access List**: `Internal`
- **HTTP Access Log**: Enabled
Finally in the `Handlers` tab, I define to which upstream these domains are forwarded to. For `cerbere.vezpi.com` I define this:
- **Enabled**: Yes
- **Frontend**
- **Domain**: `https://cerbere.vezpi.com`
- **Subdomain**: None
- **Handler**
- **Path**: any
- **Access**
- **Access List**: None
- **Directive**
- **Directive**: `reverse_proxy`
- **Upstream**
- **Protocol**: `https://`
- **Upstream Domain**: `127.0.0.1`
- **Upstream Port**: `4443`
- **TLS Insecure Skip Verify**: Enabled
- **Description**: OPNSense
#### Layer4 Proxy
Most of my services are behind another reverse proxy on my network, Traefik. To let it manage normally its domains, I forward them using `Layer4 Routes`. It prevents Caddy to terminate SSL, the HTTPS stream is left intact.
In `Services` > `Caddy` > `Layer4 Proxy`, I create 3 routes.
The first one is for internet exposed services, like this blog or my Gitea instance:
- Enabled: Yes
- Sequence: 1
- Layer 4
- Routing Type: listener_wrappers
- Layer 7
- Matchers: TLS (SNI Client Hello)
- Domain: `blog.vezpi.com` `git.vezpi.com`
- Terminate SSL: No
- Upstream
- Upstream Domain: `192.168.66.50`
- Upstream Port: `443`
- Proxy Protocol: v2
- Description: External Traefik HTTPS dockerVM
The second one is for internal only services. It is configured pretty much the same but using access list:
- Sequence: 2
- Access
- Remote IP: `192.168.13.0/24` `192.168.88.0/24` `10.13.37.0/24`
The third one is for Traefik HTTP challenges for Let's Encrypt:
- Sequence: 3
- Layer 7
- Matchers: HTTP (Host Header)
- Domain: `blog.vezpi.com` `git.vezpi.com` etc.
- Upstream:
- Upstream Port: 80
- Proxy Protocol: Off (default)
Finally, I need to allow connection of these ports on the firewall, one rule for HTTPS and another for HTTP:
| Field | Value |
| -------------------------- | ------------------------------------- |
| **Action** | Pass |
| **Quick** | Apply the action immediately on match |
| **Interface** | WAN |
| **Direction** | in |
| **TCP/IP Version** | IPv4 |
| **Protocol** | TCP |
| **Source** | any |
| **Destination** | WAN address |
| **Destination port range** | from: HTTPS - to: HTTPS |
| **Log** | Log packets |
| **Category** | Caddy |
| **Description** | Caddy HTTPS |
### mDNS Repeater
The last service I want to setup in OPNsense is a mDNS repeater. This is useful for some devices to announce themselves on the network, when not on the same VLAN, such as my printer or my Chromecast. The mDNS repeater get the message from an interface to send it to another one.
This service is also not installed by default, on both firewalls, In `System` > `Firmware` > `Plugins`, I tick the box to show community plugins and install `os-mdns-repeater`.
Then in `Services` > `mDNS Repeater`, the configuration is pretty straight forward:
- Enable: Yes
- Enable CARP Failover: Yes
- Listen Interfaces: *IoT*, *User*
### Service Synchronization
The final step is to synchronize all the services between the master and the backup node in the cluster. First in `System` > `High Availability` > `Status`, I click the button to `Synchronize and reconfigure all`.
Then I want to make sure that future changes are synchronized if I omit to replicate them myself. In `System` > `Settings` > `Cron`, I add a new job that runs every night to `HA update and reconfigure backup`.
## TODO
HA in proxmox
Make sure VM start at proxmox boot
## Switch ## Switch
@@ -461,10 +98,17 @@ Replicate configuration
## Verify ## Verify
Basic (dhcp, dns, internet)
Firewall Firewall
All sites All sites
mDNS (chromecast) mDNS (chromecast)
VPN VPN
TV
Vérifier tous les devices
DNS blocklist DNS blocklist
Failover
Test proxmox full shutdown