A Beginners Guide to Junos Firewall Filters

In this post we’re going to look at something that Junos calls “firewall filters”. Some other vendors call them “access lists” or “access control lists”. Some vendors might even call them “swonky paps”. I don’t know, I’ve not used every single vendor.

It’s possible though, isn’t it? It is possible that there’s one vendor out there, somewhere in the world, that uses the term “swonky paps” to describe this function. I’m not wrong, am I? It is, in principle, theoretically possible. Just because you and I can’t immediately think of a vendor that calls them “swonky paps”, doesn’t mean that such a vendor doesn’t exist.

Look, I’m sorry to keep on about this, but: can you actually prove to me that there isn’t any vendor in the world that uses the term “swonky paps” to describe this feature? No. No you can’t. You can’t prove a negative. So how about you treat me with a bit more respect before you start coming on my website to call me names like “idiot boy” and “stupid idiot boy”.

Anyway, what was I saying? Oh yeah. You might think from the name “firewall filters” that Junos uses them to allow or block transit traffic through a device. Well, although that is true, you can actually do so much more with them:

• You can log traffic, including the most useful parts of the headers, which is a great way to save yourself time running packet captures to troubleshoot a problem;
• You can count packets;
• You can change the quality-of-service behavior of traffic;
• You can police traffic to a certain speed;
• You can redirect traffic out of a different interface to what your routing table thinks is best;
• You can redirect traffic to a different routing table entirely;
• You can filter traffic destined to the router’s control plane;
• And much more!

In other words, if you learn how to create Junos firewall filters, you unlock the ability to configure about a dozen different other features. Nice!

To start with though, this post focuses on the basics: blocking and accepting traffic. We’ll do all those other things it in a future post.

 

A QUICK NOTE FOR CISCO FOLKS

If you’re coming from a Cisco IOS background, then at first, the Junos way will seem longer than the way you’re used to.

Trust me – I also came from a Cisco background. I know exactly how you’re going to feel, because I’ve been through this precise experience myself. You’re going to look at this config, and think “Wow, this is longer than a Cisco access, and involves more typing. Therefore, I hate it.

I hope you’ll stick with me to the end of this post – because I’m going to try to help you see the three nice things it took me a long time to work out for myself:

• Although the config might look long, the actual typing involved is very short, because of the way the Junos hierarchy works.
• The “natural English” style of Junos firewall filters means that your brain is able to much more easily process what you need to type, which means you’re able to type quickly.
• In textbooks and examples you only ever see short Cisco access lists – but you and I both know that in the real world, access lists can quickly become very long, and almost impossible to read and maintain. By contrast, you’re going to see that Junos firewall filters are just as easy to read whether you have one or a hundred rules in them.

With all that in mind: stay with me. We’re going to learn some cool stuff here.

 

SOME REQUIRED THEORY KNOWLEDGE

This post assumes you have at least a little understanding of the very very basics of Junos.

In addition, before you read this post, ask yourself these questions:

– Imagine you had a firewall filter/access list that had ten rules in it. The order of these rules matters. Do you understand why this is? For example, if a packet matches rule number three, does the processing stop there, or does your device carry on checking the other rules as well? If you don’t know the answer to this, click here for an explanation as to why the order of rules is crucial.

– Do you know the difference between a stateful policy and a stateless policy? If not, click here for an explanation of the difference.

– Do you know how to customize Junos (and Cisco IOS) so that they don’t cut off your CLI input if you type too much? If not, click here. You’ll find this tip handy when you’re typing long lines of text!

 

THE TOPOLOGY FOR THIS POST

In the topology on this diagram, you can see that I have four hosts in a LAN, with the subnet 192.168.10.0/24. They’re in the yellow box on the left. Can you see them? Look closely. They’re on the left there. Do you see them? On the left. In the yellow box. Look closely. No, you’re looking at your microwave. Look at your screen. That’s it, you’ve got it!

