RDP & Guacamole

Et non, je ne suis hélas pas parti en vacances au Mexique déguster du guacamole arrosé de téquila ! Mais j'ai trouvé la solution que je cherchait depuis longtemps pour sécuriser les accès RDP. Comme chacun le sait il n'est vraiment pas conseillé de laisser ouvert sur internet le port RDP qui est plutôt vulnérable. Hélas pensant le confinement beaucoup de clients ont du mettre en place des solutions dans l'urgence et dans bien des cas il était impossible de verrouiller au minimum ce port sur une IP fixe....

Bien sur Microsoft a une solution (RDP Gateway), couteuse et complexe, donc pas adaptée à de petites entreprises dont les couts IT explosent déjà. Je restait donc en éveil à la recherche d'une solution quand je suis tombé sur le projet open-source Guacamole en HTML5. Et surprise, celui ci fonctionne vraiment bien ! Le principe est simple et reprends celui des autres projets, une machine va servir de proxy afin d'exposer le RDP (mais aussi SSH, Telnet et VNC).

Installation

S'il est possible d'installer Guacamole en natif comme c'est très bien expliqué ici, après avoir testé différentes options, par facilité je vais faire ça sous Docker en utilisant ce projet.

Je vais donc monter une VM Linux Ubuntu et y configurer Docker et Docker Compose. Pour cette partie je vous laisse chercher, d'autres expliquent mieux que moi.

Pour déployer Guacamole on a besoin de 3 services :

  • GUACD : Le cœur de Guacamole qui va servir à connecter les différents services (RDP, SSH, etc...)
  • PostgreSQL : Une base de donnée (qui peut être également MySQL ou encore l'utilisation d'une base externe)
  • Guacamole : Le composant FrontEnd qui va gérer les connections, les services et les utilisateurs.

Docker Compose

L'auteur de l'intégration a eu la bonne idée de nous fournir un script d'installation. On va donc l'utiliser et on se servira de Docker Compose plus tard afin d'ajuster la configuration.

sudo git clone "https://github.com/boschkundendienst/guacamole-docker-compose.git"
cd guacamole-docker-compose
./prepare.sh
sudo docker-compose up -d

Si tout se passe bien on peut se connecter sur https://ip_serveur:8443/guacamole. Le nom d'utilisateur par défaut est guacadmin avec mot de passe guacadmin. La première chose à faire est bien sur de le changer.

On pourra facilement configurer un serveur RDP et s'y connecter pour avoir les premières impressions. Je trouve que le rendu RDP en HTML5 est fluide, même en regardant des vidéos sur YouTube à une bonne résolution. Attention à ne pas perdre de vue que c'est le serveur Guacamole qui doit encaisser le trafic entrant et sortant. Selon l'usage et le nombre de clients il faudra donc le dimensionner correctement.

Je ne vais pas m'étendre sur les différentes options, l'interface et claire, la documentation également et d'autres en parlent très bien.

Sécurisation

Il n'est bien sur pas question d'exposer ce serveur directement sur internet et je vais tester deux solutions de reverse proxy, je commence par éditer le fichier docker-compose.yml afin de supprimer le proxy Nginx préinstallé histoire de ne pas empiler les proxys. J'ajuste également en 8080:8080 pour une utilisation en direct et REMOTE_IP_VALVE_ENABLED: 'true'  pour activer le proxy externe et WEBAPP_CONTEXT: 'ROOT' afin que Guacamole soit accessible en racine :

version: '2.0'
networks:
  guacnetwork_compose:
    driver: bridge

