Tag: SDN

Fortinet integration with Nuage Networks SDN

Fortinet integration with Nuage Networks SDN


Nuage Networks VSP, with the emphasis on P for Platform provides many integration points for 3rd party network and security providers (a.o.) this way the customer can leverage the SDN platform and build end-to-end automated services in support of his/her application needs.

One of the integration partners is Fortinet whereby we can integrate with the FortiGate Virtual Appliances to provide NGFW services and automated FW management via FortiManager.

Integration example

In the example setup below we are using OpenStack as the Cloud Management System and KVM as the OS Compute hosts.
We have the FortiGate Virtual Appliance connected to a management network (orange), a untrusted interface (red), and a trusted/internal interface (purple).
On the untrusted network we have a couple of virtual machines connected, and on the internal network


Dynamic group membership

Since we are working in cloud environment where new workloads are spun up and down at a regular pace resulting in a dynamic allocation of IP addresses, we need to make sure that we can keep the firewall policy intact. To do this we use dynamic group membership that adds and deletes the IP addresses of the virtual machines based on group membership on both platforms. The added benefit of this is that security policy does not go stale, when workloads are decommissioned in the cloud environment it’s address information is automatically removed from the security policies resulting in a more secure and stable environment overall.

Looking at the FortiGate below, we are using dynamic address groups to define source and destination policy rules. The membership of the address groups is synchronised between the Nuage VSP environment and Fortinet.

Screen Shot 2016-04-17 at 14.59.55

If we look at group membership in Fortinet we can see the virtual machines that are currently a member of the group. As you can see in the image below currently the group “PG1 – Address group 1 – Internal” has 1 virtual machine member.


If we now create a new virtual machine instance in OpenStack and make that instance a member of the corresponding Policy Group in Nuage Networks VSP it will be automatically synced back to Fortinet.

Screen Shot 2016-04-17 at 14.12.42

Looking at Nuage Networks VSP we can see the new OpenStack virtual machine is a member of the Policy Group “PG1 – Address Group 1 – Internal”


If we now go back to our FortiGate we can see the membership of the corresponding group has been updated.


Traffic Redirection

Now that we have dynamic address groups we can use these to create dynamic security policy, in order to selectively forward traffic from Nuage Networks VSP to FortiGate we need to create a Forward Policy in VSP.

In the picture below we define a new redirection target pointing to the FortiGate Virtual Appliance, in this case we opted for L3 service insertion, this could also be virtual wire based.


Now we need to define which traffic to classify as “interesting” and forward to FortiGate, because Nuage Networks VSP has a built-in distributed stateful L4 firewall we can create a security baseline that handles common east-west traffic locally and only forwards traffic that demands a higher level inspection to the FortiGate virtual appliance.


In the picture above we can select the Protocol, in this case I’m forwarding all traffic, but we could just as easily select for example TCP and define interesting traffic based on source and destination ports. We need to select the origin and destination network, in this case we use the dynamic address groups that are synced with Fortinet, this could also be based on more static network information. Finally we select the forward action and point to the Fortinet Virtual Appliance.

We have a couple of policies defined, as you could see in the picture at the top of the post we are allowing ICMP traffic between the untrusted network and the internal network. In the picture below I’ve logged on to one of the untrusted clients and am pinging the internal server.

Screen Shot 2016-04-17 at 15.38.57

Screen Shot 2016-04-17 at 15.40.29.png

Since this traffic mathes the ACL redirect rule we have configured in Nuage Networks VSP we can see a flow redirection at the Open vSwitch level pointing to the FortiGate virtual appliance.

Screen Shot 2016-04-17 at 15.40.17

We can also see that the Forward statics counters in VSP are increasing and furthermore determine that the traffic is logged for referential purposes.

Screen Shot 2016-04-17 at 15.41.24.png

If we look at FortiGate we can see that the traffic is indeed received and allowed by the virtual appliance.


Same quick test with SSH which is blocked by our ForiGate security policy.

Screen Shot 2016-04-17 at 15.53.06

Screen Shot 2016-04-17 at 15.52.40.png

So as you can see a very solid integration between the Nuage Networks datacenter SDN solution and Fortinet to secure dynamic cloud environments in an automated way.

Nuage Networks Service Insertion demos

