vQFX 10k Testlab on ESX 6.0 / 6.5

Currently the vQFX is neither officially supported for ESX, neither for ESX 6.0 / 6.5.
My Goal is always to have the latest Versions in place – so all the Tutorials for ESX 5.5 are uninteresting for me.

Here are the steps to make the vQFX run on ESX 6.0 / 6.5:

1.) Download the vmdk images from Juniper (RE + PFE)

2.) Upload both files into your datastore

3.) Convert the vmdk images:
vmkfstools -i vqfx10k-re-15.1X53-D60.vmdk vqfx10kRE.vmdk -d thin
vmkfstools -i vqfx10k-pfe-20160609-2.vmdk vqfx10kPFE.vmdk -d thin

4.) Create a new V-Switch for inter-chassis-communication between pfe and re with Promiscious-mode enabled ant MTU of 9000 (Jumbo-Frames)

5.) Create the necessary VM’s:
vQFX-RE:
1 CPU – 2 Cores
5 GB RAM
OS: FreeBSD (64bit)
Adapter: BusLogic – ignore the “not recommended” Warning
Disk: vqfx10kRE.vmdk
Add at least 2 NIC’s:
1st NIC (E1000) – OOB-Management
2nd NIC (E1000) – inter-chassis-communication between PFE and RE
3rd to 10th NIC (E1000) – Data-Links

vQFX-PFE:
1 CPU – 1 Core
2 GB RAM
OS: FreeBSD (64bit)
Adapter: BusLogic – ignore the “not recommended” Warning
Disk: vqfx10kPFE.vmdk
1st NIC (E1000) – OOB-Management
2nd NIC (E1000) – inter-chassis-communication between PFE and RE

6.) Run both VMs

vQFX RE:
login : root
pwd : Juniper

Go to “cli” and configure em0 for OOB-Management.

 

7.) Enjoy – Repeat steps 1-5 for as many Switches as you want 🙂

 

Edit on 16.02.2017:

I want to thank Alexander Marhold for providing a Script that sets the correct mac-adresses to the corresponding interfaces.
http://forums.juniper.net/t5/Ethernet-Switching/vQFX10k-15-1X53-D60-on-ESXi-Installation-and-Running-with-up-to/td-p/303493

I have written a procedure for the vMX and adapted it for the vQFX which does this automatically on each commit

 