Then, on the right, we have two much larger subnets, in the green and blue sections.

In the middle we have a router called COOL_ROUTER. Wow, what a cool name! This router must be really cool. After all, names like that don’t just come from out of thin air.

We’re going to add a firewall filter to this device. In particular, we’ll add it to traffic inbound on the ge-0/0/0 interface, which you can see connects to our LAN. On the left. Can you see it? In yellow.

What is our intent with this lab? Let’s imagine that we want to do three things:

1. ALLOW any traffic sourced from three hosts (192.168.10.1/32, 192.168.10.2/32, and 192.168.10.3/32), destined to anywhere.
2. BLOCK SSH traffic sourced from anywhere, destined to 10.20.0.0/16.
3. ALLOW everything else.

Look at this topology again, and take a moment to identify where these IPs are on this picture. Over this blog, we’re going to create a firewall filter that does exactly this.

 

WHAT DOES A JUNOS FIREWALL FILTER LOOK LIKE?

Firewall filters are found in the “firewall” hierarchy. You might be aware that there’s also a “security” hierarchy. We’ll talk more about that at the end, so stick around if that bit has ever confused you.

Junos firewall filters are basically just a series of if/then statements. “IF the traffic matches these conditions, THEN take these actions”.

Junos calls these if/then statements “terms”.

Each term is given a name, which means you have the opportunity give meaningful names to each individual section of the firewall filter – names that indicate its actual purpose. You could even put a ticket number in the term’s name. Gone are the days when you look at a random line in a 50-line-long access list, and go “err… what does this line do? Can I safely delete it? Will this break something somewhere? Will the world burn to the ground? Why did no-one write this down? What does it do?!”

Your eye has no doubt already noticed that there’s an example firewall filter below, where I’ve configured our intent for this lab. In a moment I’ll ask you to read it. As you do, notice that the filter itself has a name, and then each term also has its own name. I’ve given each term a different colour, so you can more easily identify the three terms, in this early stage of your learning.

Also, if you look carefully, you may notice that the second term (in blue) has an incorrect name, compared to what it’s actually doing. Oh no! Luckily, this is easy to fix. Later on in this post, we’ll do exactly that.

This filter is called “FROM_LAN_TO_INTERNET”. Give it a read, and see if you can work out what’s going on.

root@COOL_ROUTER> show configuration firewall
family inet {
    filter FROM_LAN_TO_INTERNET {
        term ALLOW_CHRIS_PARKERS_DEVICES {
            from {
                source-address {
                    192.168.10.1/32;
                    192.168.10.2/32;
                    192.168.10.3/32;
                }
            }
            then accept;
        }
        term BLOCK_PINGS_TO_THE_MOON {
            from {
                destination-address {
                    10.20.0.0/16;
                }
                destination-port ssh;
            }
            then {
                discard;
            }
        }
        term ACCEPT_ALL_ELSE {
            then accept;
        }
    }
}

 

“FROM” AND “THEN”

So, what’s going on here?

• The “from” section is your match conditions. If you didn’t know this, then it might be strange to read “from destination-address”. But it makes more sense now that you know you find all your match conditions in this “from” section.

(Lol, so it’s more like from/then, rather than if/then. But you know what they say: same meat, different gravy.)

• The “then” section is the action you want to take on your matched traffic. For the moment we’re just accepting and discarding (in other words, allowing or blocking) – but there’s much more you can do. It’s in this “then” section that you’d do all the other things we mentioned at the very start of this post, like changing the quality-of-service behavior of traffic, policing traffic, or counting/logging packets.

By the way, did you notice that only two of the terms (the red and blue ones) have a “from” section?

In fact, this “from” section is optional. If you don’t have any match conditions, then all traffic is matched. You can see this in the final term.

To be clear, there’s nothing stopping you from configuring some kind of match-all condition, if you want to make your intent explicitly clear. You could type something like “from source-address 0.0.0.0/0” for example. The point here is that you don’t have to do this. And besides, if your term is called something like “ACCEPT_ALL_ELSE”, then your intent is pretty clear already.

