Through, Around or Over

It’s been a while since I have posted in this blog, and to be honest this has been the strangest year of my life so far. While being mute on this blog isn’t helping my situation at all it feels like that this was the most appropriate thing to do. So while there are many cool things I want to talk about in the upcoming months I feel that it is appropriate to talk about non-technical things first.

For those of you that do not know I left my previous employer in March of 2015, and joined a company called Nexum which is based out of Chicago, Illinois. To add to the madness I have relocated to Cambridge, MA for a myriad of reasons. At both Nexum and Cambridge I have been exposed to a completely different world of technologies and opportunities that were not available to me at my previous job.

In 2015 I have become certified in F5, VMWare, Arbor Networks, and recently became a Pulse Secure Instructor as well. It has been an extremely liberating feeling to begin from square one and learn new concepts and ideas. Which brings me to my next update – more posts on this blog will be focusing on technologies that may not be Juniper-based. Most (if not all) the previous posts were based on stories in the field, and names/addresses were changed to protect the innocent. My current role has me focusing on topics that are not necessarily working on any CLI or any hardware, but this a lesson that needs to be learned anyways.

More things are coming in the next couple of months – primarily focusing on SDN and OpenStack – but it seemed like this was the best way to get that ball rolling. Switching jobs, locations, and technologies has had a significant impact in the past year, but it has allowed me to have the opportunity to find a way through, around, or over some of the obstacles that have held me back for too many years.

Good luck to you all in 2016 – and if there are things you want to see in here let me know!

Juniper Secure Access: Testing Web Rewrite via Proxy SA

I recently learned a new trick from JTAC to test rewriting issues through Content Intermediation Engine without affecting production traffic. This can be used to test new code releases, or change parameters (ACL, rewriting filters, cross-domain access, etc.) on a lab SA and still be able to provide full access to TAC for additional troubleshooting.

The basic idea is to set up a JSAM role on the production SA, and connect via a proxying server (I have had good luck with the program CCProxy – it’s free for up to three users). From there, point a test SA (the Demonstration and Training Edition SA is perfect for this!) to the proxying server via a web bookmark. Lastly, use a client PC to connect to the lab SA to perform your tests. A diagram of the layout is shown below:

sa proxy

So let’s begin!

On the Production SA, create a JSAM access resource that points to the web resource:


Connect to the customer’s SA and load JSAM, and take note of the localhost address being used (in the session manager window, click on Details to see the address):


