Why bother

Let’s be honest about how it got this bad: I didn’t keep up with it. I know. Servers don’t rot on their own — you stop patching them, stop upgrading them, and a few years later you’re staring at a stack that’s aged out from under you. The old droplet had quietly rotted underneath a site that still worked fine. Ubuntu 18.04 — EOL since 2023. PHP 7.4 — EOL since 2022, with no apt-upgrade path to anything newer (the PPA I’d have needed was frozen). MySQL 5.7 — also EOL. WordPress itself was current; everything under it wasn’t, and there was no clean patching path left, just a slow accumulation of risk on a box facing the public internet.

If you work with Juniper hardware and have never used the Juniper Port Checker, you are missing out on a really useful tool. It is part of the Juniper Pathfinder suite and it gives you a visual representation of the front panel of a device and lets you configure port speeds to validate that your planned configuration is actually supported by the hardware. No more digging through data sheets trying to figure out what happens to adjacent ports when you change a speed.

I have been meaning to put together some network tools for a while now, and I finally got around to it. I added a new Network Tools section to the site with eight tools that I find myself needing on a regular basis. They all run in the browser – nothing gets sent to a server, they either do the math locally or call a public API directly.

This post is intended to show you how to configure a Juniper SRX to be a DNS proxy for your network. This will allow you to forward DNS queries to both a private DNS server for your local domain and a public DNS server for all other requests.

Using the SRX as a DNS proxy has a few advantages for a network administrator. The first being that if you need to ever change an upstream DNS server pointer, you just need to update the SRX and not all the clients. The second is that if you want to split domain name DNS queries among different DNS servers, you can do that. This is good if you have a .local domain server locally or over a VPN. This will allow you to keep that query local, yet all other requests will go to a public DNS server.

The topology for this lab is as follows:

• The internal network in this topology is my Home network that is providing access to the Internet.
• The SRX is configured with DHCP on the UNTRUST side to obtain an IP from my home network.
• SRX is configured with a static IP of 192.168.100.1/24 on the TRUST side.
• SRX is acting as DHCP server for 192.168.100.0/24 and serving DNS server IP of 192.168.100.1.
• The SRX is NATing all traffic from TRUST to the UNTRUST interface.
• Linux host is a simple Ubuntu 16.04 desktop default in EVE-NG.

You can find a copy of the EVE-NG topology as well as the SRX start and final configs in my github repository: https://github.com/FryguyPA/Junos-SRX-DNS-Proxy

This is the fifth post in the Loading Configs series. In this post, we will cover the load set command. This allows you to enter commands into the buffer just like you would on the CLI. All these commands are either set or delete based commands. Yes, you can use this to delete as well.

Here is a quick refresher on what we are doing…

This is the fourth post in the Loading Configs series. In this post, we will cover the load update command. We touched on this in post one when we discussed override. This command, update, is less destructive as it will update the configuration, yet the Junos device will only evaluate the differences between the running and what you have staged.

Here is a quick refresher on what we are doing…

For this lab series, we will use a simple topology to demonstrate the different ways to load configs. We have our SRX configured with TRUST and UNTRUST zones, a connection to the Internet, and a Windows 7 PC that has a browser installed. We will focus on making changes to our security policies.

This is the third post in the Loading Configs series. In this post, we will cover the load replace command. This command shines when you want to replace parts of a configuration without having to delete a bunch of stuff. It is really powerful in security policies and firewall filters, places where you tend to want to replace a lot of configs quickly.

This is the second post in the Loading Configs series. In this post, we will cover the load patch command. The beauty of the load patch command is that you can load the config on one device, issue a show | compare, and take that output and patch another device. This is also useful when you want to test your commands for a change, roll it back, and then re-apply it later.

Here is a quick refresher on what we are doing…

For this lab series, we will use a simple topology to demonstrate the different ways to load configs. We have our SRX configured with TRUST and UNTRUST zones, a connection to the Internet, and a Windows 7 PC that has a browser installed. We will focus on making changes to our security policies.

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.