Cohesive Blog

As you’ll remember from networking foundations (4 things everyone should know about network layers), routers, switches, firewalls, and port filtering all happen between layers 4-7 of the OSI layer model.

Quick, here’s a short video on what devices work at each layer:

 

One thing we like to brag about with VNS3 is that it is a layer 4-7 networking device. What does that mean? How can that be? VNS3 is software, and acts as 6 devices in 1:

  • router,
  • switch,
  • SSL/IPSec VPN concentrator,
  • firewall,
  • protocol distributor,
  • scriptable network function virtualization

VNS3 cube 6devices in 1

VNS3 is a network appliance – or virtual, remember it’s software. With a software-based networking devices you can build those function on top of cloud-provider devices, like AWS security groups or Azure network security groups. Remember that defense in depth!

How does it work? What’s it made out of??

VNS3 builds on core VPN concepts but allows more customer control with an “overlay network.” An overlay network is a computer network built on top of another network. Nodes in an overlay can be virtual or logical links. VNS3 adds control over topologies, network addressing, encrypted communications, and network protocols.

Unlike other VPNs, VNS3 also acts like a virtual router, switch, firewall, VPN concentrator, protocol redistributor, and NFV container. VNS3 allows many, many networking use cases including:

  • application layer firewall with custom rules and hashings
  • connecting both NAT-T and Native IPsec endpoints on the same endpoint
  • Layer 2 Bridging over GRE as well as GRE tunneling over IPsec
  • customizable, flexible networks with Docker containerized network services
  • Trend Micro Deep Security central management agent

VNS3 Controllers are virtual machines (VMs) that act as a VPN gateway for the other virtual machines in the same cloud infrastructure. VNS3 synchronize between each other using RabbitMQ (a little thing we put together a while ago). VNS3 has a web-based UI and traditional Linux system command line interface (CLI). The VNS3 API uses a Ruby script and Ruby language binding. Everything else is a secret. Seriously, we’ve got a patent.

Put it all together: VNS3 devices

Posted by:

- - - -

In the same vein of recent technical blog posts, this week we’ll take a look at networking protocols.

Read up on:

You’ll remember from the OSI/TCP networking layer posts, protocols live at the Transport Layer (Layer 4 in OSI).In layer 3-4, the Network and Transport Layers, routers do packet filtering.

Routers direct packets to the “street address” on the packet header “envelope” to make sure it gets delivered to the correct location. The transport layer functions ensure messages are  received error free, in full, in order, and without duplicates.

Watch how common protocols can help you navigate cloud networks:

Tunneling protocols:

  • Layer 0-1 protocols including SSH, L2TP, GRE
  • Repackage traffic, can be used to hide data that runs through the tunnels
  • Can allow foreign protocols to run over a network that doesn’t support that particular protocol

Internet Protocol Security (IPsec):

  • Secures communications by authenticating and encrypting each IP packet
  • Establishes mutual authentication between agents by negotiating cryptographic keys for each session
  • Automatically secures data at the IP layer – only IPsec protects all application traffic over an IP network

Transport Control Protocol (TCP):

  • Creates a reliable, ordered, and error-checked packet delivery between hosts
  • Prioritizes accurate delivery rather than timely delivery

User Datagram Protocol (UDP):

  • Uses a connectionless transmission model for minimal message-oriented delivery
  • Does not use handshaking dialogues, so no guarantee of delivery, ordering, or duplicates
  • Ideal for time-sensitive / real-time apps where dropped packets are better than delays

Transport Layer Security (TLS) & Secure Sockets Layer (SSL):

  • Private connection guaranteed by secure, cryptographic keys
  • Authenticates the parties through public keys
  • Negotiates secure, stateful connections through “handshake” procedure
  • At application layer in the TCP/IP model or presentation layer in the OSI model

Secure Shell (SSH):

  • Operates secure network services over an unsecured network
  • Used to log in to remote machines to execute commands; tunneling; forwarding TCP ports; and secure file transfers (SFTP)
  • Used in cloud to provide secure paths over the Internet to a virtual machine (VM)

Border Gateway Protocol (BGP):

  • Designed to exchange routing and reachability information among autonomous systems (AS) on the Internet
  • Makes routing decisions based on paths, network policies, or rule-sets configured by a network administrator
  • Used most with ISPs and large internal private IP networks

Generic Routing Encapsulation (GRE)

  • GRE is a tunneling protocol that can encapsulate multiple network layer protocols inside a virtual point-to-point link. GRE is primarily used:
    • With PPTP to create VPNs
    • With IPsec VPNs to pass routing information between connected networks
    • In mobility or carrier protocols
Posted by:

- - - -

Part 2 of firewall rules with VNS3. Check out part 1 for all the overview parts.

Quick review:

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/

The order of rules matter.

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.

and, NATing:

Network address translator (NAT) can act as an intermediary agent on behalf of clients. The real originating IP address might be masked from the server receiving a request. A common practice is to have a NAT mask a large number of devices in a private network. Only the “outside” interface(s) of the NAT needs to have an Internet-routable address.

Firewall Rules – Network Address Translation (NAT-ing)