I don’t know about you, but I really like reading these firewall filters using the hierarchy view, as opposed to the set view. All of the white space and indenting means that important things stand out to me. It also means that I can immediately tell from the indented sections what’s going on. Anyone who has read a long access-list will know what a wall-of-text it can be, and how difficult it can be to quickly identify what’s going on. You have to read them pretty slowly. By contrast, you can scan your eyes down this hierarchical filter, because of the white space and the indenting.

The flip-side to that is that a firewall filter takes up more screen space than the average Cisco access list. But of course, there’s nothing stopping you from reading it in “display set” format if you want to. Not even the cops can stop us from doing that. Not even the feds. Try calling them. They won’t care.

 

SOME OTHER INTERESTING THINGS THAT STAND OUT IN THIS CONFIG

• You add firewall filters within the kind of protocol family you’re filtering – “family inet”, “family inet6”, “family ethernet-switching”, and so on.
• You can see that you use the “source-address” statement to match on a – you guessed it – source address!
• Similarly, you use the “destination-address” statement for… well, you can work it out.
• You can add multiple IPs to these statements.
• Alternatively, you can also create named “prefix lists”, where you can create a named list of as many IPs and ranges as you like, and then just refer to that named object. I’ll show you how to do that in a future post.
• How good is it that you can just type the subnet in slash notation? It’s so nice to just write /32 or /16. Gone are the days with “other vendors” where you first have to remember the long subnet mask, and then work out the inversion. How many times have you had to go “Okay, so a /29 is 255.255.255.248, which means it’s 0.0.0.8. No wait, it’s 0.0.0.7… I think? Is that right?” Bye bye to all that nonsense!

(Hey, if anyone knows enough website coding to know why my WordPress theme has less space between lines when they’re in a bulleted list, please contact me. It’s really annoying!)

 

WHAT KIND OF MATCH CONDITIONS CAN YOU ADD?

Omg so many. Literally anything you can think of. Source IP, destination IP, TCP/UDP port, QoS settings, TTL values, TCP flags like Syn/Ack/Syn-Ack.. and depending on the forwarding chips you’re using, there are even filters that let you match on precise hex values in the payload itself. If you can imagine it, chances are there’s a match statement for it. The power is in your hands!

I encourage you to go to a Junos box, start typing a firewall filter, and then type a ? after the word “from” to see all the match conditions. You can match on so many useful things. Here’s just a small sample:

• “address” (to match either source or destination)
• DSCP markings (6-bit QoS markings)
• Fragment info
• Forwarding class (in other words, all traffic in a certain QoS/CoS queue)
• ICMP type
• Flags in the IP options
• Packet length
• IP precedence markings (3-bit QoS markings)
• Prefix list (in Junos this literally just means a named list of prefixes that you can create)
• TCP flags (established, syn/ack)

And almost all of those comes with the equivalent option for the inverse of it. So for example, you could match on “destination-port-except”, which would match any traffic apart from that port.

Let’s focus on one term, and see its match conditions. Remember, this is the term that has a deliberately incorrect name, which we’ll fix later. The only thing correct about this name is the fact that the 10.20.0.0/16 range belongs to moon, in outer space. Which of course, you knew already.

term BLOCK_PINGS_TO_THE_MOON {
    from {
        destination-address {
            10.20.0.0/16;
        }
        destination-port ssh;
    }
    then {
        discard;
    }
}

There are loads of keywords like “ssh” that you can use as shortcuts for the most popular ports. You can also type the port number directly.

Notice that I’m not specifying TCP or UDP. This “ssh” word is just a shortcut for the port number. This isn’t like a stateful firewall rule, where you could specify SSH as an application, and let it take care of the rest. “ssh” is just a more human-friendly way of typing “22”. In other words, although the config says “ssh”, this is actually matching both TCP and UDP port 22.

