Bridging Lab to the Cloud with Site-to-Site VPN

Pasted image 20260628123544.png

I. Project Summary

Collecting event logs in a centralized location is important for network visibility and incident response. However, as infrastructure expands to remote branches and into the cloud, transmitting traffic over the public internet introduces risks of interception from threat actors.

To address this, I established a site-to-site VPN using WireGuard to connect the Lab network directly to my AWS cloud environment. This encrypted tunnel will be used to transport logs and access the Wazuh SIEM without exposing the web management ports to the public internet. This builds on top of the previous entry where I turned an AntiX Linux host into a firewall and DNS sinkhole.

Pasted image 20260628125617.png

II. Key Engineering Decisions
1. Secure Remote Connections (WireGuard)
  • Established an encrypted communication tunnel between lab and remote infrastructures by implementing a site-to-site VPN using WireGuard. This adds an extra layer of protection when sending important data through the internet.
2. Unidirectional Telemetry for Simplified Routing
  • I enabled NAT on traffic from lab network going to AWS Gateway via the encrypted tunnel. AWS instances would only see the (AntiX) Lab Firewall 172.16.99.1 as source of all traffic. This simplifies routing but relies on the Lab Firewall to apply strict security policies.
3. Centralized Security Policy on Lab Firewall
  • Applied strict filtering on the lab firewall by specifying which hosts or networks have access to which remote servers and services. This filters the invalid traffic before it leaves the network which saves bandwidth and adds an extra layer of security.
4. Agent-Based and Agentless Telemetry Aggregation (Wazuh)
  • Deployed a security information and event management (SIEM) system that collects telemetry from various endpoints and devices. This provides better visibility on overall security posture, improves threat detection, and incident response.
III. Challenges
Challenges Probable Cause Fixes
Opening and viewing large config files hangs up the interactive SSH connection. Packet MTU is too large; ip addr on the AWS Gateway shows mtu 8921 for wg0 interface. Added MTU = 1420 on the wg0.conf to trim packets to 1420 bytes.
Firewall logs are reaching Wazuh Server but not displayed on the dashboard. Forwarded log's format does not match built-in rules/decoders. Enabled logall on ossec.conf so Wazuh archives all logs.
Packets not reaching the desired destination / not receiving responses. AWS SG/firewall blocks the traffic or missing routes. Utilized ping to check host connectivity. Used tcpdump on each hop to see if the packet was dropped before or after that hop. Checked routing tables with route command.
IV. Validation and Testing

According to the test summary below, the site-to-site VPN implementation was able to bridge the lab network to the remote AWS infrastructure. I also verified that while WireGuard places additional load on the legacy 32-bit CPU, it is not heavy enough to cause bandwidth drops and overheating.

Bandwidth & Load Test Summary:

Direction Send (Mbits/s) Receive (Mbits/s) CPU Load (Last 1min)
Lab to External 10.21 10.17 1.20
Lab to AWS 12.83 12.73 1.26

Network Access Test Summary:

Source Destination Port Accepted Is_expected
10.0.0.50 AWS Gateway 22 yes yes
10.0.0.50 Wazuh Server 22 yes yes
10.0.0.50 Wazuh Server 443 yes yes
10.0.0.50 AntiX Firewall 22 yes yes
10.0.0.100 AWS Gateway 22 no yes
10.0.0.100 Wazuh Server 22 no yes
10.0.0.100 Wazuh Server 443 no yes
10.0.0.100 AntiX Firewall 22 no yes
10.0.0.100 Wazuh Server 1514 yes yes
10.0.0.100 Wazuh Server 1515 yes yes
V. Lessons Learned
  • Fully routed site-to-site VPN implementations allow both sides to initiate connection with each other but it requires maintaining a lot of routing tables and firewall rules.
VI. Next Steps
  • Write custom Wazuh decoders and rules.
  • Reduce AntiX Firewall log noise.
References