services:
  # guacd
  guacd:
    container_name: guacd_compose
    image: guacamole/guacd
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./drive:/drive:rw
    - ./record:/record:rw
  # postgres
  postgres:
    container_name: postgres_guacamole_compose
    environment:
      PGDATA: /var/lib/postgresql/data/guacamole
      POSTGRES_DB: guacamole_db
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: postgres:15.2-alpine
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./init:/docker-entrypoint-initdb.d:z
    - ./data:/var/lib/postgresql/data:Z

  guacamole:
    container_name: guacamole_compose
    depends_on:
    - guacd
    - postgres
    environment:
      REMOTE_IP_VALVE_ENABLED: 'true'   # On active ici l'utilisation via un proxy externe
      WEBAPP_CONTEXT: 'ROOT'
      GUACD_HOSTNAME: guacd
      POSTGRES_DATABASE: guacamole_db
      POSTGRES_HOSTNAME: postgres
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: guacamole/guacamole
    volumes:
    - ./custom/server.xml:/home/administrator/guacamole-docker-compose/server.xml
    links:
    - guacd
    networks:
      guacnetwork_compose:
    ports:
    - 8080:8080
    restart: always

Je relance docker :

administrator@guacamole:~/guacamole-docker-compose$ sudo docker-compose up -d

En local je me connecte maintenant en http://ip_serveur:8080 sans SSL car le SSL sera géré par le proxy.

Option 1 : pfsense

J'ai un pfsense installé avec HAProxy et Acme pour gérer les certificats Lets'Encrypt, je vais donc me servir de ca pour publier le service. Sur HAProxy on configure le BackEnd et le FronteEnd qui lui utilisera le certificat préalablement créé avec Acme. Dans ma configuration je partage l'IP avec plusieurs sites et ce qui est important c'est d'activer l'option forwardfor qui permettra de transférer les adresses sources à Guacamole.

Je mets ici le code de configuration qui sera utile à ceux qui n'utilisent pas HAProxy sous pfsense qui lui dispose d'une interface graphique. Comme on peut le constater le HTTP to HTTPS se fait au niveau du HAProxy et c'est lui également qui redirigera les requetés HTTTP vers HTTPS et mon serveur sera accessible sur https://guacamole.mondomaine.tld :

global
  maxconn     10000
  stats socket /tmp/haproxy.socket level admin  expose-fd listeners
  uid     80
  gid     80
  nbproc      1
  nbthread      1
  hard-stop-after   15m
  chroot        /tmp/haproxy_chroot
  daemon
  tune.ssl.default-dh-param 1024
  server-state-file /tmp/haproxy_server_state

listen HAProxyLocalStats
  bind 127.0.0.1:2200 name localstats
  mode http
  stats enable
  stats admin if TRUE
  stats show-legends
  stats uri /haproxy/haproxy_stats.php?haproxystats=1
  timeout client 5000
  timeout connect 5000
  timeout server 5000

frontend Shared_WAN-merged
  bind      x.x.x.x:443 (IP WAN) name x.x.x.x:443 (IP WAN)   ssl crt-list /var/etc/haproxy/Shared_WAN.crt_list  
  mode      http
  log       global
  option    http-keep-alive
  option    forwardfor
  acl https ssl_fc
  http-request set-header   X-Forwarded-Proto http if !https
  http-request set-header   X-Forwarded-Proto https if https
  timeout client    30000
  acl     Admin var(txn.txnhost)      -m str -i admin.domain.tld
  acl     guacamole var(txn.txnhost)  -m str -i guacamole.domain.tld
  http-request set-var(txn.txnhost) hdr(host)
  use_backend Admin_ipvANY  if  Admin 
  use_backend Guacamole_8443_ipvANY  if  guacamole 

frontend http-to-https
  bind            x.x.x.x:80 (IP WAN) name x.x.x.x:80 (IP WAN)
  mode            http
  log             global
  option          http-keep-alive
  timeout client  30000
  http-request redirect code 301 location https://%[hdr(host)]%[path]  

backend Admin_ipvANY
  mode     http
  id       100
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   admin 192.168.55.44:80 id 101  

backend Guacamole_8443_ipvANY
  mode     http
  id       102
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   guacamole 192.168.66.55:8080 id 101

