Secure proxy access with WireGuard VPN

Directly exposing a SafeSquid proxy in the cloud to office or remote users is insecure. A dedicated, encrypted WireGuard VPN tunnel enables secure transport from enterprise networks or remote endpoints to the cloud without public exposure. This isolates the proxy, limits attack surface, and supports zero-trust connectivity with SafeSquid inspection and access control. The following diagram depicts the VPN tunnel:

WireGuard VPN tunnel and SafeSquid proxy architecture

Prerequisites

Cloud VPS
Office LAN or Remote Endpoint

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

Example cloud and office network topology

Cloud Environment
Office Environment

Element	Address	Description
Public IP	203.0.113.10	External IP of Cloud VPS
Private Subnet	10.0.0.0/24	Internal cloud network
WireGuard Server / SafeSquid Proxy IP	10.0.0.100	Internal IP of cloud VPS running WireGuard and SafeSquid
VPN Tunnel Subnet	10.66.66.1/24	IP pool for WireGuard interfaces

Element	Address	Description
Office Subnet	10.200.2.0/24	Internal network of office LAN
WireGuard Client1 IP	10.200.2.100	Office client behind NAT, initiates VPN tunnel to cloud
VPN Tunnel Subnet	10.66.66.2/24	IP 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

Cloud VPS Ping Test
Office Client Ping Tests
Tunnel Status Inspection

Confirm tunnel and office endpoint reachability.

ping 10.66.66.2

ping 10.200.2.100

Ensure reverse reachability to server and cloud LAN.

ping 10.66.66.1

ping 10.0.0.100

Display active peers and session statistics.

wg show

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.

WireGuard load balancer and proxy layer architecture

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

Verification and Evidence

Interface Checks: Confirm WireGuard interface is up (wg show); SafeSquid listens on the expected ports and is reachable over the VPN tunnel from clients.
Log Analysis: VPN peer handshakes and traffic appear in system logs; SafeSquid access logs show requests from VPN client IPs when traffic is routed through the proxy.
Performance Validation: From a client connected via VPN, browse through SafeSquid; traffic is inspected and policies apply. Load balancer (if used) distributes connections correctly.

​Secure proxy access with WireGuard VPN

​Prerequisites

​Example cloud and office network topology

​Setup Procedure

​1. Deploy WireGuard on cloud VPS

​Download Setup Script

​Execute Script

​2. Install WireGuard on the office endpoint

​3. Configure office endpoint

​Retrieve Client Configuration from Server

​Save Configuration Locally

​4. Set peer routing rules

​On Cloud VPS

​On Office Client

​5. Restart and enable services

​Cloud VPS

​Office Client

​6. Enable IP Forwarding

​7. Configure Routing

​Cloud VPS Route

​Office Router Configuration

​8. Enforce One-Way Tunnel Security

​Block Unsolicited Traffic from Cloud to Office

​Persist Firewall Rules Across Reboots

​Validate VPN Connectivity

​Post-Deployment Considerations

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

​On the WireGuard Server:

​On the Remote User

​2. Directory Server Integration

​3. Proxy Cluster with Centralized Load Balancer

​4. Key Pair Management

​Verification and Evidence