Ouverture d’un flux entre deux zones du pare-feu SRX300

Version

1.0

Date d’édition

05/10/2026

Ouvrir un flux précis entre deux zones du pare-feu, hôte par hôte et service par service, avec un retour arrière automatique tant que le test n’est pas concluant.

1. Objet

Le pare-feu SRX300 du laboratoire bloque par défaut tout trafic entre zones (voir HL-PRC-001). Chaque service qui doit être joint depuis une autre zone demande donc une politique explicite. Cette procédure décrit l’ajout d’une telle politique, de la vérification des noms de zones jusqu’au test depuis l’hôte source, puis le diagnostic d’un flux qui reste bloqué.

Le cas de référence du 5 octobre 2026 utilise la politique hermes-n8n pour autoriser un client de la zone lab à joindre l’API de n8n publiée par le proxy inverse dans la zone srv. La démarche reste la même pour un autre client autorisé, avec les paramètres adaptés.

2. Périmètre et prérequis

Périmètre

Couvert : ouverture d’un flux d’un hôte vers un hôte, sur un service, entre deux zones existantes ; validation ; diagnostic ; retour arrière.

Hors périmètre : création d’une zone ou d’une sous-interface, traduction d’adresses, flux entrants depuis Internet.

Prérequis

• Accès SSH au pare-feu avec le compte d’administration nominatif, depuis la zone d’administration.
• Le besoin exprimé précisément : hôte source, hôte destination, service, sens du flux.
• Un accès à l’hôte source pour tester le flux : un test lancé depuis une autre machine ne prouve rien.

3. Rôles et responsabilités

4. Procédure

Paramètres

1. Vérifier les noms de zones

Les noms de zones sont sensibles à la casse. Dans ce laboratoire, ils sont tous en minuscules : adm, srv, dmz, cli, voip, dep, wfi, lab, untrust. Un nom repris d’un brouillon sans vérification fait échouer le contrôle de cohérence.

# mode configuration [edit]
run show security zones terse
run show security policies from-zone lab to-zone srv

La seconde commande liste, dans l’ordre, les politiques déjà en place pour ce couple de zones. Repérer une éventuelle politique de refus : une nouvelle politique s’ajoute en fin de liste et resterait sans effet sous un refus.

2. Nommer la source et la destination

Une politique ne désigne jamais une adresse IP directement : elle désigne des entrées du carnet d’adresses. Une adresse d’hôte en /32 limite l’ouverture à une seule machine.

set security address-book global address HERMES 10.10.80.10/32
set security address-book global address srv-proxy 10.10.20.12/32

Si l’entrée existe déjà, c’était le cas de HERMES créée pour la politique hermes-deploy, la ligne peut être omise.

3. Choisir l’application

Les services courants existent sous forme d’applications prédéfinies : junos-ssh, junos-https, junos-http, junos-ping. Un port spécifique demande une application personnalisée, comme celle créée pour l’API Proxmox :

set applications application pve-api protocol tcp destination-port 8006

4. Écrire la politique

set security policies from-zone lab to-zone srv policy hermes-n8n match source-address HERMES
set security policies from-zone lab to-zone srv policy hermes-n8n match destination-address srv-proxy
set security policies from-zone lab to-zone srv policy hermes-n8n match application junos-https
set security policies from-zone lab to-zone srv policy hermes-n8n then permit

Si une politique de refus existe pour ce couple de zones, placer la nouvelle politique avant elle :

insert security policies from-zone lab to-zone srv policy hermes-n8n before policy <politique_de_refus>

5. Contrôler, puis appliquer avec retour automatique

show | compare
commit check
commit confirmed 5

show | compare affiche exactement ce qui va changer : seules les lignes des étapes 2 à 4 doivent apparaître. commit confirmed 5 applique la configuration et programme son annulation dans cinq minutes : si le test échoue ou si un accès est perdu, la configuration précédente revient d’elle-même. Ne pas enchaîner les trois commandes sans lire leur sortie.

6. Tester depuis l’hôte source

Le test de ce flux doit être lancé depuis le client source défini dans la politique. Un essai depuis une autre machine fournit un diagnostic complémentaire, mais ne valide pas cette ouverture.

# ouverture du port, sans outil supplémentaire
timeout 6 bash -c '</dev/tcp/10.10.20.12/443' && echo OUVERT || echo BLOQUE
# réponse du service, certificat vérifié par l’autorité racine interne
curl -sS --cacert <autorite_racine_interne.pem> -o /dev/null -w '%{http_code}' https://n8n.srv.dozylab.lan/healthz; echo

Résultat obtenu le 5 octobre : port ouvert, code HTTP 200. Le certificat est vérifié par l’autorité racine interne émise par AD CS : la vérification TLS n’est jamais désactivée pour faire passer un test.

7. Confirmer

commit

Sans cette confirmation dans le délai, la politique est retirée automatiquement.

Diagnostiquer un flux bloqué

Lire le symptôme avant de toucher au pare-feu.

# juste après une tentative, depuis le pare-feu
run show security flow session destination-prefix 10.10.20.12 destination-port 443

L’absence de session ne suffit pas à localiser le blocage : vérifier que le trafic atteint ce pare-feu, les zones, la route et l’ordre des politiques. Une session sans réponse impose aussi de contrôler le service destination et le chemin retour ; elle ne prouve pas à elle seule un blocage sur l’hôte.

Le cas de référence a commencé ainsi : depuis la zone lab, l’API de n8n ne répondait ni en 443 ni en 5678, avec un délai dépassé et aucun refus, alors que le même service répondait 200 depuis la zone srv. Le blocage venait donc du pare-feu, pas de n8n.

Retour arrière

Pièges connus

5. Intégration réseau

Exemples de politiques inter-zones documentées au 5 octobre 2026 pour WatchTower et le client de référence, chacune limitée à un hôte source, un hôte destination et un service :

Le client de référence n’a pas de flux ouvert vers l’API Proxmox : cette procédure ne lui attribue aucun droit d’administration sur l’hyperviseur.

6. Durcissement et sécurité

• Une politique par besoin, nommée d’après son usage. Jamais l’ouverture d’un sous-réseau entier quand un hôte suffit.
• Un service précis : pas d’application any entre zones de serveurs et de laboratoire.
• Contournement à retirer : avant la politique hermes-n8n, l’API de n8n n’était joignable qu’en rebondissant par SSH sur WatchTower, avec l’accord explicite du propriétaire. Ce rebond n’a plus lieu d’être.
• Chaque ouverture est reportée dans la matrice de flux du pare-feu (HL-PRC-001).

7. Vérifications finales

8. Références et historique des révisions

• HL-PRC-001 — Mise en service d’un pare-feu Juniper SRX300 : zones, carnet d’adresses et matrice de flux d’origine.
• Accès SSH par clé à un hôte du laboratoire : diagnostic côté hôte quand le réseau répond.
• Juniper Networks — documentation Junos OS : politiques de sécurité, carnet d’adresses, commit confirmed.