Most public clouds now provide VLAN isolation, a critical element of the defense in depth security approach. VLAN isolation also creates the need for additional capabilities beyond the basic compute and networking functions for application owners.

“NATing” allows the machines in a VLAN to use the VNS3 Controller as a gateway to services on the Internet, with all VLAN machines sharing the Controller’s public IP address.

NATing in public cloud uses the same behavior used in your home or office, where many devices can access the Internet via one shared public IP address.  When a VLAN device accesses the Internet, its return traffic is routed to it.

Basically, VNS3 lets you use your cloud VLAN just like you treat your home or office network, isolated from inbound requests for service, but allowing most outbound service requests.

Simple Syntax

MACRO_CUST -o eth0 -s 172.31.1.0/24 -j MASQUERADE

In this example your VNS3 Controller is in a VLAN subnet with a network from 172.31.1.0-172.31.1.255.   Many clouds with VLAN capabilities map a public IP to the private IP on eth0  via DNS.

Here we are telling the VNS3 Controller to “masquerade” for traffic coming from that subnet out to the Internet and then return the response packets to the requesting machine.

Firewall Rules – Port Forwarding

With AWS VPC, your can configure your cloud servers to not be visible and accessible from the Internet. AWS assigns a standard, automatically-assigned public IP , but we do not recommend relying on the automatic IP because you will not retain the same IP address if you shut down the instance. Rather, you should assign an Elastic IP to put the server on the Internet.

What if you want to be able to access one of the machines (for example like you might do on your home network) from the Internet? This is where port forwarding comes in.

A common use case would be using a Windows Remote Desktop on one of your cloud servers, as the “jump” box for then remoting to all the other cloud servers in your VPC.  VNS3 lets you do this with your VPC, just like you could for your home or office network, allowing specific traffic, from a specific source, on a specific port to be “forwarded” on to another machine.

Simple Syntax

MACRO_CUST -o eth0 -s 10.199.1.0/24 -j MASQUERADE

Using the same example network, assuming a source network public IP of 69.69.70.70 from which the RDP client is running, do the following:

  • NATing needs to be enabled for port forwarding to work
  • Specify the port to be forwarded, in this case “RDP” or 3389
  • Specify the source network address, here 69.69.70.70/32
  • Specify the machine for port 3389 traffic, here 10.199.1.130 using the “–to” syntax
  • Use the “-j DNAT” syntax to specify destination network address translation.

Firewall Rules – Netmapping

Netmapping allows you to create IPsec tunnels to imaginary IPs on the VNS3 side of the connection and use the VNS3 firewall to map all traffic to/from the imaginary IP, to the actual host on your cloud side.  This is extremely useful in situations where a connecting party has an address overlap with your Overlay or VLAN subnet.

Example

Remote subnet 10.10.10.0/24
Local Server the Remote wants to access: 172.31.10.50
Customer will not connect their LAN (10.10.10.0/24) to a private network Allocate an EIP to your account but DON’T associate: 23.23.23.23.
Build an IPsec the tunnel from 23.23.23.23/32 to 10.10.10.0/24

Simple Syntax:

PREROUTING_CUST -i eth0 -s 10.10.10.0/24 -d 23.23.23.23/32 -j NETMAP --to 172.31.10.50/32
POSTROUTING_CUST -o eth0 -s 172.31.10.50/32 -d 10.10.10.0/24 -j NETMAP --to 23.23.23.23/32

If the Local Subnet is a VLAN and not the Overlay Subnet add the following forward rule:
FORWARD_CUST -j ACCEPT

Copy Traffic to a Device

With the addition of the Docker-powered application container system there are scenarios where you might want to push a copy of the traffic from the eth0 or tun0 VNS3 interface to a particular IP.  The obvious use-case is copying traffic to the Cohesive Utilities Container where you can do things like run tcpdump or iftop.

Example:
I want to copy all tun0 (Overlay Network) traffic to my Network Utils Container running on the VNS3 Controller on the Docker network at 172.0.10.2.

Simple Syntax:
MACRO_CUST -j COPY —from tun0 —to 172.0.10.2 —bidirectional

SNMP Support

VNS3 now supports a number of industry standard MIBs for use from  monitoring system doing SNMP polling. We do not currently support any SNMP traps.

VNS3 SNMP support is enabled through the firewall. In the future we will provide API calls and user interface to provide more control of the SNMP experience.

To enable access to the SNMP information add the following rule to  firewall using a source address from your network (either your public IP, or an internal IP available to the Controller via IPsec or Clientpack). There is no SNMP authentication in this beta. An example rule would be INPUT_CUST -p udp -s 69.69.70.70/32 --dport snmp -j ACCEPT (where 69.69.70.70 is your network’s public IP address).

On your SNMP monitoring system:

  • Use SNMP v1c or v2
  • Community string of “vns3public”
  • The access to the SNMP information is “read only”

You should then be able to use a utility like “snmpwalk” to test:

snmpwalk -v 1 -c vns3public -O e <vns3_manager_public_ip>

Want to see something cool? Let’s add 10,000 firewall rules at once!

If you have trouble with the video player below, watch the video on YouTube:  https://youtu.be/N-c3GyGP6qk

Posted by:

- - - -

Blog Resources