Virtual Private Network Tunnelling

In order for our systems to be able to reach out to, connect to and communicate with client systems on remote sites, AND for those systems to be able to connect back to our systems, a VPN needs to be established. 

This Virtual Private Network, secures traffic between GEN and the clients site ensuring that (a) it is encrypted in transit, and (b) there is no requirement to open any ports or make any unsafe firewall provisions. The tunnel effectively presents our resource at the clients network and visa-versa. 

Technical Requirements

The originator (the dial out) is flexible, but generally remote sites are the A end and dial out to GEN who are the B end. GEN Supports the following configurations as standard. 

Hashing

• HMAC-MD5 (not recommended)
• HMAC-SHA1

Ciphers

• DES (not recommended)
• 3DES (not recommended)
• AES (128, 192 and 256)

Groups

• G1 : Group1 (786 bit)
  G2 : Group2 (1024 bit)
  G5 : Group5 (1536 bit)
  G14 : Group14 (2048 bit)
  G19 : Group19 (256 bit Elliptic Curve)
  G20 : Group20 (384 bit Elliptic Curve)
  G21 : Group21 (521 bit Elliptic Curve)

Authentication

IKEv1 PSK with ESP (Encapsulated Security Payload) or AH (Authentication Header)

IKEv2 PSK with optional Local and Remote IDs and ESP

IKEv2 EAP with RSA and ESP with a Username & Password

NAT and MAP

We can NAT the VPN if there are IP address conflicts but we rarely find the need, and the NAT can be done at either end, or both. If NAT is required then a transport subnet might be required and this will need to be discussed and provisioned. 

Scope

At the GEN side, we restrict the reach of each tunnel to the services applicable for that tunnel. In most cases that means the oversight monitoring nodes, our logstash/greylog infrastructure, and the storage platforms, but this can also include hosted containers, virtualisations and other resources. 

At the client side, we recommend restricting the tunnel to the resources we are commissioned to monitor and/or manage. Any device we monitor will need to be able to reach our network, and we to reach that device (monitoring is almost always a two-way process - Events and telemetry are sent, and probes reach out to check operation). 

Example

A typical VPN Configuration would look something like this: 

Test

Once the tunnel has established, the infrastructure team will run some tests and ensure we can reach everything on the build, and those can reach us. Any problems and we'll work with you to resolve them. 

Assistance

In many cases we can assist in setting up your firewall/appliance(s) to establish a VPN correctly, and we're experienced with Fortinet, Draytek, Watchguard, Juniper, etc so simply raise a case at the HelpDesk or speak to your account manager.