SRX – Configuring a DHCP Server

It’s been a while since I wrote up a new post, so I thought I would come back with a nice post about the changes in configuring DHCP Servers on the SRX’s. Since Junos 12.x a new DHCP process came out to help fix some long standing issues with the existing feature. In this post I will discuss the old configuration, some of the problems I would regularly encounter, and the configuration of the new DHCP process.

Continue reading

Packet Mode and Selective Packet Services

Packet mode enables a SRX firewall to act strictly as a router, forwarding packets from a source to a destination without tracking sessions. This is useful for an engineer in certain situations such as high throughput applications that do not need full firewall functionality, or asymmetric traffic flows. We can also enable this mode on interesting traffic which is called Selective Packet Services. More details on Selective Packet Services is available on the following PDF as well as the rest of this post.

Enabling packet mode does change some of the behaviors of the SRX. For starters, it will bypass practically everything under the security stanza of the SRX. This means that the following features are disabled:

  • NAT
  • VPN Termination
  • Firewall Policies under the security stanza
  • IPS
  • UTM
  • Screens

Furthermore, when enabling packet mode for all traffic you will need to use stateless firewall filters to manage traffic which is located under the firewall stanza in the config.

On to business, shall we?

How to turn on Packet Mode for all traffic:

set security forwarding-options family mpls mode packet-based
commit and-quit
request system reboot

How to turn on Packet Mode for selective traffic:

  1. Set up a firewall filter to accept interesting traffic with an action of packet-mode
  2. Apply filter to interface that traffic is ingresses the firewall
  3. Set up 2nd firewall filter to accept return traffic with an action of packet-mode
  4. Apply 2nd filter to interface that return traffic ingresses the firewall

Below is a slightly fancier version of Selective Packet Services as it includes forwarding the traffic out of a forwarding instance:

interfaces {
    gr-0/0/0 {
        unit 0 {
            tunnel {
                source 1.1.1.1;  
                destination 2.2.2.2;
            }
            family inet {
                filter {
                    input redirect-return;
                }
                address 172.25.0.1/30;
            }
        }
    ge-0/0/1 {
        description "Trust Zone";
        unit 0 {
            family inet {
                filter {
                    input redirect-packet;
                }
                address 192.168.0.1/24;
            }
        }
    }
}

routing-options {
    interface-routes {
        rib-group inet global-rib;
    }
    rib-groups {
        global-rib {
            import-rib [ r1.inet.0 inet.0 ];
        }
    }
}

firewall {
    filter redirect-packet {
        term packet {
            from {
                destination-port [ http https ];
            }
            then {
                packet-mode;
                routing-instance r1;
            }
        }
        term allow-everything-else {
            then accept;
        }
    }
    filter redirect-return {
        term packet {
            from {
                source-port [ http https ];
            }
            then {
                packet-mode;
            }
        }
        term allow-everything-else {
            then accept;
        }
    }
}

routing-instances {
    r1 {
        instance-type forwarding;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop gr-0/0/0.0;
            }
        }
    }
}

Route-based VPN with Multiple Source/Destination Networks to a 3rd Party Device

I have seen this question several times on the Juniper Forums, so I decided to post a quick write up on how to build a route-based VPN to a 3rd party device, such as a Cisco ASA, with multiple subnets on each side. The answer is more straightforward than you think.

Take the example below, where the SRX has a network of 192.168.1.0/24, and needs to access 192.168.10.0/24 and 192.168.11.0/24 which is behind a Cisco ASA.

image

The Cisco Administrator specifies interesting traffic via an Access Control List to intercept traffic to be sent down the vpn tunnel. This ACL essentially creates what the SRX identifies as a proxy-id. By default the SRX will send the following proxy-id to any remote peer:

        proxy-identity {
            local 0.0.0.0/0;
            remote 0.0.0.0/0;
            service any;
        }

So, we will need to create multiple VPN’s with differing proxy-id’s that reference the same ike-gateway:

vpn abc1 {
    bind-interface st0.0;
    ike {
        gateway ike-vpn;
        proxy-identity {
            local 192.168.1.0/24;
            remote 192.168.10.0/24;
            service any;
        }
        ipsec-policy ipsec-policy;
    }
}