The script sets the correct mac address on any configured XE interface  ( taken from the corresponding em(+3) interface,.

  • the mac address is visible under current address in show interface
  • Only if there is a mac adress set in the configuration, that one will be overwritten with the correct one.
  • If the interface belongs to an ae-set, then there will be no mac adress set, as the mac-address is set by the ae
  • if the config contains an interface without a corresponding em-interface , it signals an error on commit

 

Installation on RE

 

> file copy  <location>/set-em-mac-to-xe-ae-vQFX.slax /var/db/scripts/commit/

 

>edit

# set system scripts commit allow-transients

# set system scripts commit file set-em-mac-to-xe-ae-vQFX.slax

#  commit

 

Hope that helps to  install vQFx10k on ESXi, I assume that the mac-seting is also needed on VMware Workstation but I have not tested it.

 

Another hint: there are a bunch of et,xe… interfaces with DHCP in the startup-factory-default, clear them all before starting with your configuration.

and yes independent of your ESXi physical interfaces the interfaces are 10gig XE interfaces.

Download: set-em-mac-to-xe-ae-vQFX.zip

IPsec Site-to-Site Tunnel between SRX100 and PfSense (Policy-Based VPN)

pfs-jsrx100-ipsec-pbvpn

Today (with the help of my friend and skillful netadmin Malte) we finally figured out how to bring up an IPsec Site-to-Site Policy-based VPN with multiple phase2-entries behind the PfSense and a single subnet behind the SRX100.

For this to work with a Policy-Based VPN (since PfSense can’t do route-based VPN) you need to create a policy for each combination of the subnets so that juniper can generate the correct proxy-id’s. If you miss one, you end up with an error like:

 

Here’s the config from the J-Point of view:

Took us some time to figure out why we still had some problems but in the end we found the culprit:

Seems to me, that PfSense and Juniper don’t play very nice when PFS is enabled.
After deleting the PFS-Group all 3 subnets went up and traffic was able to flow.

Hopefully this short article can save you some pain in the ass 😉

New Site – New Rules – New Cloud

As you may have noticed, this Website has just been migrated to Canada – wait – what????

I finally took the last Step to go “full Cloud” – so all my V-Servers are now Cloud based at OVH.

Therefore, this Site now is located in Canada – this might affect latency – however most of my followers will be happy, since they live in the US 😉

If you have any Questions on how I managed to get all my 33VM’s alone into the Cloud in 1 Night without disruption feel free to contact me.

 

In the next few Months my Posts will heavily increase, as my JNCIE-SEC Training has started – stay tuned 😉

SRX Security Policy at Group-Level – Careful what you wish for…

Just struggled with this one and thought that this might be helpful.

To log every denied packet on my SRX-100 (Living-Room and HomeOffice-Room) I use groups so I don’t accidentally forget to set the “log session-init” at the bottom of each zone.
But today I wondered why my Traffic that was passing from Zone1 to Zone2 didn’t show up in the logs – there was no configuration at all for this Zones and here’s the tricky part, that you find when searching extremely careful in the Juniper Docs:

This will only work if any Rule has been defined under the [security policies] section – if there is no Rule, the “Group-Rule” will not be created and therefore the traffic will not be visible.

If the above group is applied to the [security policies] hierarchy, it will not automatically populate the required policies; but will populate policies only for the zones that have security policies already configured. (http://kb.juniper.net/InfoCenter/index?page=content&id=KB25700&actp=search)

Today I’ve learned something new and this shows that you can never learn enough 😉

SRX Default Drop Log

      No Comments on SRX Default Drop Log

Have you ever wondered where the SRX stores the Logs for what it denied?
Back in my Checkpoint days we had this nice Dashboard which showed us the Packets that the Firewall denied so we could immediately check if our Rules applied successfully or not. Since the SRX can’t show this, here’s a nice little trick to show you all Packets being blocked by the Firewall. For this to work you would have to create a “log session-init” Deny-Rule for every zone as the “last” Rule (of course there still is implicit deny, but implicit deny does not log by default). When facing many Zones, this will be much too complex. It can be done simpler:

This adds a Group to every Zone. The Zone-Specific Rules apply first – so your Rule-set it safe, since it is more specific and as we all know JunOS always puts the more specific first. At the End the group policy will be inserted – right before your implicit deny (which is “invisible”).

If you are like me, you don’t want to look at the “messages” log, since it contains many more Events – not so good when looking at denied Packets. So create a new File to put only the “Deny”-Packets in it:

With “show log {name of logfile}” you can watch the Packets, that have been denied. Of course if your colleague is on the phone and you want him to press his connection-button so you can instantly monitor, whats happening you can issue the “monitor start {name of logfile}”. This will show all events “Live” on the CLI. Don’t forget to turn this off “monitor stop {name of logfile}”. You can however “rotate” the Files so they don’t steal your free Disk Space:

 

JUNOS 11.4R1 introduced “global security policies” – you can (and I prefer this) do it via another way:

But remember:
You have to use global address-books for this solution to apply – you cannot mix Zone-Specific address-books and global-address-books.
I always prefer the global address book since you don’t have to create Hosts 2-times when they are needed in different Zones – but that’s just my “taste”.

 

 

Juniper Summmit 2016 – The Disruptive Decade

I went to the Juniper Summit in Frankfurt, Germany on Wednesday the 13th of April. It was really interesting seeing so many Juniper Employees and Partners and of course also the great Minds who shared many good Sessions with the Crowd. Also Juniper took the 20years and we all received various gifts and a 20Years Sticker – way to go Juniper!

IMG_20160417_165546

The Juniper Power-Bank

IMG_3508