From here, configure CCProxy to send traffic to that address (in this case, it’s by clicking on the Configuration Button:


In your test SA, create a resource to point to your proxy server instead of the main server:


From there, log in as a user on the Test SA, and try and access the resource:



Success! You can confirm the connection in the logs in CCProxy by clicking the Monitor button:


Feel free to make adjustments in the test SA to try out new resource policies, code versions or even set up a passthrough proxy. Hope this tip helps someone!

Junos Security is dead! Long live Junos Security!

I was hoping that title would catch your attention.

First and foremost this is a technical blog to discuss neat tricks and tips that I use daily, but sometime it’s a good idea to jump off the path and take a look at what is going on in the tech world. It is high time we start looking past traditional security firewalls or Next-Generation Firewalls and see where the path takes us.

For starters, I was recently at the Juniper Ambassador’s Conference and got to speak with the brilliant minds at Juniper Networks. I am quite sure everyone has heard about the significant changes that has been occurring at Juniper, and like many of you I had my concerns/reservations. While it is important to note is that there are still plenty of opportunities to improve the realm of Junos security in the short term I am excited for what is to come.

I feel that there is always going to be a need for traditional hardware firewalls in the network. Certain features make it extremely tough to remove hardware appliances completely; in particular I am talking about the edge firewalls that handle massive amounts of IPSEC tunnels or NATing public/private IP’s. In the future it would not be a long shot to put security functions in other parts of the network. As an example by moving firewall functions to the hypervisor then we can reduce the need of massive firewalls at the head end.

Let’s look at this idea for a moment. Consider the following traditional network:

traditional network

Typically you would have your network segments trunked to an interface on a firewall, or a unique interface per vlan directly connected to the firewall. This works great until you run out of interfaces, bandwidth, or processing power of the firewall – especially for that pesky intra-zone traffic!

Now consider adding security features to the hypervisor, such as a virtual firewall that connects its external interface to a flat vlan, and its internal interface to a specific vlan on the virtual switch. A diagram of such an idea is shown below:

new network

By offloading basic firewall or even IPS features to the hypervisor (which has far more compute power than that of a single hardware firewall) we can now free up the firewall to do more important tasks, and increase our scalability significantly! Combining this solution with some of the cool tools like Firefly Packer to help with automating these deployments you can have a significantly faster turnaround time for the needs of your network. This type of design also helps with reducing the failure domain of the network – if an issue crops up one of the hypervisor firewalls it only affects one group of devices, instead of causing an entire network outage. Smaller failure domains = higher overall stability.

Now certainly there are still a bunch of unanswered questions about designs like these, but this is the start of a significant change in how we all can view security and its application to the network. Sometimes it helps to take a step back from what features are missing in a device, and instead look at the opportunities that exist today and in the future.

Day One: Juniper Ambassadors’ Cookbook for 2014 is out!

Juniper just released the latest Juniper Ambassador cookbook today, and have included some articles that I have written over the past year. You can download it via the link below. My Recipes are Recipe #6, and Recipe #9:

There’s some fantastic resources in here about the SRX and MX, and interoperability with other vendors. I hope you all enjoy this book!

Quick Tip: TOS Ping in JUNOS

I recently ran into an issue with Class of Service on an SRX device where DSCP markings on traffic we not being seen on an upstream router when going through an SRX. After running packet captures showing the DSCP-marked traffic leaving the SRX the customer still wanted to proceed with troubleshooting the SRX as being at fault.

Because of this, I wanted to generate traffic with the DSCP markings directly from the SRX. In order to do this we can use a simple ping in order to generate a Type of Service (TOS) value. The command to do so is below:

ping tos <value> <host>

The <value> is where we set a TOS value, and <host> is the destination address we want to ping.

In the example below, we will use a TOS value of 46, and ping the host

ping tos 46

From here we can open a second CLI window and can monitor traffic coming in and out of the SRX.

root@SRX> monitor traffic interface ge-0/0/0.0 detail matching "host" no-resolve   
Address resolution is OFF.
Listening on ge-0/0/0.0, capture size 1514 bytes

14:09:15.098657 Out IP (tos 0x2e,ECT(0), ttl  64, id 57053, offset 0, flags [none], proto: ICMP (1), length: 84) > ICMP echo request, id 56818, seq 0, length 64
14:09:15.163678  In IP (tos 0x0, ttl  60, id 43312, offset 0, flags [none], proto: ICMP (1), length: 84) > ICMP echo reply, id 56818, seq 0, length 64

Note how the packets are tagged with the TOS 0x2e going out, but the ICMP replies are coming back with the DSCP marker stripped! In this case, an intermediary switch the SRX was connected to was not trusting the DSCP markings. After that issue was corrected here is what we saw instead:

root@SRX> monitor traffic interface ge-0/0/0.0 detail matching "host" no-resolve   
Address resolution is OFF.
Listening on ge-0/0/0.0, capture size 1514 bytes

14:09:15.098657 Out IP (tos 0x2e,ECT(0), ttl  64, id 57053, offset 0, flags [none], proto: ICMP (1), length: 84) > ICMP echo request, id 56818, seq 0, length 64
14:09:15.163678  In IP (tos 0x2e,ECT(0), ttl  60, id 43312, offset 0, flags [none], proto: ICMP (1), length: 84) > ICMP echo reply, id 56818, seq 0, length 64

I hope this neat little trick helps someone else out in the future!

SRX – Configuring a DHCP Server

It’s been a while since I wrote up a new post, so I thought I would come back with a nice post about the changes in configuring DHCP Servers on the SRX’s. Since Junos 12.x a new DHCP process came out to help fix some long standing issues with the existing feature. In this post I will discuss the old configuration, some of the problems I would regularly encounter, and the configuration of the new DHCP process.

Continue reading