vpn abc2 {
    bind-interface st0.0;
    ike {
        gateway ike-vpn;
        proxy-identity {
            local 192.168.1.0/24;
            remote 192.168.11.0/24;
            service any;
        }
        ipsec-policy ipsec-policy;
    }
}

The tricky part is handling next-hop-tunnel bindings:

st0 {
  unit 0 {
   multipoint;
   family inet {
     next-hop-tunnel 172.31.255.2 ipsec-vpn abc1;
     next-hop-tunnel 172.31.255.3 ipsec-vpn abc2;
     address 172.31.255.1/24;
   }
  }
}

The st0.0 address must use a subnet for its local address, and the NHTB address are ephermal (they don’t exist on the cisco side); they just need to be unique for each vpn.

Routing is pretty straightforward – just specify the ephermal NHTB address as the next-hop:

routing-options {
    static {
        route 192.168.10.0/24 next-hop 172.31.255.2;
        route 192.168.11.0/24 next-hop 172.31.255.3;
    }
}

There is still one slight caveat here:

If you have multiple source subnets headed to the same destination then you will need to perform policy-based VPNs. This is because there is no way to specify the same destination subnet across two separate interfaces. In the case above we are using a single source subnet so this above configuration should work.

Studying for JNCIE-SEC Exam

Many people have now asked me for advice on how to pass the JNCIE-SEC Exam, which is a great thing as it seems many people are working towards achieving the next level in their certification journey. This post will cover:

  • Exam Objectives
  • Studying Materials
  • Additional Advice

In later posts I will discuss specific methods/techniques from those objectives.

A shout-out and thanks goes to CentraComm supplying many of the study materials/gear, as well as the terrific support and encouragement many coworkers provided throughout this journey!

Exam Objectives

So let’s first talk about what to study in order to prepare for the exam. Since this is a practical exam there is no single resource that covers every single aspect of the test. That being said, there are several books I would strongly recommend reading first in order to address 95% of the exam objectives:

One more important thing to know – be aware of what features are available for the version of Junos you are using! Right now the exam is set for 11.1, so things such as GRE tunnels in chassis clusters are not available. You can find those feature listings in either the Feature Explorer or the Feature Support PDF.

Studying Materials

You will absolutely need to get at least 2 SRX’s of the same model in order to set up chassis clustering and understand all the options for the clusters. In addition one of the units needs to be a High Memory unit in order to test UTM functionality. Obviously, the more the merrier is recommended in this case. The additional benefit of using the branch series is that they are extremely portable. I could fit my equipment into my carryon bag, and with the right cables/powerstrips it was extremely easy to set up a new mock lab anywhere I traveled. My lab was as follows (picture below):

  • 2x SRX-210’s
  • 3x SRX-100’s
  • 1x EX2200-C

MY JNCIE-SEC Lab

Other Advice

The nearest testing site for me was in Herndon, Virginia so that required booking a flight. I actually left two days early to get situated in Herndon, and to get one last day of good studying in before the exam. It turned out to be a blessing in disguise as the plane landed several hours late due to storms! A 4-hour flight turned into an 8-hour ordeal due to the weather. Trying to get through an ordeal like that the day before the exam would have been extremely unpleasant, and add unnecessary stress to an already stressful exam.

In terms of how long to study, I did nothing but read for about a solid month prior to using the lab gear. The books mentioned above provided a good solid background to all the functionality inside the SRX’s. From there I would go through the exam objectives and create scenarios to reinforce understanding of a particular piece of technology. One of the important things to remember here is that building out complicated networks still require fundamental knowledge in the basics. For an example if you do not understand how to create/troubleshoot a simple VPN tunnel or how the SRX’s negotiate both phases of the tunnel, then you will struggle at this exam. If you don’t know how to perform a certain task, then take a look at the vast wealth available on the Internet. Here are a couple of sites that I would refer back to constantly:

Take your time when going through the exam, and make sure you review your configurations after you have completed the exam. Even after reviewing my configs there were still minor errors that would have cost dearly on the final scoring.

Lastly, ask the proctor questions if you’re unsure of what is required on an objective. The proctor will not be able to tell you the answer if you are stuck at a certain point, but they can provide valuable guidance on what needs to be done in your configurations.

Hopefully this will help you in your journey to achieving the JNCIE-SEC certification. Feel free to ask questions here, and stay tuned for more posts on how to configure many of the objectives for this exam.