With that in mind, how could I edit this term to specify TCP?

Thanks to the fact that your filter and terms all have names, you can add in any extra conditions at any time by simply referring to the name of the filter and term.

In real life I’d type the configuration all on one line. But to prevent it from word-wrapping in my blog, I’ll type it on two lines, by first going into the firewall filter, and then editing the term:

[edit]
root@COOL_ROUTER# edit firewall family inet filter FROM_LAN_TO_INTERNET

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER# set term BLOCK_PINGS_TO_THE_MOON from protocol tcp 

This new config hasn’t overwritten anything. It’s just added to the config that already exists.

And with that, my firewall filter is now more specific. I think that’s a great example of where Juniper firewall filters technically involve “more typing” than the access lists of other vendors, but that’s okay because you can do the typing so much more quickly – because it’s all in plain English. You’ll be amazed how quickly you can type these filters, once you get the hang of it.

Once I commit my change, the firewall filter now looks like this. I’ve highlighted the new part in green:

root@COOL_ROUTER> show configuration firewall family inet filter FROM_LAN_TO_INTERNET
term ALLOW_CHRIS_PARKERS_DEVICES {
    from {
        source-address {
            192.168.10.1/32;
            192.168.10.2/32;
            192.168.10.3/32;
        }
    }
    then accept;
}
term BLOCK_PINGS_TO_THE_MOON {
    from {
        destination-address {
            10.20.0.0/16;
        }
        protocol tcp;
        destination-port ssh;
    }
    then {
        discard;
    }
}
term ACCEPT_ALL_ELSE {
    then accept;
}

 

YOU CAN MATCH ON MULTIPLE THINGS AT ONCE

Let’s look more closely at the first term:

term ALLOW_CHRIS_PARKERS_DEVICES {
    from {
        source-address {
            192.168.10.1/32;
            192.168.10.2/32;
            192.168.10.3/32;
        }
    }
    then accept;
}

Notice that you can have as many source addresses as you like. You could also have as many ports as you like, or anything else.

In this example, you can think of these three IPs as acting like a logical “or”. In other words, a packet matches this term if the source IP is either 192.168.10.1 or 192.168.10.2 or 192.168.10.3. After all, a packet’s source IP clearly can’t be all three of those IP addresses at once!

It would be the same if we edited this term to match on either HTTP or HTTPS. In fact, let’s do that:

[edit]
root@COOL_ROUTER# edit firewall family inet filter FROM_LAN_TO_INTERNET

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER# set term ALLOW_CHRIS_PARKERS_DEVICES from protocol tcp

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER# set term ALLOW_CHRIS_PARKERS_DEVICES from destination-port http

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER# set term ALLOW_CHRIS_PARKERS_DEVICES from destination-port https

The term now looks like this:

term ALLOW_CHRIS_PARKERS_DEVICES {
    from {
        source-address {
            192.168.10.1/32;
            192.168.10.2/32;
            192.168.10.3/32;
        }
        protocol tcp;
        destination-port [ http https ];
    }
    then accept;
}

Each general match condition is treated as an “and” operation. In other words, a packet needs to match one of the source addresses, and one of the destination ports.

The result is that this one term matches on all of the following possibilities:

• Web traffic from 192.168.10.1/32
• Web traffic from 192.168.10.2/32
• Web traffic from 192.168.10.3/32
• Encrypted web traffic from 192.168.10.1/32
• Encrypted web traffic from 192.168.10.2/32
• Encrypted web traffic from 192.168.10.3/32

You can make some very scalable terms because of this. No need to have a hundred terms for all the combinations, when just one term will do the job nicely.

It’s really easy to just remove single items from a term, so you don’t need to worry about maintaining a term that has a lot of things in it.

And of course, you can always verify your work before you commit, which means that you really have to go out of your way to break things. There’s lots of nice safeguards in place.

 

