Les journaux sont stockés sous forme de log circulaire. Pour les lire, il faut utiliser clog.
En SSH :
cd /var/log
clog mylog.log | less
Par défaut ils sont limités à environ 500ko/log, et à 50 lignes dans l’affichage webGUI.
Dans Status -> System Logs -> Settings, on peut augmenter ces valeurs. La taille des journaux ne sera toutefois réellement changée que lors d’un réinitialisation des logs.
user installer
pass opnsense
login apres install, si non modifié
root
opnsense
Theme :
System -> Settings -> General -> Theme
Pour définir le secret TOTP pour un user :
System -> Access -> Users
Éditer l’utilisateur
Chercher OTP seed et l’activer
Puis au niveau système :
System -> Access -> Servers
Ajouter
En nom mettre par exemple “Local_2FA”
Type : Local + TOTP
Laisser par défaut
Pour le tester, aller dans
System -> Settings -> Authentication -> Server
et cocher Local database et “Local_2FA”
On peut alors s’authentifier auprès des 2 sources (avec et sans TOTP).
Une fois que la connexion fonctionne, on peut décocher “Local Database” pour n’autoriser que le format TOTP.
Pour se connecter avec 2FA, il faut entrer le password au format
{TOTP}{PASS}
par exemple 157496MyPassw0rd
Pour enregistrer automatiquement ce format dans KeepassXC, on enregistre le pass comme :
{TOTP}MyPassw0rd
et il fera la complétion avec le code actuel.
Les interfaces sont des configurations réseau que l’on peut associer aux ports physiques du routeur, dans Interfaces -> Assignments.
Dans Interfaces -> iface_name, on peut configurer l’interface en question : lui donner un nom explicite, son adresse IP, et la passerelle qui lui est accessible.
Sous OpnSense (26.7), il peut être distribué par Dnsmasq (activé par défaut) ou Kea (désact. par défaut)
Pour on/off chaucn des 2 :
Services -> Kea DHCP -> Kea DHCPv4
Services -> Dnsmasq DNS & DHCP
Pour voir les leases pour chacun des services, on peut aller dans Services -> Kea DHCP -> Leases DHCPv[4|6]
Pour voir pour Dnsmasq : Services -> Dnsmasq DNS & DHCP -> Leases
Dnsmasq : Services -> Dnsmasq DNS & DHCP -> Hosts et “+”
Remplir “Host”, “IP addresses” et “Hardware adresses” (adresse MAC)
Les passerelles sont à configurer individuellement, dans System -> Routing -> Gateway. La petite terre indique l’interface actuellement par défaut (peut changer en fonction de l’état des liens). Un double-clic sur une passerelle permet de la configurer.
On donne l’interface par laquelle cette passerelle est accessible (par exemple WAN), on donne un nom (que l’on choisit) à cette passerelle, on entre l’IP sur laquelle elle est accessible (par exemple 192.168.1.1), et une adresse IP de monitoring (qui sera pinguée régulièrement, pour s’assurer que cette connexion est toujours vivante ; par exemple 8.8.8.8).
⚠ l’IP de monitoring ne sera jamais accessible depuis une autre interface du routeur PfSense. Faire attention de ne pas bloquer les serveurs DNS d’une interface.
⚠ Pour une connexion qui doit être utilisée même si elle est instable (par exemple une connexion basse qualité de secours, préférable à une absence de connexion), il est possible de cocher Disable Gateway Monitoring, afin qu’elle soit toujours considérée vivante.
En cliquant sur Display Advanced, on peut définir les seuils à partir desquels la connexion est considérée comme perdue.
Unbound est un resolver DNS (résout les domaine en allant interroger récursivement le système DNS).
Dnsmasq est un forwarder DNS (transfère la requête à un resolver)
Dans la config par défaut d’OpnSense Unbound tourne sur le port 53 et Dnsmasq sur le port 53053.
Unboud est le resolver par défaut.
Si par exemple on veut résoudre sub.domain.com vers 192.168.1.100
Services -> Unbound -> Overrides
Host : sub
Domain : domain.com
IP address : 192.168.1.100
On peut mettre des alias, qui sont un peu l’équivalent des CNAME ; ils partagent tous la même IP de destination.
Il est possible d’avoir une résolution des clients DHCP sous le format “hostname.domain.lan”.
Si DHCP par Kea, alors Services -> Unbound DNS -> General puis Register ISC DHCP4 Leases et Register DHCP Static Mappings.
Ainsi Unbound sera directement informé des hostnames des clients DHCP et pourra les résoudre.
Si DHCP par Dnsmasq, alors Services -> Dnsmasq DNS & DHCP -> General puis Register ISC DHCP4 leases (s’applique aussi aux baux statiques, tant que le client est conecté ; la case “Register DHCP static mappings” permet de résoudre même en l’absence de connexion du client)
Vérifier aussi DHCP domain override ; si vide, alors les clients seront ajoutés au domain système ; sinon ils seront ajoutés au domaine mentionné ici.
Vérifier aussi le domaine distribué aux client pour leur recherche, par Services -> Dnsmasq -> DHCP ranges puis Domain.
Ceci permet aux clients de faire les requêtes sur le domaine, et à Dnsmasq de résoudre les hostname.
Toutefois, si le resolver est Unbound, il faut dire à unbound d’aller interroger Dnsmasq uniquement pour répondre aux requêtes concernant ce domaine (par exemple “domain.lan”). Pour ça :
Services -> Unbound -> Query forwarding et +
Domain : domain.lan
Server IP : 127.0.0.1
Server Port : 53053
Si le routeur est défini comme serveur DNS pour les clients, il faut configurer sa résolution DNS. Pour ça, on va dans System -> General Setup. Dans le cas de multi-WAN, il est nécessaire d’avoir au moins 1 serveur DNS par passerelle.
Par souci de simplicité, je choisis le serveur DNS de cette passerelle comme adresse de monitoring pour cette passerelle. Ainsi, si c’est le serveur DNS qui tombe (empêchant la navigation internet), la connexion sera considérée comme défectueuse, et le routeur basculera sur une autre connexion.
Il peut être intéressant d’essayer d’activer Powerd dans
System / Advanced / Miscellaneous -> Enable PowerD.
En l’activant (et laissant la valeur “hiadaptative”), je suis passé de 65 Mo/s à 100 Mo/s (débit max upstream)
Aussi, dans Interfaces -> Settings -> General
essayer de désactiver “Disable hardware TCP segmentation offload”
et reboot
En “Redirect Target Port”, any dit de rediriger sur le/les ports spécifiés en entrée (Destination Port)
Si on spécifie une plage de port en entrée et un port simple en sortie, il utilise ce port comme base et décale à partir de ce port.
Par défaut, les redirections de port ne fonctionnent que depuis l’extérieur (interface WAN). Si on essaye d’y accéder depuis l’intérieur du réseaU, cela ne fonctionne pas.
Pour que les redirections de port fonctionnent depuis l’intérieur, il faut activer l’option “NAT reflection” (parfois “NAT hairpin)”. Ainsi, l’IP de destination sera traduite même si la requête vient du LAN.
Toutefois, cela ne suffit pas ; en effet, comme l’IP source est préservée lors du “Destination NAT”, le destinataire (serveur) verra que l’IP source est sur le réseau local, et lui répondra donc directement. Or ce n’est pas l’IP contactée à la base par le client, donc sa réponse sera ignorée/rejetée.
Pour éviter ce problème, il faut également créer des règles pour le SNAT (NAT Source), grâce auquel l’IP source deviendra l’IP du routeur. Ainsi, le serveur répondra au routeur, qui dé-nattera la réponse pour la renvoyer au client.
Il ya 2 modes : “Pure NAT” et “NAT + proxy”.
Le mode proxy, c’est un petit soft qui tourne sur PfSense, qui récupère le flux entrant et le retransmets vers la destination en recréant un nouveau flux. Ça doit fonctionner dans toutes les situations, mais on perd en débit et cela sollicite beaucoup le firewall.
Le mode “Pure NAT” est le mode standard exposé ci-dessus. Il est beaucoup moins lourd et permet de conserver les débits.
Il faut aller dans dans System / Advanced -> Firewall & NAT. On y voit Enable automatic outbound NAT for Reflection qui correspond au SNAT, il faut le cocher.
On y voit aussi NAT Reflection mode for port forwards, qui correspond au DNAT Reflection par défaut. On peut l’activer ici, et elle sera activée par défaut. Il est sinon possible de gérer granulairement pour chaque redirection de port, sous NAT reflection.
Firewall -> Settings -> Advanced
Automatic outbound NAT for Reflection : SNAT
Reflection for destination NAT : politique DNAT par défaut depuis le LAN
Le DNAT peut aussi se gérer indépendamment pour chaque redirection de port ; il faut activer le mode avancé, puis Options -> NAT Reflection
La traduction IP/port a lieu avant de passer le pare-feu ; ainsi, la règle nécessaire est lorsqu’un paquet se présente sur l’interface WAN, avec pour destination
Dans System -> Routing -> Gateway Groups, on ajoute un groupe de passerelle. Il faut lui donner un nom (par exemple “Gateways_Failover”).
Dans Gateway Priority, on donne une priorité à chaque passerelle existante. Si “Never”, elle ne sera pas utilisée dans ce groupe de passerelles. Toutes les passerelles d’un même Tier seront utilisées en même temps, en commençant par le Tier 1. Si les conditions de ligne défectueuse (perte de paquet, forte latence ou lien coupé) se présentent, le routeur basculera sur la/les passerelles du Tier 2, etc. (C’est aussi en mettant plusieurs passerelles dans le même Tier que l’on peut faire de l’équilibrage de charge, dont on peut affiner la forme en modifiant le poids de chaque passerelle.)
Pour Virtual IP, on laisse généralement “Interface adress”. Il peut être utile de faire différemment si on a un cluster de routeurs PfSense redondants, pour simuler une même interface entre tous les routeurs.
Le Trigger Level permet de choisir l’évenement qui déclenche un basculement vers le Tier suivant (perte de paquets, haute latence, lien coupé). Le détail des seuils peut être reglé pour chaque passerelle individuellement (voir ci-dessus).
Dans System -> Routing, une fois le groupe de passerelle créé, on peut le définir comme passerelle par défaut, pour IPv4 et/ou IPv6.
NOTE : il semble que ce ne fut pas possible pendant longtemps. Dans le cas où ce choix ne serait pas disponible, il faut aller dans Firewall -> Rules, aller dans l’onglet LAN (car le choix de passerelle s’applique aux paquets qui se présentent sur l’interface LAN, dans le but de sortir sur une autre interface), éditer chaque règle pertinente (par défaut uniquement une règle pour IPv4 et une règle pour IPv6 qui autorise tout le trafic vers les autres interfaces), cliquer Display Advanced et définir la Gateway sur le groupe précedemment créé. C’est aussi la solution à choisir pour un filtrage plus granulaire.
Pour voir l’état actuel des passerelles, on peut aller dans Status -> Gateways. Ceci donne l’état de chaque passerelle, individuellement.
On peut aller dans l’onglet Gateway groups pour voir l’état du groupe de passerelle.