Améliorer la disponibilité d'un Tunnel Branch Office VPN (BOVPN)
- Connexion Externe Non Fiable — Un ou les deux endpoints BOVPN peuvent avoir des connexions externes avec une latence élevée, une fragmentation de paquets élevée et une perte de paquets élevée, ce qui peut rendre une connexion peu fiable. Ces facteurs ont des conséquences plus importantes sur le trafic BOVPN que sur d'autres trafics courants, comme HTTP ou SMTP. Dans le trafic BOVPN, les paquets chiffrés doivent arriver au endpoint de destination, être déchiffrés, puis réassemblés avant que le trafic non chiffré puisse être acheminé à l'adresse IP de destination.
- Anciens endpoints et logiciels WatchGuard — Nous effectuons des tests de compatibilité entre les nouveaux produits WatchGuard et les périphériques plus anciens en utilisant le dernier logiciel disponible pour les périphériques plus anciens. Avec des logiciels plus anciens, il peut exister des problèmes que nous avons résolus dans des versions de logiciels plus récentes.
- endpoint tiers — les Fireboxes étant basés sur la norme IPSec, ils sont compatibles avec la plupart des endpoints tiers. Toutefois, certains périphériques de terminaison tiers ne sont pas conformes à la norme IPSec en raison de problèmes logiciels ou de paramètres propriétaires.
- Trafic faible ou nul — S'il y a un faible volume de trafic dans un tunnel IPSec, ou s'il y a de longues périodes pendant lesquelles aucun trafic ne traverse le tunnel, le Firebox et la plupart des endpoints tiers se déchirent intentionnellement la connexion VPN. Ceci est fait pour éviter les attaques par force brute entre les clés renouvelées automatiques. Lorsque le trafic essaie à nouveau de traverser le tunnel, le tunnel est reconstruit et la clé renouvelée.
Si les problèmes de disponibilité de BOVPN persistent après la Mise à Niveau de Fireware OS, essayez ces options :
Dans les paramètres IKEv1, vous pouvez activer Dead Peer Detection, une norme de l'industrie utilisée par la plupart des périphériques IPSec. Nous vous recommandons de sélectionner la détection DPD (Dead Peer Detection) si les deux périphériques de terminaison la prennent en charge.
Lorsque vous activez la détection DPD (Dead Peer Detection), le Firebox surveille le trafic du tunnel pour déterminer si celui-ci est actif. Si aucun trafic n'a été reçu du pair distant pendant la durée spécifiée par la valeur Délai d'inactivité du trafic et qu'un paquet attend d'être envoyé au pair, le Firebox envoie une requête. S'il n'y a pas de réponse après le nombre de Tentatives maximales, le Firebox arrête le tunnel et renégocie la connexion de phase 1. Pour plus d'informations sur la détection Dead Peer Detection, consultez RFC 3706.
Nous vous recommandons de ne pas activer IKE Keep-alive, une technologie plus ancienne moins fiable et moins évolutive.
Pour activer la Détection Dead Peer Detection, dans Fireware Web UI :
- Sélectionnez VPN > Branch Office VPN.
- Sélectionnez la passerelle souhaitée, puis cliquez sur Modifier.
- Sélectionnez l'onglet Paramètres de Phase 1.
- Sélectionnez Dead Peer Detection (RFC3706).
Pour activer la Détection Dead Peer Detection, dans Policy Manager :
- Sélectionnez VPN > Passerelles Branch Office.
- Sélectionnez la passerelle souhaitée, puis cliquez sur Modifier.
- Sélectionnez l'onglet Paramètres de Phase 1.
- Sélectionnez Dead Peer Detection (RFC3706).
Les paramètres BOVPN par défaut sur le Firebox sont destinés à assurer la compatibilité avec les anciens périphériques WatchGuard et les périphériques tiers. Si le périphérique d'endpoint du pair prend en charge IKEv2 et des paramètres de chiffrement et d'authentification plus puissants, nous vous recommandons de modifier les paramètres par défaut pour une sécurité et des performances accrues.
Ces tableaux indiquent les valeurs par défaut et recommandées pour chaque paramètre BOVPN.
| Paramètres BOVPN | Valeurs par Défaut (pour la compatibilité) | Valeurs Recommandées (pour les performances et la sécurité) |
|---|---|---|
| Version | IKEv1 | IKEv2 |
| Mode | Principal
(Sélectionnez Agressif si l'un des périphériques a une adresse IP externe dynamique.) |
Non applicable si vous sélectionnez IKEv2 comme version |
| Parcours NAT | Oui | Oui |
| Intervalle de Conservation d'Activité du Parcours NAT | 20 secondes | 20 secondes |
| Conservation d'activité IKE (I) | Désactivé | Désactivé |
| Intervalle entre les messages de conservation d'activité IKE | Aucun(e) | Aucun(e) |
| Nombre d'échecs max de la conservation d'activité IKE | Aucun(e) | Aucun(e) |
| Détection DPD (Dead Peer Detection) (RFC3706) | Activé | Activé |
| Délai d'Inactivité du Trafic de la détection DPD (Dead Peer Detection) | 20 secondes | 20 secondes |
| Nombre maximal de tentatives de détection DPD (Dead Peer Detection) | 5 | 5 |
| Paramètres de Transformation de Phase 1 | Valeurs par Défaut (pour la compatibilité) | Valeurs Recommandées (pour les performances et la sécurité)1 |
|---|---|---|
| Algorithme d'authentification | SHA2-256 | Non applicable si vous spécifiez AES-GCM comme algorithme de chiffrement |
| Algorithme de chiffrement | AES (256 bits) | AES-GCM (256 bit)2 |
| SA Life ou expiration de la négociation (heures) | 24 | 24 |
| Groupe Diffie-Hellman | 14 | 202 |
1. Dans les paramètres de Phase 1, vous devez sélectionner l'option IKEv2 pour voir les options AES-GCM.
2. Étant donné que les paramètres de Phase 1 n'ont généralement pas d'impact sur les performances de BOVPN, nous recommandons AES-GCM (256 bits) et Diffie-Hellman Group 20 pour une plus grande sécurité.
| Paramètres de proposition de PHASE 2 | Valeurs par Défaut (pour la compatibilité) | Valeurs Recommandées (pour les performances et la sécurité) |
|---|---|---|
| Type | ESP | ESP |
| Algorithme d'authentification | SHA2-256 | Non applicable si vous spécifiez AES-GCM comme algorithme de chiffrement |
| Algorithme de chiffrement | AES (256 bits) | AES-GCM (128-bit) |
| Forcer l'expiration de la clé | Activer | Activer |
| Temps d'Expiration de la Clé de Phase 2 (heures) | 8 | 8 |
| Perfect Forward Secrecy (PFS) | Activé | Activé |
| Groupe Diffie-Hellman | 14 | 19 |
N'activez pas le paramètre Trafic d'Expiration de Clé de Phase 2 (kilo-octets), qui est un paramètre par défaut dans Fireware v11.9.1 ou une version antérieure. Ce paramètre peut provoquer des reprises excessives, une charge CPU élevée et des paquets perdus, ce qui peut déstabiliser votre VPN. Le paramètre Trafic d'Expiration de Clé de Phase 2 (kilo-octets) n'est pas compatible avec la plupart des périphériques tiers.
Si aucun trafic ne passe par un tunnel IPSec pendant un certain temps, un endpoint de passerelle peut décider que l'autre endpoint est indisponible et détruire le tunnel. l'endpoint de la passerelle ne renégociera pas le tunnel VPN tant que le trafic ne sera pas à nouveau envoyé à travers le tunnel. Dans les paramètres de Phase 1, si vous spécifiez IKEv2, ce processus se produit rapidement et peut ne pas être perceptible.
Si vous remarquez des paquets perdus, vérifiez la version spécifiée dans vos paramètres de Phase 1. Si vous avez spécifié IKEv1 et que vous utilisez les autres paramètres par défaut des Phases 1 et 2, en particulier les paramètres par défaut de Fireware v11.x ou les versions antérieures, vous remarquerez peut-être des paquets perdus lors des renouvellements de clés.
Si vous utilisez IKEv1 et les paramètres par défaut hérités, et que vous avez remarqué des paquets perdus pendant les reprises, assurez-vous que le trafic passe par le tunnel à tout moment.
Par exemple, vous pouvez envoyer ces types de trafic à travers le tunnel :
- Ping continu
- Messages de journal
- SNMP
- Autres logiciels de surveillance
Ping Continu
Pour une solution simple, vous pouvez configurer un ping continu pour envoyer le trafic via le tunnel vers un périphérique fiable, tel qu'un serveur.
Messages de Journal
Vous pouvez configurer le Firebox pour envoyer des messages de journal via le tunnel VPN à un serveur log server.
Si vous n'avez pas de serveur log server, vous pouvez configurer volontairement le Firebox de sorte qu'il envoie des messages de journal à un serveur log server qui n'existe pas. Cela crée une quantité cohérente mais faible de trafic envoyé à travers le tunnel, ce qui peut aider à réduire le nombre de reconstructions et de renouvellements de clés.
Lorsque vous spécifiez une adresse IP pour le serveur log server, que le serveur log server existe ou non, suivez ces instructions :
- L'adresse IP du serveur log server que vous spécifiez doit être une adresse IP incluse dans les paramètres de routage du tunnel distant.
Pour plus d'informations, consultez Ajouter des Routes à un Tunnel. - L'adresse IP du serveur log server ne doit pas être une adresse IP attribuée à un périphérique réel.
Vous devez également déterminer le type de journalisation à utiliser. Différents types de journalisation génèrent des volumes de trafic différents :
WatchGuard Dimension
Aucune donnée de journal n'est envoyée tant que le Firebox n'est pas connecté à Dimension. Les seuls types de trafic envoyés à travers le tunnel sont les tentatives de connexion à Dimension. Cela peut constituer un trafic suffisant pour contribuer à la stabilité du tunnel, tout en ayant une incidence mineure sur le reste du trafic BOVPN.
Syslog
Les données de journal sont immédiatement envoyées à l'adresse IP du serveur SysLog. Le volume de données du journal dépend du trafic géré par le périphérique. La journalisation de Syslog génère habituellement un certain trafic, car des paquets transitent en permanence par le tunnel. En certaines occasions, le volume de trafic peut ralentir le trafic BOVPN ordinaire, mais c'est assez rare.
Pour améliorer la stabilité et avoir le moins d'impact sur le trafic BOVPN, essayez d'abord Dimension. Si cela n'améliore pas la stabilité du tunnel BOVPN, essayez la journalisation de Syslog.
Les différentes options que vous pouvez utiliser sont les suivantes :
- Configurez un endpoint de sorte qu'il envoie du trafic de journal Dimension à travers le tunnel.
- Configurez l'autre endpoint de sorte qu'il envoie du trafic de journal Dimension à travers le tunnel.
- Configurez les deux endpoints de sorte qu'ils envoient du trafic de journal Dimension à travers le tunnel.
- Configurez un endpoint de sorte qu'il envoie du trafic de journal Syslog via le tunnel.
- Configurez uniquement l'autre endpoint de sorte qu'il envoie du trafic de journal Syslog via le tunnel.
- Configurez les deux endpoints de sorte qu'ils envoient du trafic de journal Syslog via le tunnel.
Pour configurer votre Firebox de sorte qu'il envoie des données de journal à un serveur WatchGuard Dimension Server à travers le tunnel, consultez Ajouter un Serveur Dimension ou WSM Log Server.
Pour configurer votre Firebox de sorte qu'il envoie des données Syslog à travers le tunnel, consultez Configurer les Paramètres de Serveur Syslog.
Messages SNMP
Vous pouvez configurer votre Firebox pour qu'il envoie des informations à un serveur SNMP. Pour plus d'informations, consultez À propos du Protocole SNMP.