Category Archives: srx

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:)