Archive for the ‘configuration’ tag
Junos Configuration Groups
It has been quite a spring so far. I’ve spent the last two months at our data center racking, railing, mounting, cabling, extending, labeling, and documenting a whole pile of switches, routers, and firewalls for our new environment. I won’t and can’t go into the details, but it’s a huge project for the company that I’m proud to be trusted with. Anyway, now that the physical build is finished (for definitions), I’m finally getting really deep into the configuration. Since we’re a Juniper shop, I’m finding all sorts of stuff that’s fun to explore.
One cool thing I’ve found is the configuration group, which is a way to create a configuration template. The classic example is to use a config group to create a default-deny template for all security policies. No one wants to have to remember to create the deny policy every time they create a new security zone. Or, even better, let’s say that the security team now wants us to log every time a connection is denied. Instead of having to modify a dozen or more security policies ( it’s an n(n-1) thing usually), we could just modify the group, and everything gets updated.
I’m doing this on an SRX240 running 11.4R2.14. First, we create the template through groups at the top of the hierarchy. We’ll create one called “DEFAULT_DENY_TEMPLATE” for the example. Inside that group, we just configure a new security policy with the settings we want. If you’ve ever done security policies, though, you’ll know that you should specify both a from and to security zone. Luckily, we’re able to use wildcards in certain parts including the security zones ( don’t ask me what the rules of wildcard are; I don’t know. :) ). Instead of a zone name, you can just use “<*>” to signify all zones. To finish the details out, we’ll do a deny from all to all on all ports and log the session initiation.
groups {
DEFAULT_DENY_TEMPLATE {
security {
policies {
from-zone <*> to-zone <*> {
policy LOG_DENY_ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
}
}
}
}
Now we have to apply the group properly. We can apply it at any number of spots in the hierarchy. In my limited experience, I’ve just applied them at the top of the config. I’m sure there are strategies that would say to apply them elsewhere, but it works there.
apply-groups DEFAULT_DENY_TEMPLATE;
Easy enough. Let’s check our work by looking at the security policy config.
aconaway@SRX> show configuration security policies from-zone UNTRUST to-zone TRUST
policy ANY {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit;
count;
}
}
Wait. What? Where did the template go? We just added another policy, right? One of the things that drives me crazy with Junos is that any config that is inherited is not shown unless you tell it to do so with “| display inherited”. I’s way too much output to include here, but you’ll see a whole mess of annotate config that shows the inherited policy. Of course, we can just do a “show security policy” to see what’s actually applied.
aconaway@SRX> show security policies from-zone UNTRUST to-zone TRUST
From zone: UNTRUST, To zone: TRUST
Policy: ANY, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: junos-http
Action: permit
Policy: LOG_DENY_ALL, State: enabled, Index: 19, Scope Policy: 0, Sequence number: 2
Source addresses: any
Destination addresses: any
Applications: any
Action: deny, log
Any changes you make to the group will be applied to all security policies when you commit. Pretty cool stuff. I’m sure I’ll wind up using it more down the road.
Send any BBQ tips questions to me.
A Little Story on Switch Configuration
Here’s another story from the late night. I’ve changed the details to protect the innocent, but you’ll get the idea.
I think most of you know that I started a new job late last year, and I’ve spent my waking hours getting caught up on how the new company works, how everything fits together, and all that jazz. One of the big reasons that I (and a number of others) were brought in was to fix the biggest problem; the company doesn’t have a real central control over customer-facing technologies. There’s a group that does central IT for the company (Exchange, SharePoint, Oracle apps, etc.), but there are dozens and dozens of applications out there. That means there are dozens of “network teams” around the world doing their own thing.
One of those groups gave me a call the other day for some help. Their stack of old 2950s was having some issues, and they needed my help to figure out what was going on. Among the symptoms were flapping interfaces on the firewall and – the best of all – every command was greeted with an memory error. Want to see the config? Too bad. Want to see the memory utilization? Too bad. How about configure the thing? Too bad. The only command that I could actually get to work was a show version, but that’s pretty pointless when trying to troubleshoot issues.
So, what did I find? Nothing that could help with the problem, but plenty of stuff to fix. Bascially, the switch has VLAN 1, it’s layer-3 interface, and a single username configured. Nothing else. The configuration items that I consider to be basic just weren’t there thanks to the group’s network guy being a jack of all trades and master of none. Does putting every host on VLAN1 work? Sure it does. Would you just turn on your switch and not configure anything? I hope not. Does someone who does networking part-time thing it’s a problem? Obviously not.
So, what was missing? For starters, there was no syslog server configured (or even existed on the network at all). That’s a problem since the only way that I could see the logs was to reboot the switch and try again. What did the logs say when I finally rebooted the guy? Nothing since the buffer is empty, but the logs for the boot messages started with “1h3m” by the time I got back to it. That means the service timestamps commands for logging were missing. That lead me to ask what the time was on the box. Did you guess it was March 1, 1993? Yeah – no NTP server set, either. Without these basic configuration items, the odds of doing any troubleshooting are just about zero. Actually, they are zero in this case. The basics were missing, and now we have no idea what the real cause of our problems was.
I found a whole mess of other issues, too. The second switch was connected over an access port. No password encryption service. Both switches were unconfigured VTP servers. Not a single interface description. My OCD definitely kicked in that day.
I guess I’ll have to work for my paycheck this week.
Junos – VPN Hierarchy
Wow! A Junos post! Amazing.
We all know that the configuration on a Junos box is very hierarchical. Sometimes it doesn’t make a lot of sense, but it’s all a pretty cascade of code. One of the big messes that I’ve found is the VPN configuration hierarchy; there are way more items to configure than on an IOS device. To reinforce the stpes in my head, I thought I’d get some of the pieces into a post. These aren’t all the options, but it’s all you need to get a static IPSec tunnel up and running.
That’ll do, pig. I’ll fire off a real configuration post later. Feel free to add your pair of pennies since I’m a total Junos n00b.
Send any stocking stuffers questions my way.