DvSum Site-to-Site VPN Setup

Purpose

This document provides setup instructions for securely connecting to DvSum SaaS services using Site-to-Site VPN (IPSec IKEv2), enabling fully private network access to:

• REST APIs (apis.dvsum.ai)
• WebSocket Services (socket-api.dvsum.ai)
• File Storage Service (s3-storage.dvsum.ai)

All traffic travels through an encrypted IPSec tunnel from your environment to the DvSum SaaS platform over private networking.

Scope.  This connection carries traffic from the DvSum Gateway running in your network to the DvSum service backend (APIs, WebSocket, file storage). Accessing the DvSum web application in a browser is separate and continues to use your normal internet access.

No certificate changes on your side.  DvSum service endpoints present publicly trusted TLS certificates. You do not need to install a DvSum private CA or make any trust-store changes.

Architecture

Key components

• Your environment — your network with VPN device/firewall and the DvSum gateway agent.
• IPSec tunnel — encrypted site-to-site VPN over the public internet (IKEv2 / AES-256).
• DvSum SaaS — production platform serving APIs, WebSocket, and file storage.

Service Architecture Details

DvSum exposes three services over the private connectivity path. All three are accessed over HTTPS port 443 and routed through the same IPSec tunnel.

Important.  All three domains resolve private IP addresses inside the DvSum network when accessed over the VPN tunnel. These private IPs are only reachable through the tunnel — they are not accessible from the public internet. DvSum will provide specific private IPs for each domain after the VPN connection is established.

Information DvSum Requires from You

To configure the VPN connection on the DvSum side, please provide the following to your DvSum representative before any setup begins.

1. VPN configuration

2. Network details

Why a static IP is recommended.  Your public IP is registered on the DvSum Customer Gateway, and a static IP keeps the tunnel stable. If your device only has a dynamic public IP, contact your DvSum solutions engineer — dynamic-IP customer gateways can be supported with additional configuration.

Information DvSum Provides to You

Once DvSum has registered your Customer Gateway and created the VPN connection, the following will be provided.

1. VPN configuration file

DvSum will provide a VPN configuration file generated by AWS for your specific connection. Below is the structure — actual values are specific to your connection.

IPSec Tunnel #2 — same structure as Tunnel 1, with different outside IPs and PSK.

2. IKE version requirement

3. Private IPs of DvSum service endpoints

After the VPN connection is established, DvSum provides private IP addresses for the three service endpoints. These must be configured in your DNS or hosts file, so the gateway agent resolves the DvSum domains to private IPs.

4. DNS resolver configuration

Required if you are using Approach B (internal DNS forwarding) to resolve DvSum domains automatically across your network.

Firewall and Network Requirements

The following ports and protocols must be permitted on your perimeter firewall for the VPN tunnel to establish and carry traffic.

Outbound rules (Customer machine → DvSum)

Note on data source access: the rules above are for VPN establishment and DNS toward DvSum. The gateway agent machine also needs outbound access to your internal data sources. If your firewall allows all outbound by default, no additional rules are needed; if restrictive, permit the agent machine to reach your data sources on the relevant ports.

Inbound rules (DvSum → Customer machine)

DvSum tunnel endpoint (VGW) public IPs.  The two VGW public IPs (one per tunnel) are in the VPN configuration file. DvSum always provisions two tunnels — allowing both IPs for redundancy. In NAT-T mode (most common) all tunnel data uses UDP 4500; ESP protocol 50 is only needed if NAT-T is disabled.

Step-by-Step Setup Instructions

Steps 1–2 are completed by DvSum. Steps 3 onward are completed by your network team.

Key parameters to configure on your device

DNS Configuration

Approach A — Linux /etc/hosts (single machine, simplest)

If the gateway agent runs on a single Linux machine, add the following to /etc/hosts. Replace the IPs with the actual values provided by DvSum.

# DvSum Service Endpoint Private IPs (example - actual IPs will differ)