WHAT KIND OF ACTIONS CAN YOU TAKE ON MATCHED PACKETS?

Despite being called “firewall filters”, Junos doesn’t just use them to allow or block packets. In fact, they’re even used to manipulate packets. As was mentioned at the start, you can do anything from policing traffic, to manipulating QoS values, to forwarding traffic in a different way, to counting and logging packets.

In the next post we’ll see how to do many of these things.

For now, these are the three main “then” actions you’ll want to know about: accept, discard, and reject.

• “accept” allows the traffic through.
• “discard” silently drops the traffic.
• “reject” drops the traffic, and sends an ICMP “destination unreachable” message back to the sender.

All three of these are known as “terminating actions”. This means that the firewall filter processing ends here. No more terms are looked at.

For the time being I won’t say any more, other than to say that in Part 2 we’ll talk about the idea of nonterminating actions, where you can configure your device to keep on processing the packet against other terms. This is great if, for example, you want to log packets in one term, and then take some kind of action in another term. Remember that you can do a lot with firewall filters, so it makes sense that you would have this flexibility. But that’s a story for another day.

 

CONFIGURING THIS FIREWALL FILTER

Okay, so we’ve read a firewall filter it in hierarchy format. Now let’s talk about how you’d configure it.

First, I’d go into the hierarchy for this particular filter:

[edit]
root@COOL_ROUTER# edit firewall family inet filter FROM_LAN_TO_INTERNET

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER#

Then, I’d type these commands. However, I wouldn’t type each one out – I’d use the “up” key to just delete the last few character I’d typed. Or, I’d press Ctrl-W to delete entire words at a time.

Again, this is what I mean about it not actually being that much typing. If you were new to Junos then you might look at the config below, and think “wow, that’s a lot of typing”. In practice though, you’re only typing the last few letters of each line, apart from when you want to make a new named term, in which case you’re pressing up and then Ctrl-W a few times.

set term ALLOW_CHRIS_PARKERS_DEVICES from source-address 192.168.10.1/32
set term ALLOW_CHRIS_PARKERS_DEVICES from source-address 192.168.10.2/32
set term ALLOW_CHRIS_PARKERS_DEVICES from source-address 192.168.10.3/32
set term ALLOW_CHRIS_PARKERS_DEVICES from protocol tcp
set term ALLOW_CHRIS_PARKERS_DEVICES from destination-port http
set term ALLOW_CHRIS_PARKERS_DEVICES from destination-port https
set term ALLOW_CHRIS_PARKERS_DEVICES then accept
set term BLOCK_PINGS_TO_THE_MOON from destination-address 10.20.0.0/16
set term BLOCK_PINGS_TO_THE_MOON from protocol tcp
set term BLOCK_PINGS_TO_THE_MOON from destination-port ssh
set term BLOCK_PINGS_TO_THE_MOON then discard
set term ACCEPT_ALL_ELSE then accept

 

REMOVING THINGS FROM A FIREWALL FILTER

Oh, I just noticed something! Something I definitely didn’t do deliberately, for the purpose of narrative!

Earlier on, we added TCP and HTTP/HTTPS to the term called ALLOW_CHRIS_PARKERS_DEVICES.

I only did that to show you how to add things. However, now I want to delete those lines. I want to allow all traffic sourced from those three IPs, for any protocols.

In Junos I can easily delete just part of a term. This deletion won’t affect the rest of the term. Again, to prevent word-wrapping in my blog, I’ll first go into the hierarchy for my firewall filter:

[edit]
root@COOL_ROUTER# edit firewall family inet filter FROM_LAN_TO_INTERNET

Then, I’ll delete the pieces of the term that I want to remove:

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER# delete term ALLOW_CHRIS_PARKERS_DEVICES from protocol

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER# delete term ALLOW_CHRIS_PARKERS_DEVICES from destination-port

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER#

Wait a second – I didn’t specify to delete http or https, or even tcp. What happened here?

