Security

I’m a big fan of Juniper Networks! I work mainly with the SSG (ScreenOS) and SRX (Junos) series. The Juniper SRX is a network security solution, which can be positioned in the data center or at the branch. You will surely agree, that virtualization and cloud computing changed a lot from the network perspective. This demands security solutions that are not bound to hardware boundaries. Juniper Firefly Perimeter addresses this demands.

What is Juniper Firefly Perimeter?

Juniper Firefly Perimeter is a SRX Service Gateway and it’s delivered in form of a virtual appliance. You can compare it with HP VSR1000 Virtual Service Router or Cisco Cloud Service Router 1000V. Firefly Perimeter is available for VMware vSphere 5.x and Linux KVM. Microsoft Hyper-V is currently not supported. When you take a look into the datasheet you will notice, that Firefly Perimeter can all the cool things, that you expect from this kind of a virtual appliance: From simple routing, routing protocols (RIP, OSP, BGP, IS-IS…), MPLS, VPN, stateful/ stateless firewall, Network attack detection, a lot of management feature and many more.

One possible use case for the HP VSR1000 is to build IPsec tunnels for secure data transfer. In this post I will show you how to configure a IPsec tunnel between two HP VSR1000. If you need a short introduction, feel free to take a look at this article.

The experimental setup

We have two server VMs (in this case Windows Server 2008 R2 with SP1) and two HP VSR1000 Virtual Service Router. To simplify I added a vSwitch without uplinks to my ESXi at home. This vSwitch has three port groups. While each VSR1000 is connected to only one site and the WAN port group, the server VMs are only connected to one site. The WAN port group should simulate the WAN link, but in reality WAN can be anything. This is a screenshot of the ESXi vSwitch and port group configuration, as well as the logical setup.

During a vSphere 5.0 > 5.5 upgrade I got this message:

The SSL certificate for this product is expired. See Knowledge Base article kb.vmware.com/kb/1009092

The customer hasn’t installed CA-signed certificats, so the expired certificates are the out-of-the-box self-signed certificates. The certificates are valid for two (VirtualCenter 2.5) respectively 10 years (since vCenter 4.x), depending on the Version. The only way to continue the installation is to renew the certificates. After renewing the certificates, you can simply continue the setup due the fact, that the vCenter service is stopped at this point of the setup and it loads the new certificates during startup. It’s the setup which checks the validity of the certificates. KB1009092 describes in great detail what to do, so I will not repeat what is already written there. You should note, that you can’t use the ESXi busybox to renew the certificates. The necessary OpenSSL binary isn’t included. The KB articles recommends OpenSSL for Windows. I simply used my Linux root server. But you can also use a small Linux VM. After renewing the certificates for vCenter, Inventory server and Web Client I simply continued the setup and it ran without problems by. The deployment of CA-signed certifcates is planned.