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 (169.254.0.0/16) 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)
DNS
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 169.254.169.253 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
NTP
VNS3 requires access to NTP services. By default VNS3 points to the Ubuntu (provider of our base OS) time servers as well as time.apple.com (one of the most resilient consumer services available). Recently Amazon has made time service available on the link-local VPC address 169.254.169.123. The ability to change this is currently via API only. For example: "curl -k -X PUT -u api:apidemopassword -d '{"ntp_hosts":"169.254.169.123 time.apple.com"}' -H 'Content-Type: application/json' https://192.168.30.247:8000/api/config". 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
RELATED - USING VNS3 STATEFUL FIREWALL RULES
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 172.21.0.0/28, and these web servers are connecting to a set of application servers in the logical subnet 172.21.1.0/28
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.
FORWARD_CUST -s 172.21.0.0/28 -d 172.21.0.0/28 -j DROP
# No app server clustering in this example so do not allow app servers to talk to each other.
FORWARD_CUST -s 172.21.1.0/28 -d 172.21.1.0/28 -j DROP
# Allow web servers to initiate to app servers, and app servers to respond statefully.
FORWARD_CUST -i tun0 -s 172.21.0.0/28 -d 172.21.1.0/28 -m state --state NEW,ESTABLISHED -j ACCEPT
FORWARD_CUST -o tun0 -d 172.21.0.0/28 -s 172.21.1.0/28 -m state --state ESTABLISHED, RELATED -j ACCEPT
# Block all other traffic between subnets
FORWARD_CUST -s 172.21.0.0/22 -d 172.21.1.0/22 -j DROP