Category Archives: srx

migrating zone based address book to global in Juniper SRX

I have written a small script to convert SRX address books which are in zone base format to global. There was already a ready script on juniper forums but I saw they lack duplicate address checks and it couldn’t connect to some SRX devices. Below is the link to the code and how it can be used.

1) First fetch your current zone based addresses from SRX to a Linux host.

2) Download the tool at

3) Let’s say your zone based address book file is like this;

4) Run the tool against the legacy address book file as below.
Once you run you will get the new set based commands to be pasted into your SRX box.
If you have a conflict, you will get a message as below but how can a conflict happen?
It is because zone based address books allow you to choose the same address object name
if you blindly convert via another tool it can override your address book entry. In order to
prevent this, tool is simply telling you that address book object “addr1” has more than one
IP address. If both IP addresses are the same, you won’t get a warning.

Once you resolve the conflict i.e rename address book name and update security policies,
simply paste the set/del lines on your SRX command line. Then your address book should be converted.

SRX240 and SRX340 failure rates

Recently I upgraded dozens of SRX240H2 and SRX340 series Juniper firewalls and around %10 of SRX240H2 boxes either crashed during upgrade or after upgrade and none on 340 series. Although 340 is a newer platform, I would like to be positive and believe the fact that Juniper has improved both hardware and software quality. What do you think? What is your experience on newer platforms as far as hardware and software are concerned?

SRX standard and structured syslogging

SRX can send the logs in two formats standard and structured. If you haven’t made any extra config, what you see in the traffic logs is usually standard one. However structured one is easier to read and parse. Look, it is in the format field_name = field_value, so you can parse it or more friendly.

but you don’t get this by default. I have put a sample config which can help you log syslog in structured format.
Apparently sd-syslog isn’t sufficient alone but stream is also needed.

SRX Tips: Default application timeouts

It can be annoying if you are new to SRX and your SSH connection towards the firewall keeps timing out. You can of course activate keep alive on your SSH client or play with the default ssh timeout on SRX itself. First let’s see how we can check the current timeout.

Current SSH timeout is 1800 seconds. Let’s make it 7200 seconds.

We have increased the SSH timeout on the firewall. You must logout and login to see the changes though. Let’s check it!

Yes, timeout has increased to the new value we set.

SRX Tips: Static Host Mapping

After a year of being away from SRX, I have noticed that I forgot the CLI command to set a static hostname to IP mapping. If you haven’t used this feature so far, it simply allows you to have a /etc/hosts file similar to what we have in Linux and here is how we set and use it.

As you can see, we can resolve hostname “gw1” we just created.

Wonderful tool traceroute monitor

There is one traceroute option which you might not have noticed so far: It is the monitor. I use this option during packet drop issues from time to time to see if there is any hop on the path which might be causing some drop or latency. It is extremely handy and you can also modify your monitoring parameters. I believe this is a very useful troubleshooting option. The column names are also intuitive but you can take a look at the documentation here for this command if you like.

This command helped you in any troubleshooting, then drop here a comment!

According to Matt’s comment, both Linux and FreeBSD has this tool. For more info about the tool and its history check the wiki page. Tool was originally called Matt’s traceroute due to its first writer 🙂 On an ubuntu host, “apt-get install mtr” will bring you this handy tool in a few seconds!

SRX for beginners #2

After my srx for beginners post has become the most popular article of this blog, I have decided to improve it a little bit as it is missing some vital information. Without talking too much let’s summarize what we will do in this post

  • What is a flow session?
  • How can we interpret a flow session entry?
  • How can we open a standard port/application on SRX and do destination NAT?
  • How can we open a non-standard port and do destination NAT?
  • How can we do proxy-arp?

In this post, we will use the same topology like previous post but I have added three new devices in this new topology so that I can show source/destination nat and proxy arp.

SRX for beginners topology

SRX for beginners topology

Let’s get started:

Continue reading

Fragmented IP packet forwarding

I couldn’t really find a suitable topic for this post actually but I will try to find answers for the following questions:

  • How can we fragment an IP packet manually in scapy
  • How does a fragmented packet look like and how the transport layer (TCP/UDP) header is located
  • How do we forward fragmented packets, do we reassemle them?
  • If we don’t reassemble, can we force reassembly?

First of all a bit of a theory: if an incoming IP packet is to be forwarded to another next hop and the MTU of this new path is smaller than the packet to be transmitted, we must find a way to forward the packet. If the packet has DF (Don’t Fragment) bit on i.e we are instructed not to fragment the packet most probably by the source, then normally we are expected to send an ICMP packet with type “Fragmentation needed” and pray that on the way back to the source no devices block all ICMP type of traffic. Second scenario is that what if the source lets us fragment the packet. Then we need to fragment it and story from now on is about this part of the scenario and the topology we will use is something like below.

fragmented_packets Continue reading

Hostname config in Chassis cluster

This is a small post to inform followers of this blog about a common mistake done in SRX cluster configuration. This is something I really need to write. A cluster has two various configuration stanza

  • Node specific
  • Global

If you want to set something which is specific to only one node e.g node0 you configure it under groups level.

This command above means that “set the hostname only on node0 i.e not on both nodes” Here comes the mistake:

When you have a SRX Chassis cluster and you set the following host-name command under global config;

then this overrides your node specific configuration. This not only causes the same hostname SRX-FW to be displayed on the cli prompt of both devices but also syslog messages written to each box take the same name. Why is this so important?

It is important because it hinders the troubleshooting dramatically. So the bottom line is, if you have a chassis cluster, no host-name should be configured under global config. At least in my humble opinion:)