OverView OutPost

1. Ouvrir le vSphere Client (interface web)
2. Clic droit sur l'hôte ou le cluster > Deploy OVF Template...
3. Sélectionner Local file et choisir le fichier .ova fourni
4. Suivre l'assistant : nommer la VM, choisir le datastore, sélectionner le réseau (VLAN/portgroup)
5. Cliquer sur Finish et attendre la fin de l'import
6. Démarrer la VM

1. Copier le fichier .vhdx fourni sur l'hôte Hyper-V
2. Dans Hyper-V Manager, créer une nouvelle VM Génération 2 et, à l'étape du disque, choisir Use an existing virtual hard disk en pointant le .vhdx (l'action Import Virtual Machine ne fonctionnera pas — elle attend un dossier de VM exportée, pas un disque seul)
3. Régler le modèle Secure Boot sur Microsoft UEFI Certificate Authority (Settings → Security) — le modèle par défaut Microsoft Windows refuse de démarrer Linux :

   Set-VMFirmware "<nom-vm>" -SecureBootTemplate MicrosoftUEFICertificateAuthority
   

4. Configurer les ressources (2 vCPU, 2 GB RAM), connecter un virtual switch, démarrer la VM

Génération 1 ? Indiquez-le avant le build : un .vhd est fourni à la place (même procédure, sans réglage Secure Boot).

