Skip to main content

VPN Integration

Directly exposing a SafeSquid proxy server hosted in the cloud to office or remote users is insecure and exposes critical infrastructure to external threats. Establishing a dedicated, encrypted WireGuard VPN tunnel enables secure transport of traffic from enterprise networks or remote endpoints to the cloud environment without public exposure. This configuration isolates the proxy server, limits attack surfaces, and enforces zero-trust connectivity using SafeSquid's application-layer inspection and access control mechanisms. THe following diagram depicts the working of VPN tunnel:

Prerequisites​

Cloud VPS (WireGuard + SafeSquid Host)

  • Ubuntu 24.04 LTS
  • Public IPv4 address (e.g., 203.0.113.10)
  • UDP port 51820 open in the cloud firewall
  • Root or sudo privileges
  • curl utility installed

Network Topology Overview​

ElementAddressDescription
Public IP203.0.113.10External IP of Cloud VPS
Private Subnet10.0.0.0/24Internal cloud network
WireGuard Server / SafeSquid Proxy IP10.0.0.100Internal IP of cloud VPS running WireGuard and SafeSquid
VPN Tunnel Subnet10.66.66.1/24IP pool for WireGuard interfaces

Setup Procedure​

1. Deploy WireGuard on Cloud VPS​

Download Setup Script​

Fetch the automated installation script provided by SafeSquid to simplify WireGuard server setup.

curl -O https://raw.githubusercontent.com/SafeSquid-Github/wireguard/refs/heads/main/wireguard-setup.sh

Execute Script​

Run the script to initiate the WireGuard server configuration.

bash wireguard-setup.sh --install

During execution, provide:

  • Public IP: 203.0.113.10
  • Port: 51820
  • VPN Subnet: 10.66.66.0/24
  • Peer Name: Client1

Outputs:

  • Server config: /etc/wireguard/wg0.conf
  • Client config: /etc/wireguard/wg0-client-client1.conf

2. Install WireGuard on the Office Endpoint​

Install WireGuard on the office client to enable VPN connectivity.

apt update
apt install wireguard -y

This provides the necessary tools: wg for tunnel management and wg-quick for service control.

3. Configure Office Endpoint​

Retrieve Client Configuration from Server​

Display the client configuration generated by the cloud-side script.

cat /etc/wireguard/wg0-client-client1.conf

Copy the output.

Save Configuration Locally​

Create the required directory and apply the configuration on the office client.

mkdir -p /etc/wireguard
vim /etc/wireguard/wg0.conf

Paste the copied output from the previous step and save the file.

4. Set Peer Routing Rules​

On Cloud VPS​

Modify the peer section in wg0.conf to allow routing to the office subnet and the client's tunnel IP.

AllowedIPs = 10.66.66.2/32,10.200.2.0/24

  • 10.66.66.2/32: IP assigned to Client1
  • 10.200.2.0/24: Entire office LAN behind Client1

On Office Client​

Ensure routing towards the server and internal cloud subnet.

AllowedIPs = 10.66.66.1/32,10.0.0.0/24

  • 10.66.66.1/32: Server tunnel endpoint
  • 10.0.0.0/24: Internal cloud LAN accessible via VPN

5. Restart and Enable Services​

Cloud VPS​

Restart the interface to apply changes and enable persistence at boot.

systemctl restart wg-quick@wg0
systemctl enable wg-quick@wg0

Office Client​

Restart the VPN tunnel with updated config and ensure service autostarts.

wg-quick down wg0 && wg-quick up wg0
systemctl enable wg-quick@wg0

6. Enable IP Forwarding​

Edit the system control file to enable IPv4 packet forwarding.

vim /etc/sysctl.conf

Uncomment or append:

net.ipv4.ip_forward = 1

Apply the new setting:

sysctl -p

7. Configure Routing​

Cloud VPS Route​

Route traffic destined for the office LAN via the WireGuard server's internal IP.

ip route add 10.200.2.0/24 via 10.0.0.100

This ensures cloud workloads can reach the office network securely via VPN.

Office Router Configuration​

Direct cloud-bound traffic from office LAN through Client1 (WireGuard client).

ip route add 10.0.0.0/24 via 10.200.2.100

Guarantees LAN devices access cloud services routed through the VPN tunnel.

8. Enforce One-Way Tunnel Security​

Block Unsolicited Traffic from Cloud to Office​

Insert a firewall rule to drop unsolicited packets targeting the office subnet from the tunnel.

iptables -A FORWARD -i wg0 -d 10.200.2.0/24 -j DROP

Persist Firewall Rules Across Reboots​

Install the persistence utility and save the current rule set.

apt install iptables-persistent -y
netfilter-persistent save

Validate VPN Connectivity​

Confirm tunnel and office endpoint reachability.

ping 10.66.66.2
ping 10.200.2.100

Post-Deployment Considerations​

1. Multi-Client Deployment (Office & Remote Users)​

If you plan to support remote employees, not just a single office, you must:

On the WireGuard Server:​

  • Generate separate peer configurations for each user or location.

  • Assign unique tunnel IPs to each client (e.g., 10.66.66.3/32, 10.66.66.4/32, etc.).

  • Use a separate AllowedIPs per peer.

Example server config for two clients:

[Peer]

Office LAN

PublicKey = OFFICE_PUBLIC_KEY

AllowedIPs = 10.66.66.2/32,10.200.2.0/24

[Peer]

Remote User1

PublicKey = REMOTE_USER1_KEY

AllowedIPs = 10.66.66.3/32

On the Remote User​

  • Use AllowedIPs = 0.0.0.0/0 if they want all their traffic routed through the VPN.
  • Or use 10.0.0.0/24 if they only need access to internal cloud resources.

2. Directory Server Integration​

SafeSquid requires directory services (e.g., Active Directory) for identity-based policy enforcement. Ensure:

  • Proxy initiates LDAP/LDAPS requests from its WireGuard tunnel IP
  • Directory server accepts and routes responses to VPN subnet (e.g., 10.66.66.1)

This guarantees seamless identity resolution and policy mapping inside the VPN-secured cloud perimeter.

3. Proxy Cluster with Centralized Load Balancer​

When deploying multiple SafeSquid instances as a cluster:

  • Place a central load balancer between the office VPN ingress and the proxy layer
  • The load balancer handles all incoming WireGuard traffic
  • Distributes requests to proxy nodes for inspection and filtering
  • Routes sanitized output to the internet

The architecture shown in maintains performance, simplifies scale-out, and centralizes VPN and external access controls.

4. Key Pair Management​

Each peer device must independently generate cryptographic keys:

wg genkey | tee privatekey | wg pubkey > publickey
  • Only the public key is shared with the server.
  • The private key is stored securely on the client system.
  • Key rotation is recommended for long-term deployments.
Feedback