Reflections on Juniper Training

If you follow my @networkjanitor twitter feed than you may know that I spent 3 days last week in training provided by Juniper and the local distributer Avnet.

In the old tradition of “free training for channel partners”, I signed up for “Junos Routing Essentials (JRE)” and “Junos for Security Platforms”. There was an “Introduction to Junos Software” course on the Monday that I sent one of my engineers along to, but I didnt attend personally. I have included below my review of the two courses.

Junos Routing Essentials (JRE)

This course was a one day course aimed at engineers who may or may not already understand the theory behind various routing protocols and processes.

There was a brief overview of how a routing table works and how the forwarding table is produced from this, which felt a little redundant at first, but led into further discussion about the various routing tables used within Junos and their functions. There were a few things I had not picked up working on Juniper kit that was handy here.

Quite a bit of this course was devoted to routing policy and how to import and export using Junos routing policies. This makes sense as once you understand the routing policy structures within Junos you open the doorway to some of the true power of the design inherent in Junos. There are quite a lot of match options available to routing policies that make life much easier (especially if you come from a Cisco background). I am working on a seperate blog post to discuss this topic further, as I feel there is a lot to point out.

The section on (stateless) firewall rules was interesting for me because I am used to working on SRX series routers which use zone based / statefull firewalls. To date the extent of my firewall policies was around rules on the loopback to control access to SSH/Telnet/SNMP etc.

Class of Service section was brief but gave an overview of how to build policies to control different CoS settings. You really would want some kind of previous exposure to QoS/CoS to supplement this module, but that really is the point of these condensed courses.

Junos For Security Platforms (SEC)

This course was a two day course focusing on the SRX series routers. Most of my Juniper experience has been on SRX240s, so I felt quite comfortable in this class. As always, I taught myself to do exactly what I needed to do to get the job done, so learning the ins and outs of how and why the platform works the way it does was insightful.

The opening module discusses the benefits and features of a converged router/firewall device and the superiority over traditional disparate devices. Mostly a lot of “my product is better”, but there is little dive into how the hardware traffic flows through the SRX platform. The module finishes up discussing the modular design of the Junos OS and further discussion of Flow based processing that is the foundation of the SRX platform (and shows its lineage from ScreenOS products).

The next two sections discussed the advantages of Zone based firewalling and how to build security policies to implement your goal. Discussion of the scheduling feature of policies to enforce time of day or day of week style firewall rules was an interesting design I had never really looked at, but has obvious uses within an enterprise type environment.

Firewall authentication, which is the ability to auth against the firewall to open up a particular set of firewall policies was interesting, and I have seen similar things when I used to use OpenBSD as a firewall, but I felt the uses were fairly restrictive and somewhat limited. If I really wanted something like this, the SRX is perfectly suited to operate as a VPN device and provide even greater functionality to boot.

Given the lineage from ScreenOS, the SRX platform has inherited a series of SCREEN features to filter broadstroke denial of service attempts as well as handling suspicious traffic. We discussed when to use SCREEN versus some of the optional IDP features or using firewall policies.

NAT on the SRX platform is somewhat different from both traditional Junos as well as from ScreenOS. The usual list of features are supported. Static 1:1 NAT, Destination Nat (port forwards etc), and Source Based Nat (both with and without PAT). Two interesting gotchas with the NAT implementation:

a) Security Policy is applied after NAT translations, so say you have a static 1:1 NAT arrangement, you would actually apply your zone based rules on the outside interface, but reference the internal address in the destination as opposed to the IP address used by the remote host. This makes sense after a while, but took some time to get my head around.

b) Like other firewalls, the SRX will happily snatch and translate any traffic routed through it according to any NAT rules that are configured. If on the otherhand you have say a large subnet on the “untrust” side of the firewall, and you try to make some NAT rules using some of those additional addresses, you will need to tell the router to Proxy ARP those addresses. I had been caught out on this one on a previous job, and felt a little foolish when they brought it up on the course. I wont be forgetting this one.

As one would expect from a modern firewall product, the SRX supports IPSec VPNs, which were covered quite well in the course. There are two types of IPSec VPNs – policy based and route based. Essentially policy based uses security policies to determine which traffic gets handled by IPSec. Anyone familiar with Cisco IPSec implementations should understand this concept. The other option is route based which configures a new interface on the router (st0.x) that is used as the tunnel between two VPN gateways. You can assign IP addresses to these interfaces and route traffic across it (Or use a dynamic routing protocol) just like any other interface type. It feels somewhat like a GRE tunnel in IOS, but with the added benefit of IPSec encryption and integrity checks.

A very brief look at the Intrusion Detection and Prevention features of the SRX was given, but this could have been a whole course on its own, not to mention this is a licensed feature of the SRX. A lot of interesting features, but not as powerful as a dedicated IPS/IDS solution. Worth considering for a branch deployment though, which is where this feature is aimed.

The last section covered an area of the SRX that I have spent some time on – High Availability. One of the great features of the SRX platform is that you can implement an Active/Active zone based firewall solution even on the smaller branch/appliance series of devices. I have implemented a HA pair of SRX240’s for a customer and have been quite happy with the result (though I suggest you lab this heavily before implementing due to instability issues on certain Junos versions).

In HA mode, you configure a set of redundancy groups and weightings for device failover triggers. There is a bit of fiddling to get some of these groups configured the way you expect them, but this is mostly due to the fact that both devices in the cluster have active data planes, and you need to know which interfaces (and on which device) traffic will ingress and egress.

HA on SRX Platforms could take another whole blog entry, which I am happy to go into if there is enough interest – so let me know if you want to hear more.

Final Thoughts?

So, after 3 days of training I walked away feeling that I had managed to learn quite a bit even though I have been working with Juniper equipment for 12 months now. The theory was aimed at engineers who already understood core concepts and routing protocol requirements, but even a junior engineer would learn a lot from these courses. There was a lot of hands-on lab exposure to teach you the ins and outs of the theory – it certainly made sure you learnt the material.

If you can get your account rep to organise the training (or have a company who will pay for it for you), then this is certainly worth spending some time on.

Hope this helps someone out there who is starting to look into Juniper as an alternative network vendor. Please let me know if you want me to follow up anything here, or would like me to show some further examples of the Juniper solutions.

Juniper