<ip-provided-by-dvsum>   apis.dvsum.ai

<ip-provided-by-dvsum>   s3-storage.dvsum.ai

<ip-provided-by-dvsum>   socket-api.dvsum.ai

Approach B — Internal DNS forwarding (multiple machines, recommended for production)

Configure your internal DNS server to forward queries for *.dvsum.ai to the DvSum DNS Resolver IPs provided during setup. This automatically resolves the domains to private IPs for every machine in your network.

• Forwarding rule: DNS queries for *.dvsum.ai → forward to DvSum Resolver IPs
• The resolver returns the private IP of the corresponding service endpoint
• All machines benefit automatically — no per-machine configuration

Routing Configuration

Static routing mode

Destination prefix & overlap.  DvSum provides the exact destination prefix during onboarding, scoped to the smallest range that covers the three service endpoints (typically a /24) and confirmed not to overlap with your internal network. Use the prefix in your configuration file — do not assume a fixed range. Example only (your actual prefix will be in the config file): 10.x.x.0/24. DvSum configures a corresponding static route back to the network CIDR you provided.

BGP routing mode

If using BGP, configure a BGP session with the VGW inside IP addresses from the config file. Advertise your internal network CIDR; DvSum advertises the DvSum services prefix back to you dynamically.

Connectivity Testing

Run all tests from the machine running the DvSum gateway agent. The tunnel must be established and DNS configured first.

1. DNS verification

getent hosts apis.dvsum.ai
# Expected: a private IP (e.g. 10.x.x.x) - not a public address
getent hosts s3-storage.dvsum.ai
getent hosts socket-api.dvsum.ai

On Windows (PowerShell): Resolve-DnsName apis.dvsum.ai — IPAddress should be a private address.

2. TCP connectivity

nc -zv <apis-private-ip> 443      # Expected: succeeded!
nc -zv <s3-private-ip> 443        # Expected: succeeded!
nc -zv <socket-private-ip> 443    # Expected: succeeded!
On Windows: Test-NetConnection -ComputerName <private-ip> -Port 443 → TcpTestSucceeded : True

3. TLS certificate validation

openssl s_client -connect apis.dvsum.ai:443 -servername apis.dvsum.ai </dev/null 2>&1 | grep -E "subject|Verify return" 

# Expected: Verify return code: 0 (ok)
# Note: the certificate subject may be CN=*.dvsum.ai (wildcard) - this is correct.
#       Use "Verify return code: 0 (ok)" as the pass criterion, not the CN value.

4. HTTPS health checks

curl -s https://apis.dvsum.ai/health-check
# Expected: HTTP 200, body {"status":"OK"}

curl -s https://s3-storage.dvsum.ai/health-check     # Expected: {"status":"OK"}
curl -s https://socket-api.dvsum.ai/health-check     # Expected: {"status":"OK"}

5. WebSocket connectivity

wscat -c wss://socket-api.dvsum.ai/socket

# Expected: error: Unexpected server response: 403
# 403 = reached the server successfully (a valid session token is required for full auth)
# timeout / connection refused = network issue - check tunnel and DNS first

6. Full verification (Linux)

echo "=== DNS ===" && \
getent hosts apis.dvsum.ai && \
getent hosts s3-storage.dvsum.ai && \
getent hosts socket-api.dvsum.ai && \
echo "=== TCP ===" && \
nc -zv apis.dvsum.ai 443 && \
nc -zv s3-storage.dvsum.ai 443 && \
nc -zv socket-api.dvsum.ai 443 && \
echo "=== HEALTH ===" && \
curl -s https://apis.dvsum.ai/health-check && echo && \
curl -s https://s3-storage.dvsum.ai/health-check && echo && \
curl -s https://socket-api.dvsum.ai/health-check && echo && \
echo "=== ALL PASSED ==="

7. Expected results summary

Troubleshooting

Glossary