SRX Address-Set Membership Check

Posted on by Clay Haynes in Uncategorized

One of the things I like to standardize in firewall configs is addresses and address-sets. I always recommend creating address-sets and binding address entries into the address-set. From there, we could reference the address-set inside the security policy configuration. This makes it easier to automate changes as we no longer have to hunt inside the security policies to add or remove entries.

Recently I had a situation where I needed to parse through several thousand lines of configuration in a SRX Firewall to determine if address book entries were bound to more than one address-set. In many environments it is very likely that an address book entry is bound to more than one address-set. When that happens there are often unintended consequences that affect traffic flow through the firewall. A host may fall victim to a blocking policy; or worse yet allow more permissive access to sensitive systems!

Since I needed a quick way to do this repeatedly I wrote a simple script in python to parse through a SRX configuration. Read on to see the script!

(more…)

Running the vMX on VMWare Fusion

Posted on by Clay Haynes in MX, Virtualization

Having hardware to test configuration changes, new deployments, or troubleshooting an issue is very useful, and it is often the best way to replicate how an idea will work in a real environment. That being said with the introduction of virtual platforms we now have an acceptable alternative to real hardware in many cases. There are sometimes instances where having access to a dedicated virtual lab is not possible nor practical. Being able to run virtual platforms on your local system is very useful for such cases.

While MacOS has the ability to run KVM-based appliances, sometimes it is just easier to use VMWare Fusion. With a little preparation anyone can run the Juniper’s Virtual MX (vMX) platform on VMWare Fusion. So without further ado, this guide will help you run the vMX on VMWare Fusion.

(more…)

…And We’re Back!

Posted on by Clay Haynes in Personal

After an insanely long hiatus it is finally time to bring this blog online, and start venturing into technology again. In addition to the pure technology posts, there may be some additional subjects that will be explored as well. Some very clearly-labeled opinion pieces will be added based on the author’s experiences. One or two technical posts will be coming up in the next few days.

(more…)

Through, Around or Over

Posted on by Clay Haynes in Personal

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

Posted on by Clay Haynes in Remote Access

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:

JSAM-config

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):

Loopback

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

CCProxy

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

Bookmark

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

Resource
LabSAAccess

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

Monitor

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!