Once you set up and configure your VNS3 instance, add firewall rules to allow or reject packets. Add Layer 4 - 7 firewall rules to your cloud based application to get more control over your cloud deployments. Only you can control your VNS3 firewall rules.
Navigate to Connections > Firewalls to enter firewall rules.
VNS3 Firewall features are controlled using IPTables syntax. For more information see http://linux.die.net/man/8/iptables and look for the PARAMETERS section. Another useful guide is available here: http:// www.thegeekstuff.com/2011/06/iptables-rules-examples/
In addition to the standard security and firewall features of VNS3 you can create your own rules to restrict traffic to and through the VNS3 Controller. Write a specification for a packet to match, then specify what to do with the packet.These are “customer” rules and are applied as appropriate in the overall firewall rule structure on the VNS3 Controller.
The order of rules matter - rules are applied from top to bottom until the first match. If no match is found, the packet is allowed to continue on.
If your customer rules don't reject a packet, it will be allowed by default. However, this “default” is fairly restrictive. Traffic is allowed from “known” VLANS. Known VLANs are VLANS that are listed in IPSec tunnel rules, and the VNS3 virtual VLAN. Allowing traffic from other sources requires adding firewall rules to accept that traffic.
A warning about VNS3 firewalls:
The VNS3 firewall allows customers complete control of the INPUT, OUTPUT, FORWARDING, PREROUTING and POSTROUTING behavior of traffic as it first enters the VNS3 Controller and as it exits the VNS3 Controller.
The VNS3 internal firewall is still there to “protect” the internal mechanisms of VNS3, however, customer rules can be created that have undesirable effects. Essentially rules that ACCEPT or REJECT/DROP all traffic are likely to create a device that is un-reachable or one that is too permissive in accepting traffic.
Customer rules are evaluated and if there is not a match in the _CUST chains, then they flow through into the interior VNS3 chains which are quite restrictive. Accepting all traffic prevents most of the interior rules from being evaluated which might block unsafe traffic. Blocking all traffic prevents most of the interior rules from being evaluated which accept necessary traffic such as the API and WebUI management utilities. For example, blocking port 8000 from all traffic will make the VNS3 instance un-manageable.
Do not have rules of either of the following forms:
INPUT_CUST --dport 8000 -j REJECT
INPUT_CUST -j REJECT
INPUT_CUST -j ACCEPT
See the full VNS3 Admin guide for firewall instructions for NAT, netmapping, port forwarding, and how to copy traffic to a device : https://cohesive.net/dnld/Cohesive-Networks_VNS3-3.5-Administration.pdf
Watch the video for Firewall rules set up: https://youtu.be/rRrgaGt8BbU