Site-to-Site VPN (private integrations)

Status

Available

Data flow

wawa → your integration targets, over the tunnel

Connectivity

AWS Site-to-Site VPN (IPsec), two tunnels for redundancy

Set up by

wawa builds its side; your IT team configures your firewall

A private integration gives wawa access to specific systems on your internal network (ultrasound servers, analysers, witnessing and time-lapse systems) over an encrypted IPsec tunnel between wawa's cloud and your firewall. wawa uses AWS Site-to-Site VPN, a standard service that works with virtually every enterprise firewall.

Why clinics use it

• Nothing is published to the internet. Your systems stay on your internal network; the connection is private and encrypted.
• No wawa software in your clinic. The tunnel ends at the edge of your network; we don't put agents or applications on your machines.
• One door per system. The tunnel reaches only the systems you agree to connect, not the rest of your network.

What we need from you

A named IT contact with authority over your firewall, available to work with us. Without that person the integration cannot be completed, so identify them at kick-off.

About your gateway (collected in a short screening form we send you):

Input	What to give us
Region	Which wawa region the tunnel should land in (normally your account's region)
Public gateway IP	The static public IP of your firewall's tunnel endpoint, or its NAT public IP
Gateway vendor, model and OS	So we can send vendor-specific configuration where available
Internal prefixes	The narrowest ranges hosting the target systems, ideally a /28 or /29 per system, not the whole LAN
Routing	BGP with your ASN (65000 if unsure), or static routes
IKE version	IKEv1 or IKEv2
Dual tunnels	Whether your gateway supports two tunnels
NAT	Whether your gateway performs NAT for this tunnel
Gateway type	Route-based or policy-based, and whether it supports policy-based traffic selectors
Technical contacts	Email addresses for tunnel notifications and tunnel-down alerts

About each integration target:

Input	What to give us
Private IP and port	The target's address within the prefixes you advertise on the tunnel
Protocol	We typically prefer HTTPS. If the target speaks another TCP- or UDP-based protocol, we can add support for it.
Root CA certificate	Only for HTTPS targets with self-signed or internal-CA certificates
Credentials	What the integration needs (see its guide), sent over a separate secure channel

How it works

1. You nominate your IT contact, and we send the screening form.
2. We build our side and send you the tunnel configuration file through a 1Password share with your named contact. The file contains the pre-shared keys, so treat it as a secret.
3. Your IT team configures your side using that file. The tunnel comes up, but no data flows yet.
4. We exchange credentials for each target over a separate secure channel.
5. We switch it on. wawa configures your account to use the connection and we verify an end-to-end transaction.

Every step except building our side depends on your IT team or firewall provider, so raise the VPN at kick-off: it is the most common reason an integration waits.

Things to know

• Address conflicts are solved with NAT, not renumbering. If your internal range overlaps one already in use on our side, we assign an address for you to NAT the system onto. We never ask you to renumber your network.
• Traffic is scoped. Our side of the tunnel routes only to the prefixes you declare, and our traffic comes from a single small dedicated subnet we give you. Allow only that subnet, to only the target hosts and ports.
• HTTPS is still preferred. IPsec encrypts traffic between wawa and your firewall, but the tunnel ends at your firewall, not at the server.
• Policy-based gateways need the traffic selectors. With the configuration file we send both sides' selectors as literal CIDRs. Don't configure the 169.254.x.x/30 inside-tunnel addresses as policy; they belong to the tunnel.
• Monitoring. We monitor both tunnels and alert your technical contact if they go down.