Aaron's Worthless Words

It's possible that someone somewhere needs to see this.

Archive for the ‘configuration’ tag

Junos Configuration Groups

with one comment

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.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website

Written by Aaron Conaway

May 21st, 2012 at 9:02 am

Posted in junos

Tagged with , , , ,

A Little Story on Switch Configuration

without comments

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.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website

Written by Aaron Conaway

March 26th, 2012 at 8:28 pm

Posted in cisco

Tagged with , ,

Junos – VPN Hierarchy

with 3 comments

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.

security
ike
proposal <<<<  Think ISAKMP policy on Cisco
authentication-method <<<< PSK
dh-group
authentication-algorithm
encryption-algorithm
lifetime-seconds
policy
mode <<<< Main versus quick
proposal
pre-shared key <<<< The key and the proposal are bound together
gateway <<<< The remote peer
ike-policy
address
external-interface <<<< Think the if where you put the crypto map
ipsec
proposal <<<< Transform set…kinda
protocol (ESP)
authentication-algorithm
encryption-algorithm
lifetime-seconds
policy
proposal
vpn
bind-interface <<<< Complicated story
ike
gateway
proxy-identity <<<< Also complicated
local
remote
ipsec-policy
establish-tunnels immediately <<<< Awesome!

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.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website

Written by Aaron Conaway

December 23rd, 2011 at 3:58 pm

Posted in junos

Tagged with , , , , ,