This is the hierarchy in action. “http” and “https” both live under the “destination-port” hierarchy. If I delete that hierarchy, then I delete everything underneath it. The same is true for “tcp”, under the “protocol” hierarchy. Little time-savers like that can speed up your day.

 

CHANGING THE NAMES OF TERMS

We’re almost ready to apply our firewall filter. We’ve made a few changes, so let’s just check one more time that everything is good:

root@COOL_ROUTER> show configuration firewall
family inet {
    filter FROM_LAN_TO_INTERNET {
        term ALLOW_CHRIS_PARKERS_DEVICES {
            from {
                source-address {
                    192.168.10.1/32;
                    192.168.10.2/32;
                    192.168.10.3/32;
                }
            }
            then accept;
        }
        term BLOCK_PINGS_TO_THE_MOON {
            from {
                destination-address {
                    10.20.0.0/16;
                }
                protocol tcp;
                destination-port ssh;
            }
            then {
                discard;
            }
        }
        term ACCEPT_ALL_ELSE {
            then accept;
        }
    }
}

WAIT A SECOND – that middle term is named wrong! The term is blocking SSH traffic to the moon. However, the name says that it’s blocking ping.

This is easily fixed. To rename things, you just use the “rename” command:

[edit]
root@COOL_ROUTER# edit firewall family inet filter FROM_LAN_TO_INTERNET

[edit firewall family inet filter FROM_LAN_TO_INTERNET]
root@COOL_ROUTER# rename term BLOCK_PINGS_TO_THE_MOON to term BLOCK_SSH_TO_THE_MOON

After committing my change, let’s look again:

root@COOL_ROUTER> show configuration firewall
family inet {
    filter FROM_LAN_TO_INTERNET {
        term ALLOW_CHRIS_PARKERS_DEVICES {
            from {
                source-address {
                    192.168.10.1/32;
                    192.168.10.2/32;
                    192.168.10.3/32;
                }
            }
            then accept;
        }
        term BLOCK_SSH_TO_THE_MOON {
            from {
                destination-address {
                    10.20.0.0/16;
                }
                protocol tcp;
                destination-port ssh;
            }
            then {
                discard;
            }
        }
        term ACCEPT_ALL_ELSE {
            then accept;
        }
    }
}

Perfect!

 

APPLYING A FIREWALL FILTER

These filters in themselves don’t do anything until they’re applied. The most common way to use them is to apply them to an interface, either inbound or outbound.

When you apply this firewall filter to an interface, you do so using the filter’s name. The days of keeping track of access-lists based just on some random arbitrary number are over!

Applying the filter is just one line of config. Here I’m adding my filter to any inbound traffic on this interface, and to IPv4 traffic in particular:

[edit]
root@COOL_ROUTER# set interfaces ge-0/0/0 unit 0 family inet filter input FROM_LAN_TO_INTERNET

 

TESTING OUR FIREWALL FILTER

Let’s hop over to our machine at 192.168.10.1, and see if it can ping 10.20.0.1. This traffic should match the first term, which allows all traffic from this IP to anywhere:

root@192-168-10-1> ping 10.20.0.1
PING 10.20.0.1 (10.20.0.1): 56 data bytes
64 bytes from 10.20.0.1: icmp_seq=0 ttl=63 time=5.919 ms
^C
--- 10.20.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.919/5.919/5.919/0.000 ms
root@192-168-10-1> 

Good. How about SSH?

root@192-168-10-1> ssh chris.parker@10.20.0.1
The authenticity of host '10.20.0.1 (10.20.0.1)' can't be established.
ECDSA key fingerprint is 90:d9:c3:b6:34:5c:03:14:56:5a:60:9c:39:d1:b9:e8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.20.0.1' (ECDSA) to the list of known hosts.
Password:
--- JUNOS 14.1R4.8 built 2015-01-28 03:38:12 UTC
chris.parker@10-20-SLASH-16>

