Blog

Categories for JNCIE-SEC

Unified Threat Management – deeper dive of traffic inspection

Published by
April 29, 2017

Unified Threat Management (or short UTM) belongs to the advanced security capabilities on all SRX devices (support for high-end devices is from 12.1X46 release). Following features are members of the UTM:

  • antispam (Local or with Spam Block server)
  • antivirus (Kaspersky also called Full, Sophos, Juniper Express)
  • web filtering (Juniper Enhanced, Local, Surf-Control Integrated, WebSense redirect)
  • content filtering

Please note the list above applies to Junos release 12.1X47. In older Junos releases some feature options (for example Juniper Enhanced web filtering) might not be available as they were introduced later.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Closer look at static NAT

Published by
December 17, 2016

Address translation is one of the main things keeping the IPv4 still alive. Nowadays it is considered as one of the basic router or firewall functionalities. On SRXs address translation is divided into three main types:

  • source NAT – the source address is translated in the initial flow
  • destination NAT – the destination address is translated in the initial flow
  • static NAT – combines source and destination NAT. The address translated in the initial flow depends on the flow direction (inbound flows have the destination address translated and outbound flows have the source address translated)

For source and destination NAT the port translation can be enabled or disabled through configuration. In static NAT the ports are not translated. Let’s look closer at the static NAT and its operation, configuration and troubleshooting.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Chassis cluster: Redundancy groups and interface monitoring

Published by
June 11, 2016

This post is focused on the interface monitoring functionality in redundancy groups.
Redundancy groups (RG) in SRX chassis cluster provide high-availability. They fail over from one node to the other in case of failure.  You can configure the cluster to monitor physical state of interfaces (interface monitoring) and/or check the reachability of IP addresses (IP monitoring).

Combining these options is quite flexible and allows you to define the desired circumstances that represent failure. For example: single interface physical failure, multiple interfaces physical failure, unreachable single IP address, unreachable multiple IP addresses, single interface physical failure and at the same time one IP address unreachable, etc.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

SRXs and policy based routing (aka FBF)

Published by
February 22, 2016

Devices typically use the packet’s destination IP address for routing (or forwarding) table lookup. Sometimes using the destination IP address is not sufficient because other aspects, such as the protocol and port numbers, need to be considered as well. For instance all traffic should has to be send out via the uplink connection except HTTP  that has to be directed to a transparent proxy. Another example can be directing traffic only from specific hosts to a deep inspection device for closer analysis while other traffic bypasses the inspection. The capability to consider other aspects and not just destination IP address in forwarding decisions is called policy based routing (PBR). Some vendors, however call it differently. On Junos devices the name is filter based forwarding (FBF), because it utilizes firewall filters.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Filter Based Forwarding & NAT

Published by
October 30, 2015

What do they do? Network address translation (NAT) modifies the IP addresses and optionally also ports in the packet. And filter based forwarding changes the forwarding table where the lookup is performed. Previous blogs did look at them separately. Now the question is what happens if they are used together, how do they coexist and what is their influence on each other?

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Firewall authentication

Published by
August 30, 2015

Typically traffic matching a security policy with permit action is allowed to pass. The SRX however provides option to perform additional tasks before the data is finally let through. Few examples of these additional tasks are:

  • making the decision based on the layer 7 application (AppFW)
  • searching for attacks located in the packet payload (IDP)
  • unified threat examination (antivirus, antispam, content and web filtering)
  • restricting who is allowed to use the policy (firewall authentication)
  • etc.

Here we will focus only on the firewall authentication.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Troubleshooting IPsec

Published by
February 20, 2015

IPsec protocol suite provides secure way for transferring data over the networks. Naturally correct configuration is necessary on the tunnel endpoints for the VPN to establish so the traffic can be transmitted. However not in every case the VPN comes up right away and troubleshooting is needed. This post provides few options and tips for troubleshooting IPsec on SRX devices.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Few things about screens

Published by
January 7, 2015

Screen functionality helps to protect the network against certain basic types of attacks and malicious traffic. As a bonus it can help to save precious system resources because it is evaluated in the very early stages of traffic processing sequence. Simply put when screens detect and block an attack the SRX does not have to perform the following and more intensive processing. Next, information and few tips about screens are presented that might be helpful when working with them.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Winner takes it all: BGP route selection in Junos OS

Published by
October 6, 2014

In networks that use BGP as part of their routing protocols it is very important to understand how the BGP route selection works. BGP is an important part of the JNCIE exams so this information is also very useful for candidates preparing for any of the practical exams.

BGP route selection can be broken down into discrete steps so it then becomes easy to understand how you can influence the route selection with the appropriate attributes. So lets have a look at the algorithm used in Junos OS in a somewhat simplified form. For all detailed steps I refer to http://www.juniper.net/techpubs/en_US/junos13.1/topics/reference/general/routing-ptotocols-address-representation.html

Before we can start the actual BGP route selection the router needs to  make sure that the route is valid, so it checks for Martian routes, AS loops and next-hop reach-ability. The actual route selection steps are:

View article

Troubleshooting SRX chassis cluster

Published by
June 26, 2014

SRX chassis cluster bundles two devices together to provide high-availability. The cluster nodes must be the same model, have the cards placed in the same slots and must run the same software version. In addition at least two interconnect links must be present (one control and one fabric link). In newer releases the SRX supports dual fabric (high-end and branch SRXs) and dual control links (high-end SRXs only). The ports used for fabric link are defined through configuration. The definition of the ports for the control link on the other hand is not so flexible. The high-end SRXs (1000 and 3000 series) have dedicated ports for that and the 5000 series uses the ports on the SPC cards. On the branch SRX devices revenue ports (fixed ones) are converted to control ports.

View article

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts