Site-to-site VPN vs internet-facing endpoints for DICOM

Engineering teams building medical imaging cloud platforms face a common challenge: how to ingest DICOM studies from hospital modalities and picture archiving systems over the public internet.

The classic approach relies on a site-to-site IPsec VPN tunnel between the hospital data center and your cloud environment. The modern alternative exposes an internet-facing DICOM endpoint authenticated with mutual TLS (mTLS). Both approaches encrypt traffic across the public internet. However, their operational overhead, setup timelines, and failure modes differ significantly.

How site-to-site IPsec VPNs work for DICOM

A site-to-site VPN creates an encrypted tunnel between a hospital’s network gateway and your cloud network (such as an AWS Virtual Private Gateway or Azure VPN Gateway). The underlying protocol suite is IPsec, defined in RFC 4301, using Internet Key Exchange version 2 (RFC 7296) for security associations and session keys.

Once the tunnel is active, the two networks route packets as if they were on the same local area network. Modalities like CT or MR scanners send C-STORE requests across the tunnel to your private IP address on default DICOM ports (port 104 or port 11112).

The operational reality of hospital VPN tunnels

While IPsec VPNs provide strong network-level isolation, they come with substantial operational costs:

1. Hospital IT coordination delays: Establishing an IPsec tunnel requires approval from hospital network security teams. Filling out network questionnaires, coordinating pre-shared keys, and scheduling maintenance windows typically takes 4 to 12 weeks per hospital.
2. Subnet IP conflicts: Hospitals frequently use overlapping private IP ranges (such as 10.0.0.0/16 or 192.168.1.0/24). Connecting several client sites to a single cloud VPC often requires complex bidirectional Network Address Translation (NAT) rules.
3. Tunnel fragility: IPsec tunnels can drop when Phase 1 or Phase 2 rekeying fails, when intermediate firewalls clear state tables, or when dead peer detection timeouts trigger. Modalities fail silently or queue images locally until the tunnel recovers.
4. Cloud gateway expenses: Cloud providers charge an hourly fee for every provisioned VPN connection (typically €25 to €35 per month per tunnel) plus data transfer charges. Maintaining dozens of individual tunnels creates fixed monthly costs before transferring any imaging data.

How internet-facing endpoints with mutual TLS work

An internet-facing DICOM endpoint accepts incoming TCP connections directly over the public internet, requiring mutual TLS encryption and authentication. Standard DICOM secure transport profiles, defined in RFC 9325 and referenced by DICOM PS3.15 and the IHE ATNA Profile, mandate mTLS for secure imaging communication.

In this architecture, your service assigns a unique public DNS hostname or IP address to your listener. The sending hospital device (a scanner, PACS router, or local workstation) connects directly to this endpoint over TLS on a dedicated secure port, such as registered port 2762 (dicom-tls).

Cryptographic device authentication

Rather than relying on IPsec network routing, security moves to the transport layer. Both the server and the client present X.509 digital certificates during the TLS handshake:

• Server verification: The hospital sender verifies your endpoint certificate against a trusted certificate authority (CA), preventing man-in-the-middle attacks.
• Client verification: Your endpoint verifies the sender’s client certificate against a trusted CA before allowing any DICOM association negotiation. Connections without a valid, registered client certificate terminate immediately during the TLS handshake.

This model is detailed in our guide on mutual TLS for DICOM connections. For a direct comparison between site-to-site IPsec tunnels and public endpoints, see site-to-site VPN vs internet-facing endpoints for DICOM.

Practical comparison: VPN vs internet-facing mTLS

The real trade-off: legacy modality compatibility

Internet-facing endpoints provide simpler scaling and faster setup, but they have one real limitation: legacy modality support.

Some older ultrasound machines or legacy radiography systems built in the 2000s do not support TLS in their native DICOM software stack. These systems only speak unencrypted C-STORE over raw TCP.

When dealing with such legacy hardware, you have two choices:

• Use a local TLS tunnel wrapper: Install a lightweight local bridge or appliance inside the hospital LAN (such as Stunnel or a small gateway service) that receives raw C-STORE locally and tunnels it outward over mTLS.
• Fall back to an IPsec VPN: If the hospital forbids installing local software wrappers and the scanner lacks TLS options, an IPsec VPN tunnel remains the only viable path.

For modern scanners, hospital PACS routers, and DICOM routers, native TLS support is standard. You can configure them with a client certificate to push directly to a public secure endpoint.

Architecture and downstream ingestion

Securing the inbound transport solves network access, but downstream cloud applications still need to process the incoming studies. Translating incoming DIMSE C-STORE streams into modern webhooks avoids running heavy DICOM stacks in your core microservices.

Many cloud platforms pair an internet-facing mTLS endpoint with a translation layer that posts studies directly to your HTTPS API as DICOMweb STOW-RS requests. This bridges the gap between hospital scanners and cloud services, as explored in our overview of receiving DICOM from a hospital over the internet.

Dicomly provides internet-facing mTLS endpoints as a managed service. Hospital modalities connect directly to provisioned endpoints, and Dicomly streams each received study to your HTTPS destination URL in real time.

Next steps

To learn how endpoints and client certificates map to sending facilities, see our concept guide on endpoints and certificates. If you want to connect a test sender and verify connectivity, follow our quickstart guide or request early access.