diff --git a/pages/site-to-site-vpn/index.mdx b/pages/site-to-site-vpn/index.mdx
new file mode 100644
index 0000000000..32535653ea
--- /dev/null
+++ b/pages/site-to-site-vpn/index.mdx
@@ -0,0 +1,64 @@
+---
+meta:
+  title: Site-to-Site VPN Documentation
+  description: Explore Scaleway Site-to-Site VPN. Connect your Scaleway VPC to your remote infrastructure, via an encrypted, private VPN tunnel.
+  noindex: true
+---
+
+<Message
+  type="note"
+  title="Site-to-Site VPN is in Private Beta"
+>
+  Site-to-Site VPN is currently in Private Beta, and available to selected testers only via the Scaleway API. [Request an invitation](https://www.scaleway.com/en/betas/#site-to-site-vpn).
+</Message>
+
+
+<ProductHeader 
+   productName="Site-to-Site VPN"
+   productLogo="sns"
+   description="Securely connect your Scaleway VPC to your remote infrastructure, enabling encrypted data exchange over a private tunnel."
+   url="/site-to-site-vpn/reference-content/understanding-s2svpn/"
+   label="Understanding Site-to-Site VPN"
+/>
+
+## Getting Started
+
+<Grid>
+    <SummaryCard
+        title="Understanding Site-to-Site VPN"
+        icon="rocket"
+        description="Learn how to start using Site-to-Site VPN"
+        label="View Doc"
+        url="/site-to-site-vpn/reference-content/understanding-s2svpn/"
+    />
+    <SummaryCard
+        title="Site-to-Site VPN statuses"
+        icon="info"
+        description="Understand VPN statuses."
+        label="View Doc"
+        url="/site-to-site-vpn/reference-content/statuses/"
+    />
+        <SummaryCard
+        title="Security proposals"
+        icon="info"
+        description="Encryption and authentication explained"
+        label="View Doc"
+        url="/site-to-site-vpn/reference-content/security-proposals/"
+    />
+</Grid>
+
+
+<ClickableBanner
+    productLogo="cli"
+    title="Site-to-Site VPN APIs"
+    description="Manage Site-to-Site VPN using the Scaleway API."
+    url="https://www.scaleway.com/en/developers/api/s2s-vpn/"
+    label="Go to Scaleway Site-to-Site VPN API"
+/>
+
+## Changelog
+
+<ChangelogList
+    productName="site-to-site-vpn"
+    numberOfChanges={3}
+/>
\ No newline at end of file
diff --git a/pages/site-to-site-vpn/reference-content/assets/scaleway-s2svpn-conceptual.webp b/pages/site-to-site-vpn/reference-content/assets/scaleway-s2svpn-conceptual.webp
new file mode 100644
index 0000000000..faf2f312a8
Binary files /dev/null and b/pages/site-to-site-vpn/reference-content/assets/scaleway-s2svpn-conceptual.webp differ
diff --git a/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-one-tunnel-both.webp b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-one-tunnel-both.webp
new file mode 100644
index 0000000000..4ef3eaf75a
Binary files /dev/null and b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-one-tunnel-both.webp differ
diff --git a/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-one-tunnel-one-type.webp b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-one-tunnel-one-type.webp
new file mode 100644
index 0000000000..f0afd0bff8
Binary files /dev/null and b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-one-tunnel-one-type.webp differ
diff --git a/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-tunnel-detail.webp b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-tunnel-detail.webp
new file mode 100644
index 0000000000..70cf772e4a
Binary files /dev/null and b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-tunnel-detail.webp differ
diff --git a/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-two-tunnels.webp b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-two-tunnels.webp
new file mode 100644
index 0000000000..2c743d6260
Binary files /dev/null and b/pages/site-to-site-vpn/reference-content/assets/scaleway-vpn-two-tunnels.webp differ
diff --git a/pages/site-to-site-vpn/reference-content/index.mdx b/pages/site-to-site-vpn/reference-content/index.mdx
new file mode 100644
index 0000000000..bc9a996413
--- /dev/null
+++ b/pages/site-to-site-vpn/reference-content/index.mdx
@@ -0,0 +1,10 @@
+---
+meta:
+  title: Site-to-Site VPN - Additional content
+  description: Site-to-Site VPN additional content
+  noindex: true
+content:
+  h1: Site-to-Site VPN - Additional content
+  paragraph: Site-to-Site VPN additional content
+  noindex: true
+---
diff --git a/pages/site-to-site-vpn/reference-content/security-proposals.mdx b/pages/site-to-site-vpn/reference-content/security-proposals.mdx
new file mode 100644
index 0000000000..c2db15116f
--- /dev/null
+++ b/pages/site-to-site-vpn/reference-content/security-proposals.mdx
@@ -0,0 +1,100 @@
+---
+meta:
+  title: Site-to-Site VPN security proposals
+  description: Find out what the different encryption and authentication ciphers available with Scaleway Site-to-Site VPN, and how to to choose the best algorithm for your use case.
+  noindex: true
+content:
+  h1: Site-to-Site VPN security proposals
+  paragraph: Find out what the different encryption and authentication ciphers available with Scaleway Site-to-Site VPN, and how to to choose the best algorithm for your use case.
+  noindex: true
+tags: vpn connection encryption authentication security cipher security-proposal
+categories: 
+  - site-to-site-vpn
+  - network
+dates:
+  validation: 2025-06-03
+  posted: 2025-06-03
+---
+
+<Message type="note">
+Site-to-Site VPN is currently in Private Beta, and available to selected testers only via the Scaleway API. [Request an invitation](https://www.scaleway.com/en/betas/#site-to-site-vpn).
+</Message>
+
+When creating a VPN [connection](/site-to-site-vpn/reference-content/understanding-s2svpn/#connection), you must define a **security proposal** (aka IPSec proposal). The security proposal defines the encryption and authentication methods used to secure the IPSec VPN tunnel.
+
+A security proposal is made up of several parts, each with definable algorithms or settings. You should define these bearing in mind the use case of your Site-to-Site VPN, balancing **security**, **performance** and **compatibility**.
+
+It is important to find the optimal trade-off between these elements: the strongest possible security may be overkill for your use-case, and slow down performance to unacceptable levels. Some algorithms are outdated and not optimal for modern VPNs, but may be the only compatible option for legacy VPNs.
+
+In this document, we explain the different elements of a security protocol, and describe the different algorithms and security options available with Scaleway Site-to-Site VPN, giving advice to help you choose the best options for your use-case.
+
+## Defining a security proposal
+
+There are two parts to a security proposal:
+
+- **IKEv2** (Internet Key Exchange): Establishes a secure connection between the VPN gateway and the customer gateway
+- **ESP** (Encapsulating Security Payload): Encrypts and authenticates the payload of the IP data packets traveling through the tunnel.
+
+When defining your Site-to-Site VPN security proposal, you must define the algorithms/ options to be used for IKEv2 and ESP as described below:
+
+| Protocol        | Element         | Description                                        | User must define?  |
+|-----------------|-----------------|----------------------------------------------------|----------------------------|
+| **IKEv2**       | **Encryption**  | Algorithm to encrypt IKE negotiation messages      | ✅ Yes                      |
+| **IKEv2**       | **Integrity**   | HMAC-based algorithm to verify IKE negotiation messages have not been tampered with. <br/><br/>Only set an HMAC integrity algorithm if **not** using an AEAD algorithm for IKEv2 encryption (see below). Otherwise, integrity is built in, and you do not need to set an IKEv2 integrity algorithm. | ❓ Depends                       |
+| **IKEv2**       | **Key Exchange Method** | DH group to define strength of key exchange | ✅ Yes                      |
+
+| Protocol        | Element         | Description                                        | User must define?  |
+|-----------------|-----------------|----------------------------------------------------|----------------------------|
+| **ESP**         | **Encryption**  | Algorithm to encrypt traffic's data payloads  | ✅ Yes                       |
+| **ESP**         | **Integrity**   | HMAC-based algorithm to verify data payloads have not been tampered with. <br/><br/> Only set an HMAC integrity algorithm if **not** using an AEAD algorithm for ESP encryption (see below). Otherwise, integrity is built in, and you do not need to set an ESP integrity algorithm. | ❓ Depends                         |
+| **ESP**         | **Key Exchange Method**   | DH group to define strength of key exchange         | ❌ No                         |
+
+## Encryption algorithms
+
+The following encryption algorithms are available. 
+
+| Algorithm               | AEAD / non-AEAD* | Key Size (bits)| Security Level | Notes                                         | Recommended?        |
+|-------------------------|------------------|----------------|----------------|-----------------------------------------------|---------------------|
+| `aes256gcm16` (AES-GCM) | AEAD             | 256            | ✅ Very Strong | Generally the best choice for IPSec ESP & IKE | ✅ Recommended      |
+| `aes192gcm16` (AES-GCM) | AEAD             | 192            | ✅ Strong      | Suitable for high-performance VPNs            | 👍 Acceptable       |
+| `aes128gcm16` (AES-GCM) | AEAD             | 128            | ✅ Strong      | Suitable for high-performance VPNs            | 👍 Acceptable       |
+| `aes256ccm16` (AES-CCM) | AEAD             | 256            | ✅ Strong      | Alternative to AES-GCM, but GCM is preferred  | 👍 Acceptable       |
+| `aes128ccm16` (AES-CCM) | AEAD             | 128            | ⚠️ Medium       | Alternative to AES-GCM, but GCM is preferred  | 👍 Acceptable       |
+| `chacha20poly1305`      | AEAD             | 256            | ✅ Strong      | Performance-sensitive (mobile, embedded), best choice for low-power devices | ✅ Recommended |
+| `aes256` (AES-CBC)      | non-AEAD         | 256            | ✅ Strong      | Suitable for legacy VPNs. Use only with HMAC (e.g. `sha256`)| ⚠️ Use with caution |
+| `aes192` (AES-CBC)      | non-AEAD         | 192            | ⚠️ Medium       | Rarely used, `aes256` is preferred.            | ⚠️ Use with caution |
+| `aes128` (AES-CBC)      | non-AEAD         | 128            | ⚠️ Medium       | Suitable for performance-sensitive VPNs, where constraints don't allow `aes256`                     | ⚠️ Use with caution |
+
+\* **A**uthenticated **E**ncryption with **A**ssociated **D**ata (**AEAD**) algorithms provide both encryption and authentication in a single step. They are more secure and efficient than non-AEAD algorithms, but are not supported by all legacy devices. We recommend that you always prefer AEAD algorithms (`aes256gcm16` or `chacha20poly1305`) for performance and security. Choosing an AEAD algorithm for IKEv2/ESP encryption means you do **not** need to define an algorithm for IKEv2/ESP integrity.
+
+## Integrity algorithms
+
+Integrity is based on **H**ash-based **M**essage **A**uthentication **C**ode (HMAC). The following algorithms are available:
+
+| Algorithm               | Output Size (bits)| Security Level   | Notes                                                   | Recommended?        |
+|-------------------------|--------------------|-----------------|---------------------------------------------------------|---------------------|
+| `sha512`                | 512                |  ✅ Very Strong | Suitable for high security environments. Use for long term security. | ✅ Recommended      |
+| `sha384`                | 384                |  ✅ Strong      | Balanced security/performance. Good alternative to `sha-512`.                        | ✅ Recommended      |
+| `sha256`                | 256                |  ✅ Strong      | Default for most VPNs. Recommended baseline.            | ✅ Recommended      |
+
+## Key exchange methods
+
+Key exchange is **D**iffie-**H**ellman-based. The following DH groups can be set to determine the strength and performance of the key exchange:
+
+| DH Group               | Bit Size  | Security Level  | Use Case                                                         | Recommended?     |
+|------------------------|-----------|-----------------|------------------------------------------------------------------|------------------|
+| `ecp521`               | 521       |  ✅ Very Strong | Suitable for high security environments. May be overkill (lowers performance). |👍 Acceptable     |
+| `ecp384`               | 384       |  ✅ Strong      | Both strong and fast. **Our top choice for modern VPNs.**        |✅ Recommended    |
+| `ecp256`               | 256       |  ✅ Strong      | Suitable for performance-sensitive VPNs.                                      |✅ Recommended    |
+| `curve25519` (X25519)  | 256       |  ✅ Very Strong | Both strong and fast. **Our top choice for performance**.        |✅ Recommended    |
+| `modp4096`             | 4096      |  ✅ Strong      | Strong but slow. May be suitable for legacy VPNs.                |👍 Acceptable     |
+| `modp3072`             | 3072      |  ✅ Medium-Strong | May be suitable for legacy VPNs.                               |👍 Acceptable     |
+| `modp2048`             | 2048      |  ⚠️ Minimum      | Use for older VPNs only if absolutely needed.                    |⚠️ Use with caution |
+
+## Standard recommendation
+
+For standard usage on modern equipment we recommend the following security proposal:
+
+| IKEv2 Encryption | IKEv2 Integrity | IKEv2 Key Exchange | ESP Encryption | ESP Integrity | ESP Key Exchange |
+|------------------|-----------------|--------------------|----------------|---------------|------------------|
+| `aes256gcm16`    | not required    | `curve25519`       | `aes256gcm16`  | not required  | not required     |
\ No newline at end of file
diff --git a/pages/site-to-site-vpn/reference-content/statuses.mdx b/pages/site-to-site-vpn/reference-content/statuses.mdx
new file mode 100644
index 0000000000..ee512537fa
--- /dev/null
+++ b/pages/site-to-site-vpn/reference-content/statuses.mdx
@@ -0,0 +1,50 @@
+---
+meta:
+  title: Understanding Site-to-Site VPN statuses
+  description: Find out what the different possible statuses of your Site-to-Site VPN gateways and connections mean, and how to take action based on these statuses when necessary.
+  noindex: true
+content:
+  h1: Understanding Site-to-Site VPN statuses
+  paragraph: Find out what the different possible statuses of your Site-to-Site VPN gateways and connections mean, and how to take action based on these statuses when necessary.
+  noindex: true
+tags: vpn gateway customer remote connection status
+categories: 
+  - site-to-site-vpn
+  - network
+dates:
+  validation: 2025-06-03
+  posted: 2025-06-03
+---
+
+<Message type="note">
+Site-to-Site VPN is currently in Private Beta, and available to selected testers only via the Scaleway API. [Request an invitation](https://www.scaleway.com/en/betas/#site-to-site-vpn).
+</Message>
+
+## VPN gateway statuses
+
+An VPN gateway always has a **status**, which can be retrieved via the API using the **Get a VPN gateway** call.
+
+This section explains the different statuses possible for a VPN gateway, and how to understand them.
+
+| **Status**             | **Description**                         | 
+|------------------------|-----------------------------------------|
+| **Provisioning**       | The **create** action has been triggered, and Scaleway is provisioning the gateway. This status should be momentary: if it persists, contact support. |
+| **Active**             | The VPN gateway has been created successfully, and is now operational. |
+| **Failed**             | Scaleway was unable to create the VPN gateway. Wait a few seconds and refresh to check the status does not change. If the problem persists, contact support. |
+| **Configuring**        | The gateway is configuring and is in a transient state. No user actions can be carried out. This status generally occurs while a new configuration is being applied, e.g. you have modified its settings. This status should be momentary: if it persists, contact support. |
+| **Locked**             | The gateway has been locked by the Trust and Safety team. You cannot carry out any actions on the gateway. Open a support ticket. |
+| **Deprovisioning**     |The **delete** action has been triggered, and Scaleway is deprovisioning the gateway. This status should be momentary: if it persists, contact support. |
+
+## Connection statuses
+
+A Site-to-Site VPN connection also always has a **status**, separate to that of the VPN gateway which can be retrieved via the API using the **Get a connection** call.
+
+This section explains the different statuses possible for a connection, and how to understand them.
+
+| **Status**             | **Description**                         | 
+|------------------------|-----------------------------------------|
+| **Ready**             | The connection has been created and is ready to connect. The tunnel(s) cannot be established because the customer gateway device is not yet successfully configured. |
+| **Active**             | The connection has been created, and all expected BGP session(s) between the two gateways are up. Traffic can flow through the connection's tunnel(s). |
+| **Limited connectivity**   | The connection has been created, but IP connectivity is limited. This may be the case if the connection has both an IPv4 and an IPv6 routing policy attached, but only one of the two associated BGP sessions is up.|
+| **Down**       | The connection has been created, but no BGP sessions (neither IPv4 not IPv6) are up, and without route announcements no traffic can flow through the tunnel.|
+| **Locked**             | The connection has been locked by the Trust and Safety team. You cannot carry out any actions on the connection. Open a support ticket. |
\ No newline at end of file
diff --git a/pages/site-to-site-vpn/reference-content/understanding-s2svpn.mdx b/pages/site-to-site-vpn/reference-content/understanding-s2svpn.mdx
new file mode 100644
index 0000000000..db1694e46b
--- /dev/null
+++ b/pages/site-to-site-vpn/reference-content/understanding-s2svpn.mdx
@@ -0,0 +1,181 @@
+---
+meta:
+  title: Understanding Site-to-Site VPN
+  description: Dive deeper into understanding Scaleway's Site-to-Site VPN offer, with technical diagrams, explanations and more.
+  noindex: true
+content:
+  h1: Understanding Site-to-Site VPN
+  paragraph: Dive deeper into understanding Scaleway's Site-to-Site VPN offer, with technical diagrams, explanations and more.
+  noindex: true
+tags: vpn gateway customer infrastructure connection encryption
+categories: 
+  - site-to-site-vpn
+  - network
+dates:
+  validation: 2025-06-03
+  posted: 2025-06-03
+---
+
+import image1 from './assets/scaleway-s2svpn-conceptual.webp'
+import image2 from './assets/scaleway-vpn-two-tunnels.webp'
+import image3 from './assets/scaleway-vpn-one-tunnel-both.webp'
+import image4 from './assets/scaleway-vpn-one-tunnel-one-type.webp'
+import image5 from './assets/scaleway-vpn-tunnel-detail.webp'
+
+
+<Message type="note">
+Site-to-Site VPN is currently in Private Beta, and available to selected testers only via the Scaleway API. [Request an invitation](https://www.scaleway.com/en/betas/#site-to-site-vpn).
+</Message>
+
+## Site-to-Site VPN overview
+
+Site-to-Site VPN lets you securely connect your Scaleway VPC to your remote infrastructure, enabling encrypted data exchange over a private VPN tunnel. Integrated with VPC routing, traffic destined for your remote infrastructure can reach it from your VPC via the secure VPN tunnel, and vice versa. Site-to-Site VPN connections are secured with Internet Protocol security ([IPsec](https://en.wikipedia.org/wiki/IPsec)).
+
+## Components of Site-to-Site VPN
+
+Scaleway Site-to-Site VPN consists of:
+
+- A **VPN gateway**: the connection point on the Scaleway side
+- A **customer gateway**: the connection point on the remote side (representing a corresponding physical customer gateway device)
+- A **routing policy**: defines the traffic allowed to flow through the tunnel
+- A **connection**: brings together the three above elements, and defines the configuration for the VPN tunnel(s)
+
+You must create all of the above elements, and correctly configure your customer gateway device, for a functional Site-to-Site VPN.
+
+<Lightbox image={image1} alt="A diagram shows the four elements described above, connected together" />
+
+### VPN gateway
+
+The VPN gateway provides a connection point on the Scaleway side of a Site-to-Site VPN tunnel. It has the following properties, which you can customize when you create the gateway:
+
+- **Region**: The geographical location in which the gateway is created. It must be in the same region as the other Site-to-Site VPN resources (customer gateways, routing policies, connections) that you want to use it with.
+- **Name** and (optionally) **tags**: A name and tags to identify the gateway.
+- **Gateway type**: Different gateway types are available for different prices. Pricing is based on **bandwidth**, and the **maximum number of connections** the gateway can be used for.
+- **Private Network**: Each gateway must be attached to a single Scaleway Private Network. The network chosen cannot be modified after creation of the gateway. The gateway will get both an IPv4 and IPv6 address on the Private Network. Other Private Networks in the VPC will be able to learn the route through the VPN gateway.
+- **Public IP address(es)**: The address(es) used to establish the VPN tunnel. Maximum of one IPv4 /32 and one IPv6 /128 address per gateway. Gateways with both types of IP will be able to support dual tunnels for a single connection, one IPv4 and one IPv6, providing increased redundancy.
+
+### Customer gateway
+
+The customer gateway provides a connection point on the customer (remote) side of a Site-to-Site VPN tunnel. It is the logical representation of a real **customer gateway device**, a physical or software-based networking device. 
+
+A customer gateway has the following properties, which you can customize when you create the gateway:
+
+- **Region**: The geographical location in which the gateway object is created. It must be in the same region as the other Site-to-Site VPN resources (VPN gateways, routing policies, connections) that you want to use it with.
+- **Name** and (optionally) **tags**: A name and tags to identify the gateway.
+
+The rest of the properties **must** correspond to the real properties of the corresponding real customer gateway device:
+
+- **Public IP address**: The address(es) used to establish the VPN tunnel. Maximum of one IPv4 and one IPv6 address per gateway. Gateways with both types of IP will be able to support dual tunnels for a single connection, one IPv4 and one IPv6, providing increased redundancy.
+- **Autonomous System Number (ASN)**: The unique identifier assigned to the customer's network, used by BGP (Border Gateway Protocol) to exchange routing information with other networks.
+
+<Message type="note">
+The ASN must be different to Scaleway's ASN (12876). This means you cannot use Site-to-Site VPN to create a VPN tunnel between two Scaleway VPCs (peering). Watch this space for our official VPC peering solution, planned for the future.
+</Message>
+
+### Routing policy
+
+By default, when you create a VPN connection, all routes across it are blocked. You must create and attach a routing policy for the connection, which sets filters for the IP prefixes to allow.
+
+A VPN connection must have a **minimum of one** and a **maximum of two** attached routing policies, one for each IP traffic type to be routed (IPv4 and/or IPv6).
+
+A routing policy has the following properties, which you can customize when you create the policy:
+
+- **Region**: The geographical location in which the routing policy is created. It must be in the same region as the other Site-to-Site VPN resources (VPN gateways, customer gateways, connections) that you want to use it with.
+- **Traffic type**: IPv4 or IPv6. If a VPN connection is to support both IPv4 and IPv6 traffic, it needs one routing policy per traffic type.
+- **Name** and (optionally) **tags**: A name and tags to identify the policy.
+
+You can whitelist multiple **outgoing routes** and multiple **incoming routes** per policy.
+
+- **Outgoing routes** are the IP prefixes that define ranges of Scaleway VPC route announcements to whitelist. Routes within these destinations will be propagated, allowing traffic from the remote gateway to be routed via the VPN to your VPC.
+- **Incoming routes** are the IP prefixes that define ranges of route announcements from the customer gateway to whitelist. Routes towards these destinations will be propagated, allowing traffic from the Scaleway VPC to be routed via the VPN to your remote infrastructure. 
+
+### Connection
+
+A connection represents the configuration of a secure link between a VPN gateway and a customer gateway. It defines all the characteristics of the Site-to-Site VPN tunnel(s), including routing policy and encryption method.
+
+A connection has the following properties, which you can customize when you create the policy:
+
+- **Region**: The geographical location in which the connection is created. It must be in the same region as the other Site-to-Site VPN resources (VPN gateways, customer gateways, routing policies) that it uses.
+- **Name** and (optionally) **tags**: A name and tags to identify the policy.
+- **VPN gateway**: The VPN gateway to use for the connection.
+- **Customer gateway**: The customer gateway to use for the connection. It must have at least one public IP type in common with the VPN gateway (IPv4 and/or IPv6).
+
+    Based on the gateways selected, the connection will establish either one or two VPN tunnels between them:
+      - IPv4 tunnel: If both gateways have a public IPv4 address
+      - IPv6 tunnel: If both gateways have a public IPv6 address
+      - IPv4 and IPv6 tunnels: If both gateways have a public IPv4 and a public IPv6 address.
+
+- **Routing policy(ies)**: For each traffic type (IPv4 and/or IPv6) to be routed over the connection, an associated routing policy must be attached (see [above](#routing-policy)).
+
+    <Message type="tip">
+    IPv6 traffic can travel through a tunnel established between two public IPv4 addresses, and vice versa. You can still attach an IPv4 and an IPv6 routing policy to your VPN connection to allow routing of both types of traffic, even if it only has one VPN tunnel established between one type of public IP. 
+    <br/><br/>
+    Having both types of public IP for both gateways types increases redundancy by providing two tunnels per connection, but it is not this in itself which determines the traffic types which can be routed.
+    <br/><br/>
+    The following diagram shows a connection with two tunnels, configured to route both types of IP traffic:
+    <Lightbox image={image2} alt="A diagram shows a VPN gateway and a customer gateway, with two tunnels between them. One is via the gateways' public IPv4 addresses, the other via their public IPv6 addresses. Both IPv4 and IPv6 traffic flow through both tunnels."/>
+
+    The following diagram shows a connection with only one tunnel (established via the gateways' public IPv4 addresses), configured to route both types of IP traffic:
+    <Lightbox image={image3} alt="A diagram shows a VPN gateway and a customer gateway, with one tunnel between them, established via their public IPv4 addresses. Both IPv4 and IPv6 traffic flow through the tunnel."/>
+
+    The following diagram shows a connection with only one tunnel (established via the gateways' public IPv6 addresses), which has been configured to only route IPv4 traffic:
+    <Lightbox image={image4} alt="A diagram shows a VPN gateway and a customer gateway, with one tunnel between them, established via their public IPv6 addresses. IPv4 traffic flows through the tunnel."/>
+    </Message>
+
+- **Connection initiation policy**: Which gateway should initiate the tunnel(s). This can be either the VPN gateway, or the customer gateway. The chosen gateway will be responsible for kicking off the secure exchange that sets up the IPsec tunnel(s).
+
+- **Security proposal**: Defines the encryption and authentication methods used to secure the VPN tunnel. For full details on available security proposals, see our [dedicated documentation](/site-to-site-vpn/reference-content/security-proposals/).
+
+- **Pre-shared key (PSK)**: Generated automatically when you create the connection object. It is securely stored in [Scaleway Secret Manager](/secret-manager/), and can be retrieved for the purposes of configuring your customer gateway device. For now, it is not possible to customize the PSK. You must use the auto-generated one.
+
+## Configuring your customer gateway device
+
+After creating your Site-to-Site VPN [connection](#connection), you are prompted to configure your customer gateway device.
+
+Your customer gateway device is a real physical or software-based networking device, located on the remote network you want to connect to your Scaleway VPC. The customer gateway that you create in Scaleway is a logical representation of this device.
+
+Scaleway cannot configure your device for you. In order to successfully complete the setup of your Site-to-Site VPN, you must configure the device yourself. You will need the following information, which is available from the API:
+
+- **Public IP address(es) of the VPN gateway**: The IPv4 address, IPv6 address, or both, that you configured when creating the VPN gateway.
+- **Scaleway ASN**: 12876
+- **Pre-shared key**: Auto-generated for you upon creation of the connection, and stored in Scaleway Secret Manager
+
+You also need to set up route announcements and filters on the customer side. For this, you will need the following information:
+
+- **BGP interconnection subnet(s)**: The private subnet used to provide private IP addresses for the VPN gateway and customer gateway over the tunnel(s). The gateways connect over this private subnet to establish a BGP session and exchange routing information. For connections that are configured to route both IPv4 and IPv6 traffic, one IPv4 and one IPv6 subnet will be provided. Subnet information can be accessed via the API.
+
+    <Lightbox image={image5} alt="A diagram shows a VPN gateway and a customer gateway, with one tunnel between them, established via their public IPv4 addresses. IPv4 and IPv6 traffic is routed through the tunnel. Two BGP sessions are established within the tunnel between the two gateways over private subnets: one IPv4 and one IPv6, whereby they exchange route announcements for each traffic type."/>
+
+- **Routing policy**: Take into account the routing policy(ies) you attached to the connection, when configuring routing policy on the customer gateway device.
+
+### BGP communities
+
+You can influence routing between the various Site-to-Site VPNs in a VPC, for traffic flowing from Scaleway to your external network, by using BGP communities.
+
+Refer to the BGP community documentation for [InterLink](/interlink/reference-content/bgp-communities/) for details - the same information applies for Site-to-Site VPN. Note that by default, InterLink takes priority over Site-to-Site VPN for equivalent routes. 
+
+## Activating route propagation
+
+The final step in allowing traffic to flow over your Site-to-Site VPN, is to activate route propagation. This enables all the allowed prefixes defined in the routing policy to be announced in the BGP session. Traffic cannot flow over the VPN when route propagation is not activated.
+
+Activate route propagation via the dedicated call in the API.
+
+## Monitoring connection status
+
+Once you have created your Site-to-Site VPN connection, and configured your customer gateway device, monitor the status of your connection. If your device is successfully configured, and the connection is working, the status should be **Active**.
+
+See our dedicated [status documentation](/site-to-site-vpn/reference-content/statuses/) for full information on different statuses for the VPN gateway and connection, and how to troubleshoot them.
+
+## VPC routing
+
+Routes to your Site-to-Site VPN gateway are automatically added to your VPC's [route table](/vpc/concepts/#route-table), and advertised to all Private Networks within the VPC. This allows all resources within your VPC to find the route through the VPN tunnel, to your remote infrastructure. 
+
+Use [Network ACLs](/vpc/reference-content/understanding-nacls/) if you want to limit the resources that route traffic through the VPN gateway.
+
+## Site-to-Site VPN limitations
+
+- Site-to-Site VPN is currently in Private Beta, and available to selected testers only via the [Scaleway API](https://www.scaleway.com/en/betas/#site-to-site-vpn)
+- You cannot use Site-to-Site VPN to connect two Scaleway VPCs
+- You cannot modify the Private Network that a VPN is connected to after creation
+- You must use the auto-generated pre-shared key (PSK) for a VPN connection: you cannot currently define your own PSK
+- We cannot currently provide a configuration file for customer gateway devices