1. Ouvrir Prism Central > Compute & Storage > Images > Add Image
2. Uploader le fichier .qcow2 fourni, type Disk, placer sur le cluster cible
3. Aller à Compute & Storage > VMs > Create VM
4. Configurer : 2 vCPU, 2 GB RAM, et régler le Boot Configuration sur UEFI (l'image est prévue pour un démarrage UEFI)
5. Attacher un disque : Clone from Image > sélectionner l'image uploadée
6. Ajouter un NIC sur le subnet/VLAN souhaité
7. Sauvegarder et démarrer la VM

Proxmox VE

1. Copier le fichier .qcow2 fourni sur l'hôte Proxmox
2. Créer une VM sans disque : 2 vCPU, 2 GB RAM, BIOS : OVMF (UEFI) avec un disque EFI (l'image est prévue pour un démarrage UEFI)
3. Importer l'image :

   qm importdisk <vmid> ovsgw-*.qcow2 <storage>
   

4. Attacher le disque importé, le définir comme périphérique de boot
5. Connecter un bridge, démarrer la VM

KVM / libvirt (sans Proxmox)

Créer et démarrer la VM directement depuis l'image :

virt-install --name overview-outpost --memory 2048 --vcpus 2 \
  --disk /var/lib/libvirt/images/ovsgw.qcow2 --import \
  --osinfo ubuntu24.04 --boot uefi \
  --network bridge=br0 --noautoconsole

Les 28 entrées à déclarer, chacune en TCP 443 et UDP 3478 :

derp1-all.tailscale.com
derp2-all.tailscale.com
derp3-all.tailscale.com
derp4-all.tailscale.com
derp5-all.tailscale.com
derp6-all.tailscale.com
derp7-all.tailscale.com
derp8-all.tailscale.com
derp9-all.tailscale.com
derp10-all.tailscale.com
derp11-all.tailscale.com
derp12-all.tailscale.com
derp13-all.tailscale.com
derp14-all.tailscale.com
derp15-all.tailscale.com
derp16-all.tailscale.com
derp17-all.tailscale.com
derp18-all.tailscale.com
derp19-all.tailscale.com
derp20-all.tailscale.com
derp21-all.tailscale.com
derp22-all.tailscale.com
derp23-all.tailscale.com
derp24-all.tailscale.com
derp25-all.tailscale.com
derp26-all.tailscale.com
derp27-all.tailscale.com
derp28-all.tailscale.com

Cette liste est un instantané. Tailscale ajoute et retire des régions ; la source fait foi. Pour la régénérer :

curl -s https://login.tailscale.com/derpmap/default |
  python3 -c "import json,sys; [print('derp%s-all.tailscale.com' % k) for k in sorted(json.load(sys.stdin)['Regions'], key=int)]"

Les régions couvrent plusieurs continents : c'est normal, la VM mesure la latence vers l'ensemble des relais pour choisir le plus proche. Voir la FAQ sur ce point.

Trois règles au lieu de six, et une seule entrée à maintenir au lieu d'une trentaine — à condition que votre firewall accepte un objet FQDN wildcard. FortiGate, Check Point et la plupart des UTM le font ; Palo Alto et Cisco ASA le refusent.

Tout autre trafic sortant : REFUSER.

Le périmètre reste le même — tout est restreint au domaine tailscale.com — mais le firewall suit lui-même les serveurs DERP au lieu de vous faire tenir la liste à jour.

FortiOS expose un objet Internet Service (ISDB) Tailscale-Tailscale, maintenu par FortiGuard : il contient déjà les plages IP et les ports de l'infrastructure Tailscale. C'est la méthode la plus simple et la plus robuste — aucun FQDN ni serveur DERP à suivre.

Interface graphique

1. Policy & Objects > Firewall Policy > Create New
2. Source : l'objet adresse de la VM · Destination : basculer sur l'onglet Internet Service et rechercher Tailscale
3. Sélectionner Tailscale-Tailscale, action ACCEPT, et désactiver l'inspection SSL profonde

CLI (FortiOS 7.x)

config firewall address
    edit "OverView-OutPost"
        set subnet 192.0.2.10 255.255.255.255
    next
    edit "OverView-Egress"
        set subnet 51.15.222.156 255.255.255.255
    next
end

config firewall service custom
    edit "WireGuard-OverView"
        set udp-portrange 32768-60999
    next
end

config firewall policy
    edit 0
        set name "OutPost-Tailscale"
        set srcintf "dmz"
        set dstintf "wan1"
        set srcaddr "OverView-OutPost"
        set internet-service enable
        set internet-service-name "Tailscale-Tailscale"
        set action accept
        set schedule "always"
        set ssl-ssh-profile "no-inspection"
        set nat enable
    next
    edit 0
        set name "OutPost-WireGuard"
        set srcintf "dmz"
        set dstintf "wan1"
        set srcaddr "OverView-OutPost"
        set dstaddr "OverView-Egress"
        set service "WireGuard-OverView"
        set action accept
        set schedule "always"
        set nat enable
    next
end

Variante sans ISDB — FortiOS accepte les objets FQDN wildcard dans le champ dstaddr d'une policy :

config firewall address
    edit "Tailscale-Wildcard"
        set type wildcard-fqdn
        set wildcard-fqdn "*.tailscale.com"
    next
end

Réglages par défaut qui cassent Tailscale

C'est la cause la plus fréquente sur FortiGate : la règle est correcte, mais un profil actif par défaut coupe le flux.

Diagnostic express

# La base ISDB est-elle chargée ? (taille, version, nombre d'entrées)
diagnose internet-service id-summary

# À quel objet ISDB appartient réellement une IP Tailscale ?
diagnose internet-service match root <IP_TAILSCALE> 255.255.255.255

# Quel service correspond à un tuple protocole / port / IP ?
diagnose internet-service info root 6 443 <IP_TAILSCALE>

# Tracer le cheminement du flux dans les policies
diagnose debug flow filter saddr 192.0.2.10
diagnose debug flow show function-name enable
diagnose debug flow trace start 20
diagnose debug enable
# … puis pour arrêter :
diagnose debug disable
diagnose debug reset

# Que voit réellement passer le FortiGate ?
diagnose sniffer packet any 'host 51.15.222.156' 4

Si diagnose internet-service match ne renvoie pas Tailscale-Tailscale pour une IP de derp1-all.tailscale.com, la base ISDB est trop réduite ou périmée : corrigez internet-service-database avant de toucher aux règles.

Port WireGuard — Fortinet recommande de randomiser le port client WireGuard. Ce réglage se fait côté tailnet : contactez le support OverSOC si les connexions directes n'aboutissent jamais.

Deux façons de désigner la destination. L'App-ID est préférable : PAN-OS n'accepte pas de wildcard dans un objet FQDN (*.tailscale.com est refusé), et un objet FQDN ne mémorise que 32 adresses alors que controlplane.tailscale.com en publie déjà 16 en IPv4 et 16 en IPv6.

Option A — règle App-ID (recommandée)

Interface graphique

1. Objects > Addresses > Add — créer deux objets d'adresse, chacun avec une Description pour que l'administrateur suivant sache de quoi il s'agit :
   • OVS-OUTPOST, l'IP de votre OutPost en /32, ex. 192.0.2.10/32 — VM OverView OutPost en DMZ, source de tout le trafic OverView
   • OVS-OVERVIEW, 51.15.222.156/32, à reprendre tel quel — IP de sortie de la plateforme OverView, pair du tunnel WireGuard direct
2. Objects > Services > Add — créer le service qu'utilisera la seconde règle :
   • Name : SVC-WIREGUARD
   • Description : plage de ports UDP du tunnel WireGuard direct entre l'OutPost et OverView
   • Protocol : UDP
   • Destination Port : 32768-60999
   • Source Port : laisser vide. L'OutPost choisit lui-même son port source, le restreindre ici couperait le tunnel
   • Session Timeout : Inherit from application
3. Policies > Security > Add — onglet par onglet :
   • General : Name ALLOW-TAILSCALE, et une Description du type OverView OutPost : control plane Tailscale et relais chiffrés. À retirer en même temps que la VM OutPost.
   • Source : Source Zone est la zone où se trouve l'OutPost, choisie parmi vos propres zones, donc rarement nommée dmz : elle porte le nom que ce segment a sur votre firewall. Source Address est l'objet OVS-OUTPOST créé plus haut. Laissez Source User et Source Device sur any, et Negate décoché
   • Destination : zone untrust (votre zone WAN), adresse Any
   • Application : ajouter tailscale, tailscale-base, stun et ssl. PAN-OS indique ce dont une application a besoin dans le panneau Depends On, à côté de la liste, et avertit au commit lorsqu'une règle en oublie une : ajoutez ce qui y figure. Les content releases actuelles associent tailscale à tailscale-base
   • Service/URL Category : application-default
   • Actions : Allow
4. Ajouter une seconde règle pour le tunnel direct, avec les mêmes onglets :
   • General : Name ALLOW-WIREGUARD, Description OverView OutPost : tunnel WireGuard direct vers la plateforme OverView. Sans elle, le trafic bascule sur les relais.
   • Source : la même zone que la règle précédente, adresse OVS-OUTPOST
   • Destination : zone untrust, adresse OVS-OVERVIEW
   • Application : any
   • Service/URL Category : SVC-WIREGUARD
   • Actions : Allow
5. Déplacer les deux règles au-dessus de la règle qui bloque les catégories VPN / proxy (Move > Move Up, ou glisser dans la liste)
6. Commit

CLI équivalente

set address OVS-OUTPOST  ip-netmask 192.0.2.10/32 description "VM OverView OutPost en DMZ"
set address OVS-OVERVIEW ip-netmask 51.15.222.156/32 description "IP de sortie de la plateforme OverView"
set service SVC-WIREGUARD protocol udp port 32768-60999 description "Tunnel WireGuard direct, OutPost vers OverView"

set rulebase security rules ALLOW-TAILSCALE from dmz to untrust \
    source OVS-OUTPOST destination any \
    application [ tailscale tailscale-base stun ssl ] \
    service application-default action allow \
    description "OverView OutPost : control plane Tailscale et relais chiffres"

set rulebase security rules ALLOW-WIREGUARD from dmz to untrust \
    source OVS-OUTPOST destination OVS-OVERVIEW \
    application any service SVC-WIREGUARD action allow \
    description "OverView OutPost : tunnel WireGuard direct vers OverView"

move rulebase security rules ALLOW-TAILSCALE top

Option B — si l'App-ID tailscale est absent de votre content release

L'objet FQDN ne pouvant pas porter de wildcard, il faut combiner deux objets :

1. Objects > Addresses — un objet FQDN par nom : controlplane.tailscale.com, login.tailscale.com, log.tailscale.com, puis un objet derpN-all.tailscale.com par région DERP (liste vivante). Les regrouper dans Objects > Address Groups.
2. Objects > Custom Objects > URL Category > Add — catégorie TAILSCALE contenant *.tailscale.com/
3. Dans la règle : le groupe d'adresses en Destination, la catégorie personnalisée dans l'onglet Service/URL Category

Points d'attention

• NAT — Policies > NAT, sur la règle qui s'applique à la VM, onglet Translated Packet : type de traduction Persistent Dynamic IP and Port (PAN-OS 11.1.1 et supérieur). Sur un PAN-OS plus ancien, créez une règle NAT Static IP dédiée à la VM — avec la traduction dynamique classique, le port source est imprévisible et tout passe par les relais DERP.
• Déchiffrement — Policies > Decryption : ajouter une règle No Decrypt pour OVS-OUTPOST. tailscaled refuse un certificat ré-signé, l'enrôlement échoue.
• Security Profiles — piège suivant une fois la règle en place : le trafic apparaît en allow dans Monitor > Traffic mais la session est quand même coupée. Regarder Monitor > Threat : un profil Vulnerability Protection ou Anti-Spyware attaché à la règle peut la reset. Le retirer pour cette règle.
• Signature du blocage — un RST immédiat après le ClientHello trahit une action reset-both sur une règle placée plus haut, pas un port 443 fermé.

Diagnostic express

# La règle matche-t-elle vraiment ?
test security-policy-match from dmz to untrust source 192.0.2.10 \
    destination <IP_TAILSCALE> destination-port 443 protocol 6

# Les objets FQDN sont-ils résolus ? (mapping, TTL restant, dernier refresh)
request system fqdn show

# Forcer une actualisation (toute la table — il n'existe pas de refresh unitaire)
request system fqdn refresh

Dans Monitor > Traffic, le filtre (addr.src eq 192.0.2.10) and (app eq tailscale) isole le trafic de l'OutPost et désigne la règle responsable dans la colonne Rule.

Selon Tailscale, Check Point établit des connexions directes sans configuration particulière. Il reste à créer la règle sortante.

Objets

Le point initial est obligatoire. Case FQDN décochée = mode non-FQDN, qui fait correspondre le domaine et ses sous-domaines (controlplane., derp1-all.…). Cochée, l'objet ne matcherait que tailscale.com et www.tailscale.com.

Règles

Points d'attention

• Le mode non-FQDN s'appuie sur des résolutions DNS inverses : si le matching est instable, remplacez l'objet Domain par des objets Domain FQDN nommés un par un.
• Exclure la source OverView-OutPost de l'HTTPS Inspection — l'interception TLS casse l'enrôlement Tailscale.

Diagnostic express

# Paquets rejetés en temps réel, avec le motif du drop (Ctrl+C pour arrêter)
fw ctl zdebug + drop | grep 192.0.2.10

# Tables noyau du résolveur DNS inverse utilisées par les objets Domain
fw ctl multik print_bl dns_reverse_cache_tbl

# Relancer le résolveur si les objets Domain ne matchent plus,
# puis réinstaller la politique
killall wsdnsd

Les logs se consultent dans SmartConsole, onglet Logs & Monitor, filtrés sur la source OverView-OutPost.

ASA — les objets network de type fqdn n'acceptent pas de wildcard, et la résolution DNS doit être fonctionnelle sur l'appliance elle-même.

dns domain-lookup outside
dns server-group DefaultDNS
 name-server 8.8.8.8

! 192.0.2.10 = l'IP de votre OutPost — remplacez-la par la vôtre
object network OVS-OUTPOST
 host 192.0.2.10
object network OVS-OVERVIEW
 host 51.15.222.156

object network TS-CONTROLPLANE
 fqdn controlplane.tailscale.com
object network TS-LOGIN
 fqdn login.tailscale.com
object network TS-DERP1
 fqdn derp1-all.tailscale.com
! … un objet par région DERP publiée dans la derp map

object-group network TS-ALL
 network-object object TS-CONTROLPLANE
 network-object object TS-LOGIN
 network-object object TS-DERP1

access-list DMZ_OUT extended permit tcp object OVS-OUTPOST object-group TS-ALL eq 443
access-list DMZ_OUT extended permit udp object OVS-OUTPOST object-group TS-ALL eq 3478
access-list DMZ_OUT extended permit udp object OVS-OUTPOST object OVS-OVERVIEW range 32768 60999
access-group DMZ_OUT in interface dmz

Firepower / FTD — les objets URL acceptent les wildcards. Créez un objet URL .tailscale.com et utilisez-le dans l'onglet URLs d'une règle Access Control, plutôt que d'énumérer 28 objets FQDN.

Points d'attention

• Sans ouverture de port dédiée côté NAT, Cisco force le trafic à passer par les relais DERP : c'est fonctionnel, simplement plus lent.
• Cisco Umbrella (agent poste) : aucun contournement connu, le trafic emprunte toujours les relais.
• Ne pas activer le déchiffrement SSL/TLS sur ce flux.

Diagnostic express

! ASA — simuler le flux à travers la politique
packet-tracer input dmz tcp 192.0.2.10 12345 <IP_TAILSCALE> 443 detailed

! Les objets FQDN sont-ils résolus ?
show dns
show run object network

! L'ACL est-elle réellement traversée ? (compteurs de hits)
show access-list DMZ_OUT

Sur Firepower / FTD, les logs équivalents sont dans Analysis > Connection Events, filtrés sur l'IP de la VM.

Alias

Créez des alias de type Host(s) — les alias pfSense/OPNsense résolvent les FQDN périodiquement, mais n'acceptent pas de wildcard :

Règles (interface DMZ)

Point d'attention — NAT sortant

Par défaut le NAT réécrit le port source, ce qui empêche la connexion directe. Passez Firewall > NAT > Outbound en mode Hybrid ou Manual, puis cochez Static Port sur la règle qui couvre l'IP de la VM. Activer NAT-PMP ou UPnP produit le même résultat.

Diagnostic express

# Que contient réellement l'alias après résolution DNS ?
pfctl -t Tailscale_CP -T show

# États ouverts depuis la VM
pfctl -ss | grep 192.0.2.10

Dans tous les cas, un firewall qui laisse passer TCP/443 sortant suffit à faire fonctionner l'OutPost.