In this post series, we will cover one of the wonderful things with Junos, which is loading configurations to the devices. Compared to other vendors where you paste into a live configuration, Junus uses a candidate configuration for all changes. A great benefit of this is that there are a few ways to load configurations onto the devices.

The ways we can load the configurations are shown below.

  factory-default      Override existing configuration with factory default
  merge                Merge contents with existing configuration
  override             Override existing configuration
  patch                Load patch file into configuration
  replace              Replace configuration data
  set                  Execute set of commands on existing configuration
  update               Update existing configuration

I want to briefly touch on a few of the commands.

The first command, factory-default, is a way to soft reset the configuration back to the factory configuration without losing any of the locally stored data. The alternate way is factory default the configuration is to use the request system zeroize command. The zerioze command will rest the device back to the factory configuration and remove all locally stored user data (logs, files, etc).

The second command, override, will discard the current configuration and replace it with what you load into the device. When doing this the Junos device will re-evaluate the entire configuration you have entered. By re-evaluating the config, it will treat everything like it is new and you will have an impact to the device. If you want to just update the config and not re-evaluate everything, then you would use load update, which we will cover in post 4.

For this post, we will cover merge, patch, replace, update, and set.

I figured I would take a moment and recap theses past few posts and talk about the different methods now that we understand what they are. I also want to talk about some of the things to consider when choosing your approach.

Policy-Based with Security Policies

In our first post, we covered using security policies to establish and pass the traffic over the tunnel. There are a few challenges with this type of configuration is that you need to be keenly aware of.

You need to keep in mind that the order of security policies is critical. If you have a policy that permits or denies this traffic before the policy that says to tunnel the traffic, you will never send the traffic over the tunnel. Also, new security policies are always placed at the end of the current policies, so when you add a new VPN, you will need to remember to insert the new policy in the proper location.

This is the third and final post in the Policy-Based VPN series. In our first post, we configured a policy-based VPN using security policies tied to the UNTRUST interface. In our second post we used IPSec proxy-ids to define the tunneled traffic. This post will be covering the preferred method of Juniper policy-based VPNs, traffic-selectors.

The first part of this post is the setup of the labs, just like we did in the last post. If you want, you can skip down to where we delete the old configuration to see how the new configuration is done.

To recap, there are four different VPN configurations in this series:

• Uni-directional policy-based VPN (1st post)
• Bi-directional policy-based VPN (1st post)
• IPSEC proxy-identity route-based (2nd post).
• IPSEC Traffic selectors route-based (This post).

This is the second post in the Policy-Based VPN series. In our first post we configured a policy-based VPN using security policies tied to the UNTRUST interface. For this post, we will be using a route-based configuration that allows interoperability to the remote side configured as a policy-based VPN. This will also allow us to define a dedicated security zone for the VPN, hence helping to increase security. What we will be using in this post are proxy IDs to define local and remote networks.

The first part of this post is the setup of the labs, just like we did last time. If you want, you can skip down to where we delete the old configuration to see how the new configuration is done.

To recap, there are four different VPN configurations in this series:

• Uni-directional policy-based VPN (1st post)
• Bi-directional policy-based VPN (1st post)
• IPSEC proxy-identity route-based (Covered in this post)
• IPSEC Traffic selectors route-based (Coming soon)

Again, I will be using Juniper vLabs IPSEC VPN Policy-based lab for these posts. Feel free to head on over there and spin the lab up yourself when you are ready and kick the tires on these different configurations. Below is our diagram for the lab topology.

Policy-based VPNs are a pain most of the time, especially when compared to route-based VPNs. Many of the policy-based VPNs I run across today are legacy configurations dealing with ASA or interop between vendors where the one side only supported policy-based VPNs.

With Junos, there are four ways to configure VPNs to support policy-based VPN requirements. Two are a true policy-based VPN and the other two are actually route-based VPNs that support policy-based VPNs.

The four different VPN configuration options are:

• Uni-directional policy-based VPN (Covered in this post)
• Bi-directional policy-based VPN (Covered in this post at the end)
• IPSEC proxy-identity route-based (Coming soon)
• IPSEC Traffic selectors route-based (Coming soon)

There will be four posts in this series. The first post will cover the first two items listed above, the second will cover proxy-identity, the third will cover traffic-selectors, and the last post will be a wrap-up recap with pros and caveats to each option.

I will be using Juniper vLabs IPSEC VPN Policy-based lab for all these posts. We will only be working with one SRX to emulate what setting up a VPN would really be like. Feel free to head on over there and spin the lab up yourself when you are ready and kick the tires on these different configurations. Below is our diagram for the lab topology.

Pi-hole? Huh? DNS? What I am going on about now you may ask. Pi-hole is billed as a “Network-wide Ad Blocking,” a black hole for Internet Advertisements. While it is that, it can be much much more – I can also help you secure your network to some extent.

For me, I am using it to help filter out some advertisements, but also using it to block tracking websites, known malware sites, as well as tracking what my internal clients are talking to.

Want to know how effective a tool like Pi-hole can be, let’s look at the 24-hour stats for my home network below. Keep in mind that there are 5 of us here, I work from home, and we stream everything on Rokus.

A little over a year ago Juniper released Juniper vLabs. What vLabs is, is a place where you can safely lab and learn on Juniper virtualized hardware. When it was first launched there where about six labs available:

If you check out Juniper vLabs today, you will find 20 labs available across five different topic areas. With these labs, and I did test out a few, you do need to “reserve” them and you get them for about 3-hours. Everyone that I “reserved” was available immediately and ready to go in about 15 minutes. I did receive e-mails when I reserved when the lab was ready, and when I ended it.

This blog post was spurred on by a recent real-world experience where I had to configure a primary IP address on an ISP facing interface. In this scenario, we needed to maintain the corporate ARIN assigned IP on an interface for VPN traffic to originate from and terminate on. Yet the ISP would only allow the customer to use the ISP provided IP address for BGP peering.

Fair warning, this is a bit of a long one and has a twist and turn. Also, take note that I am using interface overload NAT only for demonstration purposes.

There was some discussion around the primary and preferred interface commands, so why not learn more about it and, in turn, write a blog post about it.

Below is the lab diagram we will use for this blog post. I have preconfigured the devices to pass traffic with vSRX2 set to NAT all internal traffic to its outside (ge-0/0/2) interface. vSRX1, vSRX3, and vSRX4 are all configured in packet mode to keep the configurations simple. You can find a copy of the eve-ng topology, starting configs, and ending configs at the end of this post.

I know we all have our cloudy day (some of us more than others) yet if you are a cloud expert now is your opportunity to prove it. Juniper has announced a new expert-level certification called JNCIE-Cloud.

Now if you are like me, you are probably like what the heck and why do we need this. Why do we need an expert level on cloud certification? Well when you start to consider the number of companies today that are moving to a hybrid cloud data center, it does make sense. The challenge that companies face to intelligently integrate the public and private clouds is staggering.

I have decided to do a little series on “What I run at home” with regards to networking, labs, and other assorted items that may be of interest. As a techie, it is always interesting to find what other techies run at home.

Well, I figured it was my time to share as I have been running the same network at home for a few years and have been pleased with the performance and management.