Category Archives: srx

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

SRX cluster ip-monitoring

In an SRX chassis cluster setup, in addition to interface monitoring you can also use
IP monitoring to monitor the health of your upstream path.


I have a simple topology to explain how ip monitoring works. In this setup node0 and node1
are part of an srx chassis cluster. reth0.0 interface is part of the redundancy group 1 (RG1)
Currently node0 is the primary for RG1 as you can see from the output below;

Now lets configure IP monitoring to detect any failure in network layer.

Continue reading

JNCIE-SEC: Traceoptions & IPSEC troubleshooting

In IPSEC topic, I am continuing with traceoptions and troubleshooting section. In this post, I will try to explain how I troubleshoot IPSEC VPNs mostly initial setup.

IPsec VPNs


  • Implementation of NAT
  • Source NAT
  • Destination NAT
  • Static NAT
  • Implementation of NAT with IPSec
  • Overlapping IPs between sites


One of the challenging parts of JNCIE-SEC must be the troubleshooting part for which I need to understand under what sort of problems what type of error logs are generated. Because of this, I enabled IKE traceoptions and simulated several type of possible problems and observed the error logs.

But first let’s see how a successful IKE Phase 1 and IKE Phase 2 log looks like;

PS: All errors below are between ike peers and


Phase 1

You can see the “IKE negotiation done” log in here.
Continue reading

MPLS/RSVP configuration & troubleshooting #3

This is the 3rd post of my MPLS/RSVP series. In the first and second, I set up an MPLS cloud with some sort of redundancy. In this post, I will enable traffic engineering support on OSPF in order to use CSPF and fast reroute feature. To explain fast reroute I need the topology again;


In a standard MPLS setup without fast reroute, if you have an LSP from J35 to J40 (Path: J34->J30->J29) and link between J30 and J29 breaks, it will take time for PATH error message to be received by J35 ingress router. However, if you enable fast reroute every router along the path will have alternate PATH available in case its link breaks and detours very quickly and will keep forwarding the traffic till the new LSP is established by the ingress router.
Please note that this is a temporary workaround to keep the traffic flowing without any disruption. Now it is time to get into the CLI to see how this works;

We must enable traffic engineering on OSPF and CSPF on MPLS. Otherwise fastreroute doesn’t work. This is what I have seen at least. In addition to this, my OSPF setup is multiarea for which I have to enable expand-loose-hop option in every MPLS router. According to the description from Juniper page “ it allows an LSP to traverse multiple OSPF areas within a service provider’s network.” Also according to juniper docs, if you configure an interarea LSP, you must set inter-domain option.
Continue reading