From 6fcc794b360ebaf3c13b60af63c9f01ba6834c9e Mon Sep 17 00:00:00 2001
From: Nicole Rappe <nicole.rappe@bunny-lab.io>
Date: Fri, 9 Aug 2024 16:27:07 -0600
Subject: [PATCH] Update Networking/Sophos/IPSec Site-to-Site VPN Tunnel.md

---
 .../Sophos/IPSec Site-to-Site VPN Tunnel.md      | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Networking/Sophos/IPSec Site-to-Site VPN Tunnel.md b/Networking/Sophos/IPSec Site-to-Site VPN Tunnel.md
index f692528..62b2bb9 100644
--- a/Networking/Sophos/IPSec Site-to-Site VPN Tunnel.md	
+++ b/Networking/Sophos/IPSec Site-to-Site VPN Tunnel.md	
@@ -39,6 +39,22 @@ Navigate to "**Configure > Site-to-Site VPN > Add**"
 !!! tip "Best Practices - Initiators / Responders"
     If you have a hub-and-spoke network, where one location acts as a central authority (e.g. domain controllers, auth servers, identity providers, headquarters, etc), you will set up the central "hub" as a VPN responder on its side of the VPN tunnel, and all the remote "spoke" locations would behave as VPN initiators.
 
+``` mermaid
+graph TB
+    Responder((Responder))
+    Initiator1((Initiator 1))
+    Initiator2((Initiator 2))
+    Initiator3((Initiator 3))
+    Initiator4((Initiator 4))
+    Initiator5((Initiator 5))
+
+    Responder --> Initiator1
+    Responder --> Initiator2
+    Responder --> Initiator3
+    Responder --> Initiator4
+    Responder --> Initiator5
+```
+
 !!! note "Tunnel IDs / Subnets"
     If one side of the tunnel indicates a Local ID, you need to input that as the Remote ID on the other end of the tunnel.  While Tunnel IDs are generally optional, if one side uses them, both need to.