03-sw-appliances.tf

@@ -14,7 +14,7 @@ resource "stackit_network" "cloud_network01" {
 
 resource "stackit_network" "onprem_network01" {
   project_id       = stackit_resourcemanager_project.onprem.project_id
-  ipv4_prefix      = "11.2.2.0/24"
+  ipv4_prefix      = "192.168.1.0/24"
   name             = "network-02"
   ipv4_nameservers = ["9.9.9.9", "1.1.1.1"]
 }
@@ -28,7 +28,7 @@ resource "stackit_network_interface" "appliances" {
     }
     appliance02 = {
       network_id = stackit_network.onprem_network01.network_id
-      ipv4       = "11.2.2.10"
+      ipv4       = "192.168.1.10"
       project_id = stackit_resourcemanager_project.onprem.project_id
     }
   }
@@ -62,8 +62,8 @@ locals {
       local_subnet = "10.1.1.0/24"
     }
     appliance02 = {
-      local_ip     = "11.2.2.10"
+      local_ip     = "192.168.1.10"
-      local_subnet = "11.2.2.0/24"
+      local_subnet = "192.168.1.0/24"
     }
   }
 

04-vms.tf

@@ -1,7 +1,7 @@
 resource "stackit_network_area_route" "vpn" {
   organization_id = var.stackit_organization_id
   network_area_id = stackit_network_area.sna.network_area_id
-  prefix          = "11.2.2.0/24"
+  prefix          = "192.168.1.0/24"
   // network interface strongswan cloud appliance
   next_hop = "10.1.1.10"
 }

README.md

@@ -10,7 +10,7 @@ The tunnel uses IKEv2 with a Pre-Shared Key (PSK) and is automatically establish
 |-------------|------------|------------------------|
 | appliance01 | 10.1.1.10  | Cloud VPN Appliance    |
 | machine01   | 10.1.1.11  | Cloud Internal Machine |
-| appliance02 | 11.2.2.10  | On-Prem VPN Appliance  |
+| appliance02 | 192.168.1.10  | On-Prem VPN Appliance  |
 
 ---
 
@@ -41,10 +41,10 @@ Status of IKE charon daemon (strongSwan 5.9.8, Linux ...):
   uptime: ...
   worker threads: ...
 Connections:
-     net-net:  10.1.1.10...11.2.2.10  IKEv2, dpddelay=30s
+     net-net:  10.1.1.10...192.168.1.10  IKEv2, dpddelay=30s
      net-net:   local:  [10.1.1.10] uses pre-shared key authentication
-     net-net:   remote: [11.2.2.10] uses pre-shared key authentication
+     net-net:   remote: [192.168.1.10] uses pre-shared key authentication
-     net-net:   child:  10.1.1.0/24 === 11.2.2.0/24 TUNNEL
+     net-net:   child:  10.1.1.0/24 === 192.168.1.0/24 TUNNEL
 Security Associations (SAs) (0 up, 0 connecting):
   none
 ```
@@ -53,7 +53,7 @@ This output confirms the configuration is loaded, but the tunnel may not yet be
 
 ---
 
-## 2. Manually Bring Up the VPN Tunnel (Optional)
+## 2. Bring Up the VPN Tunnel
 
 If the tunnel didn’t start automatically, initiate it manually from either VPN appliance:
 
@@ -71,15 +71,15 @@ You should now see an established connection:
 
 ```
 Connections:
-     net-net[1]: ESTABLISHED 15s ago, 10.1.1.10...11.2.2.10
+     net-net[1]: ESTABLISHED 15s ago, 10.1.1.10...192.168.1.10
      net-net{1}:  INSTALLED, TUNNEL, ESP SPIs: ...
-     net-net{1}:  10.1.1.0/24 === 11.2.2.0/24
+     net-net{1}:  10.1.1.0/24 === 192.168.1.0/24
 ```
 
 Key indicators:
 
 - ESTABLISHED: Tunnel is active
-- Subnet-to-subnet routing: 10.1.1.0/24===11.2.2.0/24
+- Subnet-to-subnet routing: 10.1.1.0/24===192.168.1.0/24
 
 ---
 
@@ -90,7 +90,7 @@ Ping between hosts to validate that routing is working through the VPN tunnel:
 ### 💻 From appliance01 (cloud) to appliance02 (on-prem)
 
 ```bash
-ping 11.2.2.10
+ping 192.168.1.10
 # ✅ Successful ping confirms VPN tunnel works
 ```
 
@@ -104,7 +104,7 @@ ping 10.1.1.10
 ### 💻 From machine01 (cloud internal) to appliance02 (on-prem)
 
 ```bash
-ping 11.2.2.10
+ping 192.168.1.10
 # ✅ Tests routing through VPN appliance (appliance01)
 ```
 
@@ -117,11 +117,12 @@ ping 10.1.1.11
 
 ### ❌ From machine01 (cloud) to appliance02 (VPN-disconnected)
 
-If you remove the static route that directs 11.2.2.0/24 through appliance01:
+If you remove the static route that directs 192.168.1.0/24 through appliance01:
 
 ```bash
-ping 11.2.2.10
+ping 192.168.1.10
 # ❌ Should fail, indicating that VPN appliance is required for routing
 ```
 
-All success cases confirm correct tunnel and routing setup. Failures (when expected) validate routing dependency on the VPN stack.
+All success cases confirm correct tunnel and routing setup.
+Failures (when expected) validate routing dependency on the VPN stack.