VPN Connectivity to the Enterprise Gateway

Hillrom offers a variety of methods to communicate data into the Digital Health Platform. For customers who require a site-to-site VPN in order to transmit or receive data, the following process may be used to collect the appropriate information to create a successful VPN deployment.

1. Identify Network Address Translation (NAT) Pools

Inbound NAT (Customer → Hillrom)

Hillrom uses the 172.25.128.0/17 subnet to allocate NAT pools to customers. All customer connections into the Digital Health Platform (DHP) that come over a VPN will NAT to a portion of this IP address pool.

Note: In some cases, there may be configurations which do not support the Hillrom-provided NAT block. These must be reviewed on a case-by-case basis, so please reach out to your Hillrom representative to discuss.

In order to allocate an appropriately sized IP address block, Hillrom must know the number of server(s) that will VPN require connectivity into the Digital Health Platform. This may include test or sandbox server(s). Typically, this does not include clinical devices (such as beds, vitals devices).

Once the number of servers is identified, Hillrom will allocate a subnet to be used for NAT during the site-to-site VPN communication.

Outbound NAT (Hillrom → Customer)

Hillrom uses the following RFC1918 address space for its Digital Health Platform gateway servers:

172.27.192.0/24
172.27.195.0/24
172.27.208.0/24
172.27.211.0/24

If any of these subnets overlap with existing customer subnets, Hillrom can provide NAT mapping in the VPN tunnel to prevent IP address space conflicts. The customer must provide appropriate IP address(es) for the NAT mapping. Typically, only a few addresses are required.

2. Collect Information

Hillrom and the customer must jointly complete the Site to Site VPN Request form. In the Tunnel Information section, Hillrom’s preferred parameters are listed. However, Hillrom can support a variety of deployment parameters to ensure compatibility with a broad array of tunnels. The customer should select values which support its own internal security and configuration policies.

Note: The “preferred” parameters are the maximum hashing, encryption and Diffie-Hellman parameters that Hillrom can support in an IKEv1 tunnel. If different parameters are requested, an IKEv2 tunnel will be used.

3. Tunnel Deployment

Once all parameters and configurations have been agreed to, it is recommended that a working session of one hour be scheduled to deploy the VPN tunnel. During this time, the Hillrom engineer and the customer engineer can collaborate to deploy the tunnel in real-time, ensuring the best outcome with a minimum of wasted time.

It is recommended that a Pre-Shared Key be selected communicated in real-time during this meeting. Hillrom recommends a minimum of 24 randomly-generated letters and numbers.

On the Hillrom side, a configuration may look similar to the following:

object network springfield-hospital-vpn-subnet
 subnet 172.25.128.0 255.255.255.224
!
object network hillrom-prod-east-vm-subnet
 subnet 172.27.195.16 255.255.255.240
!
access-list cryptomap_springfield-hospital extended permit ip object hillrom-prod-east-vm-subnet object springfield-hospital-vpn-subnet 
!
crypto map outside_map 2 match address cryptomap_springfield-hospital 
crypto map outside_map 2 set pfs  
crypto map outside_map 2 set peer 8.8.8.8 
crypto map outside_map 2 set ikev1 transform-set ESP-AES-256-SHA 
! 
group-policy policy-8.8.8.8 internal 
group-policy policy-8.8.8.8 attributes 
 vpn-tunnel-protocol ikev1  
! 
tunnel-group 8.8.8.8 type ipsec-l2l 
tunnel-group 8.8.8.8 general-attributes 
 default-group-policy policy-8.8.8.8 
tunnel-group 8.8.8.8 ipsec-attributes 
 ikev1 pre-shared-key 9ShnUPML5TMDaMUv5rUCkj2Z24BHyNyf

Configurations will vary depending on the parameters selected.

4. Testing

VPN tunnels can be initiated from either end. Therefore, it is important to test connectivity that is initiated from both sides. In order to accomplish this, it is recommended that the engineers test (using ICMP, or TCP connections, or whatever method is deemed appropriate) from one side (e.g. a Hillrom server reaching a customer server), then reset the VPN tunnel and test the reverse direction (e.g. a customer server reaching a Hillrom server).