Category Archives: srx

Dual ISP failover with RPM ip-monitoring

Internet isn’t perfect and we may have link failures from time to time. How do we react to these failures? Manually or we have an automatic way. I would like to show on this post how Junos can take action upon an upstream gateway reachability issue and how SRX flow behaves in such a scenario. To achieve this task we will use a handful of features currently available on an SRX box. Before getting started, check my test topology below in order to understand this post. It is a simulated Internet environment with some fake public IP addresses. BranchC is our client side SRX device and we have two connected PCs and we will do every config magic on this BranchC device.


Test Plan

  • 1) Create two routing instances for each ISP & cross import the routes between these two instances
  • 2) Forward Debian1 traffic to ISP1 and HostC traffic to ISP2 by using Filter Based Forwarding
  • 3) Monitor each ISP by using RPM (Real Time Performance Monitoring) feature
  • 4) Test the ideal condition traffic flow
  • 5) If any ISP link fails, failover the default route to the other ISP by using ip monitoring feature
  • 6) Analyse the effects of this failover on established TCP/UDP traffic

Now we will go step by step and complete each task.

Continue reading

Address Books Explained

You can configure address book objects in various part of the configuration on SRX. Because we have several options, we need to know where we can use which address books. To explain address books simply, I have drawn the following graph.


Group A
This group contains the zone specific address book object and the configuration must be done under the security zone e.g

Continue reading

SRX AX411 Access Point Configuration

On SRX CLI, you can also manage AX411 Wireless Access Point. Configuration isn’t very difficult but if you don’t have prior experience it may look like a bit cumbersome. Below I will try to show how you can configure one of these access points if you ave just got one of these devices. This post only covers Layer 2 mode setup. First of all I assume you have a branch SRX which has POE capabilities. I think the smallest one is SRX210 for this task. In my lab, I am connecting AX411 device to ge-0/0/1 interface of my SRX220 device.


First I make sure only this interface is POE enabled i.e disabling others

We can see that only ge-0/0/1 is providing power after this config.

Continue reading

SRX Transparent Mode

SRX can also function as a firewall device when it is in layer 2 mode i.e
it can perform firewall functionality transparently.

As of now there are certain limitations on transparent mode. If not changed already;

  • You can either run the firewall in route mode or transparent mode but not mixed
  • NAT and IPSEC aren’t supported in this mode

Below I will try to show how you can convert an SRX firewall to transparent mode
and configure it. In our topology, we have two Linux servers each in the same VLAN
(282) and we will inspect traffic between these nodes without those Linux hosts are
being aware of SRX


Continue reading

flow trace without commit

On SRX, there is now a handy feature introduced in 12.1X46-D10. You can enable flow trace without going into configuration on the operational mode. I believe this will make troubleshooting easier as it saves time if you need to try different flow filters. Here is how you can enable a sample ICMP flow trace for a specific IP address e.g

Create your filters named incoming-filter,outgoing-filter to catch the traffic

Give a file name to save the flow trace

File will be saved under /var/log folder, you can also set size option if you like

Check the filters

Yes we have created the filters but they are not active as you can see on the Status field.
Continue reading

Which Junos release to upgrade?

Upgrades are unavoidable I believe but we can ask ourselves the following upgrade related questions;

  • when should we upgrade?
  • why should we upgrade?
  • to which release we should upgrade?
  • I can just share my experience about these questions. As I have said, upgrades are unavoidable. If it isn’t due to a feature related bug, it can be due to security fixes which are involved in future releases. If you are running a firewall, 3-4 years of uptime makes sense? Not sure about this. If you really want to keep your version as long as possible, one thing I can say is that check the EOL link and try to upgrade your firewall before it reaches End of Engineering. This is an important date!

    The other important question is to which release we should upgrade? My personal advice is that If you don’t have any special reason e.g you might have got advice from JTAC for a particular problem or you need a particular feature on a new release, read the JTAC recommended software versions KB and find your recommended release for your platform and upgrade to that release.

IP Monitoring

In this post, I will show an example of how you can monitor a certain gateway for a specific route and if the gateway isn’t responding to ICMP requests, you can fail over to another gateway device. ip_monitoring

Currently for we send our packets to GW2 ( What we would like to do is if this device can’t respond to ICMP requests, we will forward packets to the other gateway GW1 (

Continue reading

Source address selection in traceroute

Have you ever thought how the IP addresses are chosen/selected in icmp time exceeded error messages when you run a traceroute command? Recently I was analyzing an issue and this really made a difference in troubleshooting. I have done the analysis on an SRX firewall and a Linux device and I have got different results. I haven’t really prepared a setup for this but I will try to show this in a sample traceroute output.

This is just a snippet of my traceroute. is actually an SRX device and this IP address is tied to vlan.103 interface to which my packet (UDP traceroute) has entered. What if packet returned to me for example via vlan.104 interface. Would I still see the IP address in the output? Answer is yes according to my tests. What I have noticed is the following on an SRX box if there is asymmetric routing;

    • In flow mode SRX: device is sending icmp time exceeded message with source address of vlan.103 through the interface that the packet entered. Regardless of the routing error is sent via the incoming path
    • In packet mode SRX: device is sending icmp time exceeded message with the source address of vlan.103 through the vlan.104


As you can see even if the device can follow a different path to you, ICMP time exceeded error message is sourced from the incoming interface. This makes troubleshooting a bit difficult actually as you don’t really understand how the remote device is returning the traffic back to you unless you take packet capture.

What about Linux? Linux’s behaviour is also different. If we put Linux instead of SRX on this topology and packet enters via vlan.103 and return via vlan.104, Linux will send ICMP time exceeded packet through the vlan.104 interface with source address of vlan.104. This means if your UDP packet (traceroute) is forwarded through a Linux device and there is an asymmetric route, you can notice immediately if you know the interface IP assignments as traceroute will display a different IP address then you expect.

To be honest, I have searched several RFCs in order to find if there is any RFC requirement in ICMP time exceeded source address selection but couldn’t find anything. If you know anything, please leave a comment:)

Update: Later I have found the nanog traceroute presentation in which I have found the answer for this mystery.

Firefly Perimeter Cluster (VSRX) Setup on Vmware ESX

As you might know Firefly Perimeter aka VSRX which is the virtual firewall running on Vmware ESX and KVM can be downloaded as evaluation at here I believe it is great to test most functionality for example an SRX cluster (High Availability) which is the topic of this post. Here I will show

  • How you can install two firefly instances and operate them in a cluster.
  • How you can setup redundancy groups

Installation of Firefly instances
First download your evaluation copy. You must have a Juniper Networks account to download one. At the time of this writing, current version is 12.1X46-D10.2. Once you downloaded the OVA file to your disk, deploy it into your ESX server via File->Deploy OVF Template.

2014-02-16 14_37_09-Deploy OVF Template Give name e.g firefly00 for the first instance. Continue and you can choose whatever suggested in the wizard. Now you should have two firefly instances ready to be configured as below:

Continue reading


In this post I will try to show how I configured an SRX NAT device to forward PPTP connection.
Please read the entire post without applying any configuration as the first part of this post
does contain some mistakes:)


As you can see in the topology for this, I have used my SRX device (SRX100 12.1X44-D20.3)
in between an XP VPN client and a RRAS server on Windows2008. I must admit that it
was a pain to install/configure RRAS on 2008 server. After I disabled IPV6, everything
messed up and I had to remove/install interfaces again.

A PPTP connection requires two things;

1) TCP port 1723 for control path
2) GRE for data path

Continue reading