Juniper's OpenStack Firewall Service plugin will enable perimeter firewall protection for OpenStack networks to configure security policies on Juniper’s SRX and vSRX devices.
OpenStack networks can be secured in two ways:
The security groups provide security between the east to west traffic or Intra VLAN traffic. Firewalls on the other hand add perimeter firewall protection to OpenStack networks and help in securing the North to South traffic such as Inter VLAN and Edge traffic.
Juniper's Firewall-as-a-Service (FWaaS) plugin builds on top of Juniper’s ML2 and L3 plugins. It enables Neutron to configure firewall rules and policies on SRX/vSRX devices. In OpenStack, one firewall can be created per tenant and can be assigned one security policy at a given point of time. A security policy is a collection of firewall rules. The below pictures illustrates this relationship:
Firewall Rule: Defines the source address & port(s), destination address & port(s), protocol and the action to be taken on the matching traffic.
Firewall Policy: is a collection of firewall rules.
Firewall: The construct representing a firewall device
The below picture will be used as a reference topology for this blog to explain the various concepts of FWaaS and how Juniper’s plugin configures the network at the various levels.
In this topology, the connection between Switches 1 & 2 to the aggregation switch and the connection between the aggregation switch and the SRX are trunk links preconfigured to carry all VLAN members.
Let’s take a scenario where an OpenStack tenant has a virtual network topology created as shown in the table below:
QFX 5100 Switch 1
QFX 5100 Switch 2
When the VMs are spawned on a network, the ML2 plugin will configure the corresponding VLANs on the trunk ports connecting the hypervisors to the switches 1 & 2.
The tenant can create a router next and add the gateways IP addresses from the networks Thirty and Forty to it. At this point, Juniper’s L3 plugin creates a routing instance (vRouter) on the SRX and generates IFLs on ge-0/0/10 of SRX for each VLAN and adds them to the router. For the initial version of FWaaS plugin implementation, the SRX acts as both a router as well as a firewall in the topology. The below picture captures the resulting OpenStack topology:
Once the router is created the tenant can create an OpenStack firewall and start adding security policy rules to it. This is the point at which Juniper’s FWaaS plugin steps in. Let’s take the case where the tenant wants to enable ICMP traffic from VM-30 à VM-40 but drop any other traffic.
Using OpenStack Horizon, first create a firewall rule which allows ICMP traffic from VM-30 to VM-40. Then create a firewall policy and assign the rule to it. Finally, create a firewall and assign the firewall policy to it.
Note: It is a good practice to set the default policy on the SRX to deny all traffic.
The following table captures the configuration that is done at each stage of the flow:
ML2 Plugin (VLAN Type driver)
QFX 5100 Switch #1
Assign VLAN 1000 to port ge-0/0/20 as a VLAN member
QFX 5100 Switch #2
Assign VLAN 1001 to port ge-0/0/30 as a VLAN member
L3 Service Plugin
Create a Routing Instance (RI)
Create IFLs corresponding to the two subnets and add them to the RI
Firewall Service Plugin (FWaaS)
Create a Zone for each router belonging to the tenant.
Add the gateway IFLS associated with each router to its corresponding Zone
Segregate the Firewall rules to their corresponding routers by evaluating their definition
Push the firewall rules on to their corresponding router zone
To see the sample config that got pushed to the SRX/vSRX device click here
Juniper’s FWaaS plugin brings the power of high performance, low latency and highly scalable data center security to the OpenStack virtual networks. It supports both physical and virtual form factors of SRX. Tenants can create and enable perimeter firewall protection for their OpenStack networks right from the OpenStack UI. In the initial release, OpenStack releases Icehouse, Juno and Kilo will be supported by the plugin.