Option 2 : CloudFlared

Cette option est encore plus simple pour ceux qui disposent d'un domaine chez Cloudflare. On va utiliser les possibilités offertes gratuitement par Cloudflared et ajouter une couche de sécurité supplémentaire.

On commence par créer un tunnel CloudFlared avec une instance Docker supplémentaire (le code est fournit par le site de configuration Zero Trust de Cloudflare)

docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoiZjk0YjdkZTBiMzFmYWNkNjZlshhsgfhsfghsgfhgfhssgfhsfgzRiMC00MmNlLWJjMghsfghsghsgfhsgfhsgfhsgmpaR00tyyretu(-yenebybvewWXpGaUxUazVNell0TnpRek56WXhNMlkxWXpFeiJ9

Ensuite une fois que le tunnel est monté

On va publier et pointant sur l'ip privée et le port de notre serveur, cela va automatiquement créer l'entrée DNS dans CloudFlare et gérer la problématique du certificat. Ll sera accessible en SSL. :

Ensuite on va ajouter une couche de sécurité supplémentaire en créant une application de type SelfHosted à laquelle on affecte une policie qui impose un code supplémentaire lors d'une connexion. Ce code sera envoyé sur le mail de l'utilisateur sur une adresse individuelle ou un domaine spécifique. Ce n'est pas tout à fait du MFA, mais on considère que si l'utilisateur reçoit bien le code sur son mail professionnel, il s'agit bien de lui et on peut lui permettre de saisir son login / password pour accéder au service :

C'est la méthode la plus simple et de nombreuses option sont exploitables, de même qu'il est possible d'utiliser de nombreux providers externes d'authentification :

Lorsqu'il souhaite se connecter, l'utilisateur tombe sur un portail que l'on peu personnaliser aux couleurs de l'entreprise.

Voilà, et surtout maintenant on retrouve bien les IP publiques dans le log de Guacamole :

Il n'y a plus qu'a ajuster les différentes options de Guacamole et pour ça la documentation est très bien faite. Et bien sur si on se sert de Guacamole pour exposer des serveurs RDP accessibles sur l'internet on prendra soin de restreindre leur usage à l'IP publique du serveur Guacamole, ou mieux de faire transiter ce flux par un tunnel (Wireguard, Tailscale ou Zerotier par exemple que l'on peu facilement installer sur les deux serveurs).

De ISA/TMG à pfsense / HA Proxy

Il y a 20 ans Microsoft s’était mis en tête de proposer un firewall / reverse proxy maison. A l’époque on ne parlait pas encore de cloud à toutes les sauces, mais juste de permettre aux itinérants de se connecter aux applications d’entreprise, quelques une en web, mais surtout des applications lourdes via le VPN maison (PPTP). Mais surtout Microsoft a réussit à imposer ISA Serveur à beaucoup de ses clients disposant de serveurs Exchange, qui succédait alors à MS Mail, en saupoudrant le tout d’un peu de complexité plus ou moins utile et en imposant de coûteux certificats SAN. Ainsi nous avons eu ISA 2000, ISA 2004, ISA 2006, au passage Microsoft a même produit des appliances avec HP pour terminer par TMG 2010 qui était la dernière itération de la série.

Et après ? Et bien Microsoft a (quasiment) du jour au lendemain décidé que la sécurité d’accès ce n’était pas leur job et en gros ils ont planté là tout le monde. Démerdez vous. Bien sur d’autres éditeurs et constructeurs ont pris le relais (Kemp par exemple) mais la transition n’a pas été facile pour tout le monde, principalement pour des questions de coût. Résultat on trouve encore aujourd’hui des installations basées, dans le meilleur des cas, sur la dernière itération du produit Microsoft, qui dans le meilleur des cas tourne sur un Windows 2008R2 qui comme toute la famille W7 ne reçoit plus de mises à jour, sans passer à la caisse.

Il arrive un moment ou il faut se résoudre à détruire ces vieilleries et se tourner vers quelque chose de plus moderne, et ce d'autant plus qu'on parle ici de sécurité, en gros la porte d'entrée numérique de l'entreprise. Si les grands comptes ont les moyens de leur sécurité en s’offrant des pare-feu et autres équilibreurs de charge à plusieurs milliers d’Euros, voire dizaine de millier d’euros, les PME, quand elles sont malines, peuvent se tourner vers l’open source.

Après avoir un peu cherché, il existe plusieurs pistes, j’ai choisit une base pfsense (on peut partir aussi sur OPNsense) avec HA Proxy comme composant reverse proxy. On peut également utiliser Squid, l’avantage de HA Proxy étant qu’il s’agit d’un bon équilibreur de charge et qu'il sera également possible de s'en servir pour publier d'autres sites sur une ou plusieurs IP publiques. L’autre avantage de pfsense est le support total de Acme et qu’il est ainsi possible de générer automatiquement un certificat SAN nécessaire à Exchange.

En version eco point d’appliance pfsense, je l’ai donc installé sur une VM ESXi selon les recommandation de l’éditeur, avec un WAN et un LAN. Je ne vais pas vous décrire, c’est très bien expliqué ici.

Une fois notre pfsense installé on va lui ajouter quelques packages en allant dans System/Packages ou est disponible tout un catalogue de composant additionnels. Encore une fois la règle est la même, moins on installe de choses, mieux on se porte...

  • Open VMWare Tools : pour faire le lien avec l'hyperviseur
  • Acme : pour générer des certificats SSL Let'Encrypt en se basant sur les API des DNS (chez nous Gandi ou OVH par exemple).
  • HA Proxy : car on est venu pour lui !

Je passe sur Acme qui est assez intuitif et on va voir comment publier un serveur Exchange. Dans cet exemple je l'ai fait sans répartition de charge, mais il est tout à fait possible de publier un (ou plusieurs) FrontEND et coté BackEND répartir la charge sur plusieurs serveurs Exchange selon des règles à définir, soit en spécialisant les serveurs (EAS, Mapi, etc...) soit en hiérarchisant leur importance et leur besoin de disponibilité en fonction du type d'utilisateurs (petit peuple, VIP, etc...). Ce ne sont que des exemples et les serveurs peuvent êtres (ou pas) multipliés (plusieurs serveurs, plusieurs hyperviseurs, plusieurs SAN, etc...) selon la sensibilité de l'infrastructure.

Alors vous allez me dire, pourquoi encore maintenir des serveurs Exchange à l'heure du cloud ? Si pour de petites structures ça n'a pas trop de sens, pour certaines entreprise sensibles il peut s'agit d'une question de confidentialité qu'aucun cloud ne pourra offrir, et pour d'autres simplement pour une question de coût, car même en additionnant le coût des licences (prohibitif, genre 80% d'un projet), le matériel, l'infrastructure, l’exploitation et de bons consultants, au delà d'un certain seuil c'est très rentable par rapport à des licences 365 à 15 € / mois.

Mais au lieu de polémiquer, revenons à notre HA Proxy...

HA Proxy se décompose en deux parties principales. Le FrontEND, c'est ce qui va recevoir les connections entrantes, et le BackEND ou seront connecté les serveurs internes et ou on redirigera les flux après les avoir isolés. Je dis bien isolés car ici on ne fait pas de routage mais du proxy. D'ailleurs pour s'en rendre compte, le serveur Exchange n'a pas besoin d'avoir le serveur pfsense / HA Proxy en passerelle par défaut...

Dans les paramètres généraux on déterminera le nombre de connexions maximum, ce qui a une incidence directe sur l'occupation mémoire, mais également un serveur SysLog si on veut deboguer un peu la chose...

Sur le FrontEND on va configurer une entrée en utilisant une des IP publique disponibles et on va la configurer en type http/https (offloading). Logique et important.

En option et pour plus de sécurité on va fixer des ACL sur les chemins utilisés par Exchange. Çà fonctionne bien sur sans, mais c’est une sécurité supplémentaire recommandable. C'est également la possibilité de rediriger des chemins (path), donc des services vers des serveurs différents via plusieurs BackEND, par exemple le web mail /OWA vers un serveur et les mobiles /Microsoft-Server-ActiveSync vers un ou plusieurs autres serveurs via un second BackEND.

Sur cette même page de configuration au chapitre SSL Offloading on choisira notre certificat (préalablement créé avec Acme ou simplement importé) et surtout on cochera la bonne case afin de restreindre les requêtes aux seul domaines et sous domaines déclarés dans en Subjet Alternative Name de notre certificat SAN, cela nous évite d'avoir à déclarer d'autres ACL plus haut ou en des entrées en SNI.

Il est bien sur possible d'ajouter d'autres sécurités, comme des certificats client, mais comme je ne bosse pas pour un service secret je me suis abstenu.

Passons maintenant au BackEND. On va ici définir le ou les serveur(s) qui seront utilisés pour nos différents services. En l’occurrence je n'en ai qu'un seul sans quoi j'aurais créé plusieurs entrées ou plusieurs BackEND si je souhaitait répartir les services.

Je vais identifier mon serveur par son adresse IP et son port. Ensuite je vais choisir si ce serveur répond en SSL et s'il est nécessaire de vérifier la validité du certificat. Exchange répond en SSL, mais s'agissant de trafic interne je pourrais très bien à l'avenir choisir de ne pas vérifier la validité de son certificat ou utiliser un certificat ausigné. Le poids n'est à renseigner que si on a plusieurs serveurs en BackEND à équilibrer.

Pour d'autres types de serveurs web je peux également y accéder seulement en HTTP en interne, sachant que le client externe lui le verra en HTTPS. C'est un choix lié au niveau de sécurité de l'infrastructure, mais dans bien des cas on ne se préoccupe pas de chiffrer l'interne.

Le cas échéant on réglera plus loin la méthode d'équilibrage, un Timeout à passer 10000 pour Exchange, une méthode pour tester la disponibilité des serveurs et si l'on souhaite ou pas des statistiques, statistiques très utiles pour valider une répartition / équilibrage de charge.


Le FrontEND


Le BackEND

Voilà, à partir de là on a quelque chose de fonctionnel pour tous les ports HTTPS. Il va nous reste à traiter les ports TCP nécessaires au fonctionnement d'un serveur de messagerie (SMTP, POP, IMAP). Si POP et IMAP sont peu en vogue dans les entreprises qui utilisent Exchange, le port SMTP (25) sera nécessaire pour le trafic entrant. Cependant Exchange assurant un service minimum au niveau de la protection certains choisiront de faire transiter le trafic entrant par une passerelle de sécurité (Anti Spam, Anti Virus, etc...).

Dans l'absolu il est possible d'utiliser HA Proxy pour répartir la charge du trafic TCP en configurant un FrontEND TCP et en lui associant un ou plusieurs BackEND.

J'ai du louper quelque chose car le trafic sur ces ports n'était pas stable, alors que d'autres l'ont fait avec de bons résultats. J'ai donc fait un rétropédalage rapide sur ce point et pour l’instant je me suis contenté de faire du NAT classique, donc sans possibilité de répartition de charge. A suivre prochainement.

DNS public

Pour ce qui est du DNS public j'ai fait le choix le plus simple consistant à utiliser uniquement mon nom de domaine. D'autres feront le choix d'utiliser un sous domaine du genre mail.domaine.tld...

@ 3600 IN A 55.235.45.30
@ 3600 IN MX 10 domaine.tld. 
@ 3600 IN TXT "v=spf1 mx mx:domaine.tls~all" 
_autodiscover 3600 IN SRV 10 10 443 domaine.tld. 
autodiscover 3600 IN CNAME  domaine.tld.

Il ne reste plus qu'à tester en configurant les trois types de clients utilisant HTTPS :

  • Un client Outlook sur Mac ou PC sous MAPI qui va utiliser le processus AutoDiscovery pour trouver son serveur en se basant uniquement sur l'adresse mail de l'utilisateur.
  • Un client mobile IOS ou Android qui utilisera ActiveSync (EAS) et AutoDiscovery pour s'y retrouver. A noter que l'application Courrier proposée sur Windows 10 utilise ce même protocole.
  • Et enfin un client web mail en pointant sur domaine.tld/owa

Si tout se passe bien on valide le SMTP entrant / sortant, éventuellement IMAP et POP et il est possible de facturer le client.

Sources

 

SSL mi amor… & pfSense

On ne vantera jamais assez les mérites d’un reverse proxy en termes de sécurité. Mais au-delà de la sécurité, un reverse proxy peut aussi nous faciliter la vie pour la publication de services web en mode sécurisé, et donc la gestion des certificats.

Si selon le niveau de protection et d’assurance il faudra continuer à acheter des certificats hors de prix, dont la sécurité a parfois été corrompue même chez les soi-disant plus sérieux fournisseurs, pour bien des services l’utilisation de certificats Let’s Encrypt fera parfaitement l’affaire.

Au passage vous noterez que si j’étais fan de Sophos XG, je suis en train de m’orienter vers pfSense que je trouve bien plus simple et mieux documenté par la communauté.

Il y a plusieurs façons d’utiliser Let’s Encrypt :

  • Via un script ou un logiciel installé sur le backend (le serveur web) qui génère le certificat, il faudra ensuite l’exporter manuellement ou via un script vers le reverse proxy si on en utilise un en frontal, mais on peu aussi passer en direct, en NAT ou une simple redirection de ports.
  • Via un script géré par le firewall / reverse proxy. C’est ce que je vais décrire ici en utilisant pfSense ou j’installerais les paquets Acme et HAProxy.

Acme

Automated Certificate Management Environment, for automated use of LetsEncrypt certificates.

Cette implémentation très complète va nous permettre de générer et renouveler automatiquement des certificats Lets’s Encrypt (Standard, Wilcard ou San) et de les installer dans pfSense. Cette implémentation sait s’appuyer sur les API des principaux DNS, ce qui nous évitera d’avoir à ouvrir un port 80 comme cela était nécessaire auparavant. Le plus simple sera de générer un wilcard : *.domaine.tld.

Il sera également possible d’exporter ces certificats, manuellement, ou via un script vers un serveur web si nécessaire (par exemple, un script PowerShell sur un serveur Exchange pour récupérer les certificats, les installer et les activer).

Dans notre exemple on n’exporte rien car on va se servir de HA Proxy comme Frontend, c’est à lui qu’incombera la gestion du SSL (le SSL Offloading consiste à déporter la gestion du SSL sur le reverse proxy / load balancer, et donc sur le serveur web on ne laisse que le service HTTP, les sessions HTTPS n'étant cryptées qu'entre l'internaute et le reverse proxy qui peut également jouer un rôle d’équilibreur de charge si nécessaire).

HA Proxy

The Reliable, High Performance TCP/HTTP(S) Load Balancer.

Il s’agit ici d’un reverse proxy moderne qui permet également d’équilibrer la charge vers plusieurs Backends.

On aurait pu utiliser le paquet Squid, mais je lui reproche de ne pas gérer SNI (à vérifier) et donc de ne pouvoir servir plusieurs domaines en SSL. Squid est toutefois plus simple et fera l’affaire pour une installation simple ou domestique. A noter également que tant HA Proxy que Squid permettent de publier un serveur Exchange, et donc de remplacer avantageusement de vieux ISA ou TMG que Microsoft nous a tant vanté avant de les oublier…

Je ne vais pas reprendre un fastidieux steep by steep de publication il y en a de très bien faits… mais juste résumer :

  1. Installation de pfSense (il y a des VM toutes prêtes) avec un lien WAN et un lien LAN. On peut éventuellement ajouter des IP virtuelles (VIP) coté WAN si on en dispose.
  2. On crée une règle sur le firewall ou on autorise le port 443 (HTTPS) en entrant sur le WAN.
  3. Sur HA Proxy on crée un Backend avec l’IP interne sur le port 80 (ou autre) et sans SSL (sans car on pourrait également sécuriser le flux interne). Dans les options de LoadBalancing on choisit None si on a qu’un Backend, et dans ce cas on n’oublie pas de choisir également None au niveau Health checking. Et c’est tout, le reste si on ne sait pas, on ne touche pas.
  4. Sur HA Proxy on crée un Frontend qui écoute sur le port WAN (ou VIP), on coche SSL Offloading et plus bas dans SSL Offloading on choisit le certificat lié au domaine que l’on va utiliser (une règle Frontend par domaine géré). Dans Default backend, access control lists and actions on va gérer nos serveurs en utilisant l’expression Host Matches et la valeur, par exemple canaletto.fr que l’on nomme www (inutile si on n’a qu’un seul serveur à sécuriser). Ensuite plus bas dans Actions on va dire que la condition www est redirigée vers le Backend idoine. Ici aussi, c’est tout, le reste si on ne sait pas, on ne touche pas, car comme vous pourrez l’observer HA Proxy dispose d’une multitude d’options qui ne seront utiles que dans certains cas.

Test

Pour tester ce genre de configuration l’idéal est de disposer une machine connectée sur l’internet en dehors de votre réseau. La machine d’un ami en remote (TS, TeamViewer, NoMachine ou AnyDesk) ou encore une machine connectée en 4G.

Comme à ce stade on n’a probablement pas encore renseigné le DNS public, le plus simple est de créer une entrée dans le fichier hosts (sous Windows le plus simple est d’utiliser HostMan). 

Ensuite on lance une session dans le navigateur et on vérifie que c’est vert et que le certificat est valide et correspond bien à celui utilisé. Si c’est le cas il n’y a plus qu’à s’occuper du DNS public.

Info

Vous imaginez bien que je n’ai pas creusé ce sujet uniquement pour publier un Jeedom. Au départ il s’agissait de publier des serveurs Microsoft Exchange avec des certificats SAN classiques et couteux, et quand on publie de l’Exchange on peut faire à peu près tout. Ensuite j’ai trouvé la gestion Let’s Encrypt tellement simple dans pfSense que je me suis dit que finalement cet outil embarqué dans une VM ou un petit Appliance pouvait d’adapter à toutes les situations, même les plus simples. Du coup je vais probablement remplacer Sophos XG et pourquoi pas également chez moi à la place ou à côté de l’USG qui est très bien pour le trafic sortant mais n’évolue pas trop et ne permet pas de faire du reverse proxy.

Sources

https://pixelabs.fr/installation-configuration-pfsense-virtualbox/https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-vmware-vsphere-esxi.html

https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://pixelabs.fr/installation-role-transport-edge-2016-partie-2/
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://www.supinfo.com/articles/single/6326-mise-place-serveurs-web-haute-disponibilite-avec-haproxy-pfsense
https://www.itwriting.com/blog/9592-publishing-exchange-with-pfsense.html
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://forum.netgate.com/topic/99804/squid-reverse-proxy-for-multiple-internal-hosts
https://tecattack.ch/index.php/2018/12/10/pfsense-2-4-4-haproxy-reverse-proxy-multiple-http-server-ubuntu-16-04/
https://all-it-network.com/pfsense-reverse-https/
https://blog.devita.co/pfsense-to-proxy-traffic-for-websites-using-pfsense/