chris.parker@10-20-SLASH-16> exit
Connection to 10.20.0.1 closed.
root@192-168-10-1>

Perfect. So far, so good.

Now, let’s see if 192.168.10.4 can SSH to 10.20.0.1. This should fail. This source IP isn’t in the first term – which means the traffic should match the second term, which blocks all SSH traffic to the 10.20/16 range:

root@192-168-10-4> ssh chris.parker@10.20.0.1
^C
root@192-168-10-4>

Fantastic! I left that command to run for like ten seconds before cancelling it. You can’t see this ten seconds of waiting in the output above, so you’ll have to believe me. Or, pay me £750,000 for a private demonstration.

Just to double-check – can 192.168.10.4 ping 10.20.0.1? This should work, because it should match our third “accept all else” term:

root@192-168-10-4> ping 10.20.0.1
PING 10.20.0.1 (10.20.0.1): 56 data bytes
64 bytes from 10.20.0.1: icmp_seq=0 ttl=63 time=4.120 ms
64 bytes from 10.20.0.1: icmp_seq=1 ttl=63 time=4.166 ms
^C
--- 10.20.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.120/4.143/4.166/0.023 ms
root@192-168-10-4>

Brilliant! Great work team!

 

JUNOS FIREWALL FILTERS vs JUNOS SECURITY POLICIES

One final thing, to clear up confusion among those readers who are already at the level of “I know just enough to be dangerous”.

You will be aware that Juniper sells actual hardware firewalls, which have stateful rules. If you know a little about these things already, you might know that the stateful security policies on these devices are found in the “security” hierarchy.

Yep, that’s right:

• Stateless rules are in the “firewall” hierarchy.
• Stateful rules (the ones used on actual firewalls) are in the “security” hierarchy.

Ever wondered why that is?

I have no citation for what I’m about to tell you, other than “many experienced engineers before me” have told me that the answer is “because of history”.

Like a lot of things in networking, these decisions were made a long, long time ago. In this case, the decision to put stateless rules in the “firewall” hierarchy was made in the very late 90s, before Juniper even sold firewalls! And once things are in place… well, good luck changing them.

In fact though, the syntax is really similar between firewall rules and security policies. So once again, if you learn firewall filters, you’re like 90% of the way towards understanding security policies.

And hey, here’s a cool thing: now that you’ve learned firewall filters, you’re like 75% of the way towards understanding Junos routing policy, where you can redistribute prefixes between routing protocols. Routing policies are also just a series of if/then statements, with a basically identical hierarchical philosophy. Once again, the logic and syntax is almost identical.

That’s pretty cool, right? Seriously, with just a little bit of learning, you find that you unlock the ability to do so many things. Whenever I’ve taught Junos to people, they’re often astonished at how repeatable these things are, and how quickly they are able to do some very powerful things.

 

THAT’S IT – FOR NOW!

It’s so difficult to write a short post on this topic, because there’s so much to explain. To make it shorter would be to remove context – and in my experience, it’s exactly this lack of context that makes new students struggle with concepts like this. I hope it was helpful to you that I took the time to explain around the topic.

I especially hope it’s helped Cisco engineers to at least become familiar with what’s going on. I hope you’ll now lab all of this up, and try to create some filters of your own. Once you get a bit of practice in, I think you’ll really enjoy using them.

Part 2 will come soon. In the meantime, thank you very much for reading! If you enjoyed it, please share this post with your colleagues, or on your favourite social media of choice. If you really enjoyed it, I’ll never say no to a donation. This website is very much a money-losing endeavour, and anything that helps me get closer to breaking even is always appreciated.

If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

Or, don’t follow me! It’s up to you. I don’t mind either way. Do whatever you heart tells you to do. Actually, definitely don’t follow me. It’s too stressful. Go and follow an account that shares pictures of bears sitting under trees or something. That’s much better for your general happiness.

Thank you for reading!