Here is some guidance on simple configuration elements which all add up to make managing, migrating and upgrading VNS3 virtual networks easier.   (The general concepts apply across clouds...but the specific terms used are AWS-focused.


  • Use VPCs
  • Use EIPs on your VNS3 controllers
  • Enable VPC DNS Hostnames

    This will create a DNS name for the VNS3 instance based on the EIP, something like: ec2-54-7-149-170.compute-1.amazonaws.com
    Basically, when the EIP-based DNS name is referenced inside the VPC, it resolves to the private IP, when referenced outside the VPC, it resolves to the public IP.

    See this knowledgebase article: https://cohesivenet.zendesk.com/hc/en-us/articles/217515497-Should-I-use-the-Amazon-DNS-name-when-configuring-Clientpacks-or-Peering-


  • DO NOT EVER USE THE Private DNS Hostname (something like this: ip-172-31-14-241.eu-west-1.compute.internal) for VNS3 configuration.
  • DO NOT EVER USE the private IPs in clientpack configs (like 172.31.14.241).  This will require you to change clientpacks every time you migrate.
  • Use the Public DNS Host name in clientpack config remote lines.  When configuring for failover put the VNS3 instances DNS host names in the order you want a given cloud host to connect to the available VNS3 instances.

    Something like this:

    remote ec2-54-7-149-170.compute-1.amazonaws.com 1194
    remote ec2-72-17-150-111.compute-1.amazonaws.com 1194


  • Use the Public DNS host name of the VNS3 instances when peering VNS3 instances.
    If the peers are in the same VPC, they will connect to each other over the private ips, if they are in different VPCs they will peer with each other securely over the Internet via Public IPs.


  • In the security groups for two-manager topologies, open UDP 1195 between the VNS3 instances via the VPC subnet, or via their EIPs, depending on wether they are in the same VPC or not.  For larger than two-manager topology allow udp 1195:1204


  • In the security groups for the VNS3 instances, allow UDP 1194 from their VPC and/or from any location you deem necessary.  This is very specific to your company, customers, and deployments.


  • Install the VNS3 Routing Agent on your cloud hosts (included in your license )
    This allows the host to receive dynamic route updates as tunnels, peers, additional clientpacks are added to the topology.  This eliminates 99% of the openvpn agent stop/starts.


  • Use the VNS3:ms HA module (not in your license) to perform migrations for you.
    VNS3 HA module allows you to connect a backup instance to a running VNS3 instance.  It synchronizes their configuration and when synched you can then hit a "big red button" and it will migrate/fail over from the original primary to the backup.  This allows migrations to occur without everyone remembering all the steps, especially when under time pressure.


Cohesive is always happy to do a training/demo session for your team and go into more depth, and answer questions about these practices and how to apply them in Azure, Google, Softlayer, and other virtual infrastructures.