Nuage Networks Service Insertion demos

During the OpenStack Summit in Tokyo, Nuage Networks announced 5 new partnerships (Fortinet, vArmour, Citrix, Guardicore, CounterTack). To give a quick overview of what these new (and some previous) partnerships represent from a technical point of view some demo movies were made available on YouTube.

Nuage Networks VSP and Citrix NetScaler VPX Demo In a Red Hat OpenStack environment

Nuage Networks VSP and F5 Big-IP Virtual Edition demo in a Red Hat OpenStack environment

Nuage Networks VSP and Palo Alto Networks Virtualized Firewall Demo in a Red Hat OpenStack environment

Nuage Networks VSP, and both Palo Alto Networks Virtualized Firewall and F5 Big-IP VE Demonstration

Nuage Networks VSP and Fortinet FortiGate Virtual Appliance Demo in a Red Hat OpenStack environment

Nuage Networks VSP and GuardiCore Data Center Security Suite Demo in a Red Hat OpenStack environment

Nuage Networks VSP and CounterTack Sentinel Demo in a Red Hat OpenStack environment

Burn the heretic!

Burn the heretic!

Talking about new ways to “fix” old problems or enabling functionalities that weren’t even possible before by introducing something that goes against established doctrine, can be an interesting experience.

The flip-side of the coin is that a lot of “new ways” are greatly oversold, of course a certain technology or product can’t fix ALL your problems, keep asking the tough questions.

But by keeping an open mind maybe you can see value that wasn’t there before, maybe by embracing change your world can become a whole lot more interesting, maybe you can become the automator instead of eventually becoming the automated.

“You can either be a victim of the world or an adventurer in search of treasure.”

-Paulo Coelho

But, but, if we would implement that we would loose x-y-z…

Back in the days of the mainframe (wait didn’t IBM just release the z13?, anyway…) you could do end to end performance tracing. You could issue an I/O and follow the transaction throughout the system (connect time, disconnect time, seek time, rotational delay,…), this worked because the mainframe was a single monolithic system, it had a single clock against which the I/O transaction could be measured and the protocol carrying the I/O cared about this metadata and allowed it to be traced. Today we have distributed systems, tracing something end to end is a whole lot trickier but that hasn’t stopped us from evolving because we saw the value and promise of the “new way”. What we have gained is much greater than what we have lost. Where you differentiate yourself has changed, the value you can get from IT has moved up the stack, we live in a world of abundance now, not a world of scarcities.

Screen Shot 2015-03-07 at 20.12.22

It’s all about the use case stupid!

I work for a vendor, and I evangelise a new way of looking at networking by doing network virtualisation/software defined networking (God I hate that I need to write both terms in order not to upset people, who cares what we call it, seriously). Obviously this stirs up a lot of controversy among “traditional” networking people, some of it warranted, some of it not. Just like it did when we first started talking about server virtualisation. In the end it comes down to the use case, every technology ever created was done with a specific set of use cases in mind. If those use cases make sense for your organisation, if they can move your business forward somehow maybe it is worth a (second) look.

I won’t spend time talking about my specific solutions’ use cases, that’s not what this blogpost is about.

A very interesting new way (at least in my humble opinion) of looking at things in a software defined world is this concept of machine learning. Systems that use data to make predictions or decisions rather than requiring explicit programming for instruction. What if the network can look at what is happening on the network, combine this with historical data (historical analytics) and make autonomous decisions about what is the best future configuration (maybe do things like redirect traffic by predicting congestion (using near real-time analytics), rearrange paths based on the workload’s requirements (using predictive analytics), etc.)

This kind of thinking requires a capable and unbound platform, something that can quickly adapt and incorporate new functionality. We now have big data platforms that can give us these insights using analytics, combine this with a programmable network and we have a potent solution for future networking.

Someone who is very active and vocal in this space is David Meyer, currently CTO for Service Providers and Chief Scientist at Brocade. I highly recommend checking out some of his recent talks, transcripts of which you can find on his webpage at http://www.1-4-5.net/~dmm/vita.html or have a look at the YouTube video below for his presentation during Network Field Day 8 where he talks about the concept of Software Defined Intelligence.

*Regarding the title, yes I am a warhammer 40k fanboy 😉