Cohesive Networks VNS3 Controllers use a small number of ports for administration and delivery of the VNS3 services. 

When planning the required ingress and egress rules for your VNS3 Controllers, please make sure you understand the distinctions between how stateful cloud firewall rules work (like AWS, Azure, or Google security groups) vs. stateless network ACLs like AWS Network ACLs.  The exact machinations of these are outside the scope of this article.

Also, be aware, that some cloud security groups have built in egress points that can't be blocked in the cloud fabric, although could be blocked using the VNS3 firewall.   For example, Amazon security groups and network ACLs don't filter traffic to or from link-local addresses ( or AWS reserved addresses (the first four IP addresses and the last one in each subnet). These addresses support the services: Domain Name Services (DNS), Dynamic Host Configuration Protocol (DHCP), Amazon EC2 instance metadata, Key Management Server (KMS—license management for Windows instances), and routing in the subnet. You can implement additional firewall solutions in your instances to block network communication with link-local addresses.

"Security Groups" provide a stateful firewall for traffic in and out of an instance like a VNS3 controller.  Security groups are stateful, meaning if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.

Here is a description of the ports used by a VNS3 Controller.  There is an important difference between ports used by VNS3 (such as for its Web User Interface or for peering to another controller) versus packets routed by VNS3.   In this case we are describing packets allowed to connect into, or coming out of VNS3, not packets being forwarded by VNS3 working as a router.

IPsec Connections

These ports need to be allowed inbound from your IPsec peer devices and outbound to your IPsec peer devices.  Inbound is needed for the peer to initiate to your VNS3, and outbound is required for VNS3 to initiate to the IPsec peer. 

    ISAKMP/Phase1 - UDP 500

    IPsec/Phase2 NAT-Traversal - UDP 4500

    IPsec/Phase2 Native - ESP Protocol 50

Overlay Network (if used)
VNS3 provides an optional encrypted overlay network using machine-to-machine VPN technology.  The default udp port for this needs to be allowed inbound to the VNS3 controller from devices using VNS3 as an encrypted router, stateful response traffic needs to be allowed. 

    VNS3 Tunneling Agent (openvpn) - UDP 1194

Peering (if peered controllers in your topology)
VNS3 controllers can be used to create a mesh overlay network to create an overlay network across vpcs/vnets, AZs, regions and clouds.  This peering requires outbound UDP ports from each of the controllers in the mesh, to all of the others.  It also requires port 8000 inbound from the other controllers. 

    Peering Transit Connections - UDP 1195-1204 depending on the number of peered controllers

    Inter-peer API Communication - TCP 8000 (inbound required, stateful outbound should be sufficient)


No outbound rule is required assuming you have DNS resolution enabled on your VPC (recommended) and are using the AWS default DNS server (VNS3 does by default via DHCP).  The AWS provided default DNS server is either link-local or AWS reserved addresses in your VPC CIDR.  You can specify a different DNS server via the DHCP options on the VPC.  If you do, you will need outbound UDP 53 and possibly TCP 53 depending on your DNS server configuration.  (If egress to external DNS is blocked as a general rule, Cohesive might need it enabled in order to do a remote support operation.)

    DNS - UDP 53 and TCP 53


VNS3 requires access to NTP services.  By default VNS3 points to the Ubuntu (provider of our base OS) time servers as well as (one of the most resilient consumer services available).  Recently Amazon has made time service available on the link-local VPC address  The ability to change this is currently via API only.  For example:  "curl -k -X PUT -u api:apidemopassword -d '{"ntp_hosts":""}' -H 'Content-Type: application/json'".  The argument "ntp_hosts" is a space delimited string of ntp host domain names or ipv4 addresses.

    NTP - UDP 123

Web User Interface/API
The traffic is response only, so no specific outbound rule is required.  

    Web UI/API - TCP 8000


To manage egress statefully for packets VNS3 forwards you use the FORWARD_CUST facility in the firewall.  

For example - image a set of web servers running in the logical subnet, and these web servers are connecting to a set of application servers in the logical subnet 

Here are some example rules to block or allow the access between the servers.
# No state transfer between web servers so no need to talk to each other.

# No app server clustering in this example so do not allow app servers to talk to each other.

# Allow web servers to initiate to app servers, and app servers to respond statefully.
FORWARD_CUST -i tun0 -s -d -m state --state NEW,ESTABLISHED -j ACCEPT
FORWARD_CUST -o tun0 -d -s -m state --state ESTABLISHED, RELATED -j ACCEPT

# Block all other traffic between subnets