Junos Security is dead! Long live Junos Security!

I was hoping that title would catch your attention.

First and foremost this is a technical blog to discuss neat tricks and tips that I use daily, but sometime it’s a good idea to jump off the path and take a look at what is going on in the tech world. It is high time we start looking past traditional security firewalls or Next-Generation Firewalls and see where the path takes us.

For starters, I was recently at the Juniper Ambassador’s Conference and got to speak with the brilliant minds at Juniper Networks. I am quite sure everyone has heard about the significant changes that has been occurring at Juniper, and like many of you I had my concerns/reservations. While it is important to note is that there are still plenty of opportunities to improve the realm of Junos security in the short term I am excited for what is to come.

I feel that there is always going to be a need for traditional hardware firewalls in the network. Certain features make it extremely tough to remove hardware appliances completely; in particular I am talking about the edge firewalls that handle massive amounts of IPSEC tunnels or NATing public/private IP’s. In the future it would not be a long shot to put security functions in other parts of the network. As an example by moving firewall functions to the hypervisor then we can reduce the need of massive firewalls at the head end.

Let’s look at this idea for a moment. Consider the following traditional network:

traditional network

Typically you would have your network segments trunked to an interface on a firewall, or a unique interface per vlan directly connected to the firewall. This works great until you run out of interfaces, bandwidth, or processing power of the firewall – especially for that pesky intra-zone traffic!

Now consider adding security features to the hypervisor, such as a virtual firewall that connects its external interface to a flat vlan, and its internal interface to a specific vlan on the virtual switch. A diagram of such an idea is shown below:

new network

By offloading basic firewall or even IPS features to the hypervisor (which has far more compute power than that of a single hardware firewall) we can now free up the firewall to do more important tasks, and increase our scalability significantly! Combining this solution with some of the cool tools like Firefly Packer to help with automating these deployments you can have a significantly faster turnaround time for the needs of your network. This type of design also helps with reducing the failure domain of the network – if an issue crops up one of the hypervisor firewalls it only affects one group of devices, instead of causing an entire network outage. Smaller failure domains = higher overall stability.

Now certainly there are still a bunch of unanswered questions about designs like these, but this is the start of a significant change in how we all can view security and its application to the network. Sometimes it helps to take a step back from what features are missing in a device, and instead look at the opportunities that exist today and in the future.

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;
            }
        }
    }
}