Backgroound Image

TOGAF 9.2 Foundation Certification

About the Exam

I recently passed the TOGAF 9.2 Part 1 exam.  This is an Enterprise Architecture exam from The Open Group.  The Open Group is an open group (who would have guessed?) that includes a number of big names.  You can read more about them at their site: https://www.opengroup.org/

The TOGAF certification actually contains two parts, Foundation and Certified.  You can earn the Foundation certification, and then upgrade to the full Certified status by completing an additional exam.  You can also sit both exams back to back and go directly to the Certified status.  More info on the certification can be found here: https://www.opengroup.org/certifications/togaf

For me, since I’m new to the TOGAF standard, I decided to do the Foundation exam first, and once I’ve finished that then move on to the Certified upgrade.

How I Prepared

For my study materials I bought the TOGAF┬« 9 Foundation Study Guide – 4th Edition

After reading through the book I think it’s a decent read.  It can be repetitive at times, but since some of the concepts are new to me I actually think it’s helpful.  There are practice tests included in the book, and they are almost identical to the separate practice tests sold by The Open Group.  If you get the book then I wouldn’t bother getting the practice tests.

I also watched Pluralsight video series on TOGAF. The thing I liked about the video series was the use of a fictional enterprise that was going through an Enterprise Architecture process.  In the Study Guide I had some trouble really understanding what some parts would look like in practice, so this material helped fill in some gaps.

There’s also the TOGAF library which contains a lot of useful information about the TOGAF standard.  However, for this exam that material really isn’t needed.

Taking the Exam

The TOGAF exam was similar to most other Pearson VUE exams.  The registration is done through The Open Group’s site, which redirects you to the Pearson VUE site for scheduling.  I was able to take the test at the same site I’ve used for Cisco and VMware exams, so the test environment was quite familiar.

The test itself is pretty straightforward.  It’s 40 questions, all multiple choice.  The passing score is 55% with each question equally weighted.  That means if you get at least 22 correct you’ll pass.  Since it’s not an adaptive test you are able to go back and review questions prior to completing the exam.

I really didn’t find the exam to be too terribly difficult.  There were a few questions that I had to guess on, but I was confident on about 70% of my answers.  Since the passing score is 55% I didn’t worry too much about the ones I was unsure of, and I ended up passing.

What’s next

It can take up to 6 business days for the score report to become official.  I am planning to start studying for the TOGAF Certified exam, and I hope to sit the exam in 2-3 weeks.

Update: I took the exam after, and wrote another post about it.

Cisco ISR Project – vWAAS deployment (14 of ?)

(I just noticed that I forgot to publish this, so anyone reading my posts on IWAN deployment… Sorry this one’s a few years late…)

To get the WAAS deployment done there are a few prerequisites:

  • Virtual Central Manager (vCM) deployed (at HQ)
  • vWAAS appliance deployed (at HQ)
  • vWAAS appliance deployed (at branch)
  • WAN connectivity between branch and HQ

A couple things to be aware of right off the bad:

  • Default username is: admin
  • Default password is: default
  • Telnet is enabled by default, and SSH is disabled.
    • To enable SSH run these commands from a config prompt (make sure hostname and domain are set before running)
      • ssh-key-generate
      • sshd enable
    • Telnet can be disabled, however, it seems the management software 
  • When logging into the web interface if there is a prompt to select an SSL certificate, click Cancel.  That should bring up the login page.

After the OVA has been deployed you should be able to log into the appliance and it should automatically start the device configuration.  If not simply enter the ‘setup’ command.

The setup between the vCM and vWAAS is pretty similar, so I’m just going to go over the vWAAS as there are more of those.  However, the vCM does need to be configured before the vWAAS, as the vWAAS needs to connect to the vCM.

WAAS setup

The setup is text-based, and pretty straightforward.  One thing to be aware of is if the CMS service fails to start (I set up vWAAS up without setting the correct vNIC settings) you can run the command ‘cms enable’ from a config prompt.  That should force the vCM to start, or force a vWAAS appliance to register with the vCM.

After completing the setup a window will pop up with a list of commands to configure WCCP on the router.

WCCP template

To make things easier, here’s a text version of the commands:

ip wccp version 2

ip wccp 61 (optional:waas-wccp-redirect-list) 

ip wccp vrf IWAN-PRIMARY/SECONDARY 62 (optional:waas-wccp-redirect-list)  

interface (Router LAN interface(s)) 

     ip wccp 61 redirect in 

interface (Router WAN interface(s)) 

     ip wccp vrf IWAN-PRIMARY/SECONDARY 62 redirect in

interface (Router NM-WAE interface) 

     ip wccp redirect exclude in

(optional: 

  ip acces-list extended waas-wccp-redirect-list 

       acl1 

       acl2 

       …. 

       aclN 

)

One thing that isn’t covered in this default config is the ISR uses VRFs for the WAN interface(s).  For the WAN interface enter the correct VRF and then the commands should work.

Links:

WAAS: http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v611/configuration/guide/cnfg/traffic.html

Prime: http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-0/user/guide/pi_ug/WAAS.html

CISSP Certification

I recently received a provisional passing score on the (ISC)┬▓ CISSP exam, and I thought I’d share what I learned.

About the exam


First off, the CISSP is a certification centered around IT security, and in touches on both management and engineering aspects of IT security.  You can read more about what the CISSP entails here: https://www.isc2.org/Certifications/CISSP


One of the requirements of the CISSP certification is that you have at least five years experience in at least two of the eight domains.

  • Security and Risk Management
  • Asset Security
  • Security Architecture and Engineering
  • Communication and Network Security
  • Identity and Access Management
  • Security Assessment and Testing
  • Security Operations
  • Software Development Security

You can also get a 1-year waiver if you have a 4-year degree, or an approved certification.

When I decided to go for the CISSP I already had 15 years experience, though most of it was on the network engineering side of things.  Due to the breadth of material covered in the exam I easily spent more time preparing for this test than any other certification test I’ve taken.

How I prepared

As I mentioned, I’ve had 15 years experience, so I’m familiar with most network security concepts from an engineering standpoint.  However, this exam goes into a lot more than just the technical side of cyber security.  A lot of the legal frameworks were new to me, as well as the software development side.

I started off by reading the CISSP Exam Cram (4th Edition).  That book is based on a previous CISSP exam, but the content is still relevant to the 2018 version of the test.  I read this cover-to-cover, making a number of highlights along the way.  I then went back through and went over those highlights again to really solidify what I read.

I also had the Sybex Official Study Guide and Practice Tests.  This book is much bigger, and I thought it went into more detail than the Exam Cram.  I mainly used to book as a reference for areas that I found I was weak in after taking the practice tests or concepts that I wasn’t confident in after finishing the Exam Cram.

To break up the monotony of reading I also watched the CISSP video series through Pluralsight.  I found the videos informative, but after having done so much reading it was a bit difficult to stay focused when reviewing content I was already familiar with.  I actually think the video series provides a great foundational level, and I would have been better off if I’d started with it before I did the reading. 

Lastly, I also read the Eleventh Hour CISSP Study Guide. I got the Kindle version, and I read through it a couple times in the days before the test.  This is a really condensed version of the material, but I thought it was a great refresher. 

Personally, I’m a big fan of practice tests.  I find that they often help highlight where my weaknesses are, so I can focus my studies more in those areas.  For the CISSP exam I must have done over 800 practice questions.  The exam covers a wide range of material, so I wanted to make sure I didn’t have any gaps.

The exam itself

Having taken exams for PearsonVue and Prometric in the past this exam really wasn’t much different.  The testing center did palm scans, and they were a lot more controlled than other exams, but nothing to significant.

Not that this is unusual for certification exams, but the CISSP exam seems to take pleasure in using some tricky questions.  Without getting into NDA space I’ll just use a very loose example-

Q: Which of these BEST describes what is needed for a sandwich

A: Peanut Butter

B: Mayo

C: Bread

D: Meat

Well, a sandwich could made with all of them (at the same time if your brave enough).  The correct answer is C because a sandwich is (at least by definition) made with bread.

In the US the exam is adaptive, meaning there’s no Back button, so when you submit an answer you’d better be happy with what you selected.  Read twice, click once.  It also doesn’t tell you how many questions there are.  It just stops abruptly somewhere between 100 and 150 questions.  The screen doesn’t display a result either.  You don’t find out if you passed or not until you get the score report.  The score report should indicated if you passed or failed, and if you failed it should list the domains you were weak in.  There’s also situations where a score isn’t immediately available.

After the exam

If you passed the exam you should get an email confirmation a couple days later with information on submitting an endorsement application.  The process is pretty straightforward, but it can take upwards of eight weeks for everything to be approved before the certification is official.

 Right now I’m still waiting for the official approval, so any addition details will come along when that’s complete.

VMware Horizon View – Service not binding to 443 after SSL certificate renewal

Here’s a quick and easy one.  Since this has burned my twice (and caused more hours of troubleshooting than I care to admit) I’m going to put it here in hopes that I remember it next time.

The short version: When importing the certificate make sure to check the box to make the SSL certificate exportable.

Continue reading “VMware Horizon View – Service not binding to 443 after SSL certificate renewal”

Cisco ISR Project – Cloud Web Security config (13 of ?)

In our deployment each location will have a dedicated internet connection.  Since we want to restrict access to specific URLs (sorry, no porn, no Netflix, and no Facebook) we need each location to have a filter in place.  However, that seems cumbersome to manage.  It would be nice to have a centralized management point for all locations, as they will all have the same policy.

Enter Cisco Cloud Web Security.  There is an ISR connector that routes all web traffic through Cisco datacenters where traffic policies are applied.  First things first, this is a subscription-based service, so a subscription must be purchased.  Once that is done and the account is set up (the purchaser will receive a couple e-mails on account creation and provisioning) then it’s time to get things moving.

Before starting the configuration two things must be done. A company key needs to be created, and a certificate needs to be downloaded.  To create the key log in to the CWS portal and click the Admin tab, then in the menu bar select Management, and then click Company Key.

Company Key

Make sure you store the company key in a secure location.  If you lose it you will need to revoke and regenerate it, which means that all devices will also need to be reconfigured.

There should also be an e-mail sent with a certificate that must be installed on the router to establish the CWS tunnel.

Now on to the actual configuration.  You will need to have the following information handy:

  • CWS certificate
  • LAN subnet
  • Tower 1 IP
  • Tower 2 IP
  • Company key

First, the certificate install.  From a config prompt run these commands:

crypto pki trustpoint cws-trustpoint
revocation-check none
enrollment terminal
exit
cry pki authenticate cws-trustpoint

It will prompt you to enter the certificate.  Paste in the certificate (including the Begin and End lines).  After the certificate enter a blank line and then hit the Enter key.  It should then prompt to accept the new certificate.

The next step is to create a couple ACLs.  The first is a simple ACL to specify the source LAN, and the second is a whitelist of IP addresses to avoid CWS.

access-list 80 permit 1.2.3.4 0.0.0.0      

ip access-list extended cws-whitelist
 permit tcp any 10.0.0.0 0.255.255.255
 permit tcp any 172.16.0.0 0.31.255.255
 permit tcp any 192.168.0.0 0.0.255.255

Make sure to enter the correct LAN subnet in ACL 80.  If there are any additional IPs that should be added to the whitelist then add them to the cws-whitelist ACL.

Next is importing the Cisco CWS certificate from Cisco.  This does require external access and DNS to be configured on the router.  Here’s the command for that import:

crypto pki trustpool import url http://www.cisco.com/security/pki/trs/ios_core.p7b

Now comes the actual CWS tunnel configuration:

parameter-map type cws-tunnel global
primary
tower ipv4 1.2.3.4                                              
secondary
tower ipv4  1.2.3.4                                             
license 0  123123123123                                             
redirect-list 80
whitelist
download interval 10
acl name cws-whitelist
fail-open

Make sure to set the correct Tower IPs, and enter the Company Key that was generated through the CWS portal.  One thing to be aware of is the “fail-open” line.  This line configures the router to allow all web traffic if there is a CWS failure.  This can be configured to drop all traffic by changing it to “fail-close”

Almost done, the next step is to set the inbound and outbound interfaces for the tunnel.

int gi0/0/0cws-tunnel in

int gi0/0/1cws-tunnel out tunnel-number 150

For each interface (and sub-interface) that will have end-user traffic that needs to be filtered use the “cws-tunnel in” command.  For the outbound connection the tunnel number must be specified.  This will automatically create two tunnels, one for the tunnel number specified, and another tunnel that is incremented by 1.  In the example above tunnel 150 would be created as primary, and tunnel 151 would be created as a backup.  The primary tunnel uses the destination of Tower 1, and the backup uses the Tower 2 IP.

Last comes some commands to make CWS play nice with the IWAN configuration that’s been done so far.  Since there are VRFs, and ZBF rules there are some extra steps.

Configure the IKE profile to use the IWAN-SECONDARY VRF:

crypto ikev2 profile cws_ikev2_profile_150
 match fvrf IWAN-SECONDARY

Create a route map for routes back to the inside network:

route-map INET-Internal permit 10
 description Return routing for Local Internet Access
 match ip address InternalNetworks
 set global

The last step is to apply the VRF, route map, and zone membership.

interface Tunnel150
 description CWS connector internal primary tunnel
 ip vrf forwarding IWAN-SECONDARY
 tunnel vrf IWAN-SECONDARY
 zone-member security Internet
 ip policy route-map INET-Internal 

interface Tunnel151
 description CWS connector internal secondary tunnel
 ip vrf forwarding IWAN-SECONDARY
 tunnel vrf IWAN-SECONDARY
 zone-member security Internet
ip policy route-map INET-Internal

Running the command “show cws-tunnel status” should show the tunnel as being UP-ACTIVE

From a client machine you should be able to browse to http://whoami.scansafe.net and see the correct Company name.

Cisco ISR Project – Internet failover config network config (12 of ?)

Each office will have their own internet connection, but in the event that connection fails the desire is to have branches backhaul internet access over the MPLS to the data center.  Since there is the possibility that the internet failure is located somewhere other than between the branch ISR and the ISP device there needs to be a method to verify connectivity.  Enter the IP SLA commands.

The following commands will set this up.  First, the actual IP SLA command.  The SLA is created, a request type, target, and source is specified, the VRF is specified, then threshold and frequency are set.  The threshold is how many milliseconds pass before marking the link is down.  The frequency is how often the requests are sent. 

ip sla 11

 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 12

 icmp-echo 8.8.4.4 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 13

 icmp-echo 4.2.2.2 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 14

 icmp-echo 198.41.0.4 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 15

 icmp-echo 198.41.0.4 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

As you can see, there are five listed.  Two are Google DNS servers, one is a Level3 DNS server, and the last two are root DNS servers.  I chose five because I thought it was enough to confirm an actual internet outage, but not so many as to bog the system down with requests.

The next step is to schedule the SLA commands to run.  The commands are pretty self-explanatory.  Run forever, start now.

ip sla schedule 11 life forever start-time now

ip sla schedule 12 life forever start-time now

ip sla schedule 13 life forever start-time now

ip sla schedule 14 life forever start-time now

ip sla schedule 15 life forever start-time now

Now the important part comes in.  Just because we are running these commands doesn’t mean much.  We want to track the reachability.  The following commands do just that.

track 11 ip sla 11 reachability

track 12 ip sla 12 reachability

track 13 ip sla 13 reachability

track 14 ip sla 14 reachability

track 15 ip sla 15 reachability

Next is creating a list of these SLAs.  Then setting a threshold.  In this command if half the sites are down the group is marked as down.  

track 10 list threshold percentage

 object 11

 object 12

 object 13

 object 14

 object 15

threshold percentage down 49 up 50

The last step is to actually put this into use.  The route from the default VRF needs to be removed and replaced with the same command, but with the track command added.

no ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 Next_Hop_IP track 10

Now, if the tests to the external sites fail the default route is removed.  Then, a default route can be learned through EIGRP to route back through the data center to get out to the internet.

Here are a couple commands for troubleshooting:

show ip route track-table

show ip sla summary

The other side to this is configuring the data center router to advertise the default route.  First, create an ACL to define the default route.

ip access-list standard DEFAULT-ONLY

 permit 0.0.0.0

Then create a route map that includes the previously created ACL.

route-map STATIC-IN permit 10

 description Redistribute local default route

 match ip address DEFAULT-ONLY

Finally, add the route map to the EIGRP redistribution

router eigrp IWAN-EIGRP

 address-family ipv4 unicast autonomous-system 400

 topology base

 redistribute static route-map STATIC-IN

 exit-af-topology

exit-address-family

 If all went according to plan then a failure in the branch internet service should remove the default route, and then EIGRP should propagate the new default route.

Security control mapping – CIS CSC Top 20, NIST CSF, and NIST 800-53

I am working on a security project with a colleague, and instead of tackling one of the bigger standards we decided to create a road map and work towards it.  Essentially, the goal is to align with NIST 800-53.  That framework is way too complex for an environment with essentially a non-existent security policy.  Instead, we will tackle the CIS Critical Security Controls (SANS Top 20, CSC, or whatever else you want to call it) first, then the NIST CyberSecurity Framework (CSF), and then tackle the NIST 800-53.

The CSC is designed with the idea that it focuses on the most critical controls, so it is the best starting point.  By layering NIST CSF we add more controls, but they are less critical.  Finally, NIST 800-53 is where we would hit a level of maturity.  The nice thing with all of these is that the frameworks do build on each other.  Controls in CSC can be mapped to the CSF and 800-53, and the controls in CSF can be mapped to 800-53.  This means that work done on one control isn’t wasted.  The issue that we had was actually understanding what that meant for the overall project.  How much mapping was actually happening?

Before getting into the answer to that question we’ll look at the controls discussed.

The CSC framework has 20 controls, NIST CSF has 98 controls, and NIST 800-53 has 256 controls.

Here are links to info about each control:

CSC Poster This shows all the controls, a bit of detail on each, the background of the CSC, and has the mapping info for other controls.

To actually get the CSC controls you have to sign up here.  There’s some good info there, which includes a file with the mapping info in Excel format, the controls in Excel, a PDF with more detail on each control, and a PDF on testing and validating an environment based on the CSC framework.

The NIST CSF info can be found here, and here’s the Excel file with the controls.  The Excel file also contains the mapping info.

Then there’s the NIST 800-53, which can be found here.

Now, a quick note: This info is based off CSC v.6, NIST CSF (I believe it’s 1.0, but I can’t find version info) and NIST 800-53 Rev. 4.

With the mapping of controls I only wanted to find unique controls that were mapped.  There are often times where multiple controls map to a single control.  I counted the first, and excluded the subsequent.  This means that controls later in the list are likely to have fewer mappings listed as they are not mapping to unique controls.  Also, just because a control is mapped does not mean it is complete.  It’s more like it is started, and will likely need to be revised when looking at the higher frameworks.

On to the fun-

If you complete the CSC then it would map to 67 of the 98 CSF Controls (68.37%)

If you complete the CSC then it would map to 114 of the 256 800-53 Controls (44.53%)

If you complete the CSF then it would map to 155 of the 256 800-53 Controls (60.55%)

If you complete the CSC, then do the CSF it would map to 193 of the 256 800-53 Controls (75.39%)

As you can see, there’s definately a benefit to working through the controls in this order.

Now, like a good student, I am going to show my work.  The attached Excel file is a list of all the mapping info.  I compiled information from the above sources to make this.  The layout is the same as I had previously used.  The first four tabs list the details of the controls that are mapped, as well as the controls that are missed.  Then there are three “Summary” tabs with the specific control data removed.

Download the mapping file.

Cisco ISR Project – Guest network config (11 of ?)

Since offering a Guest Wifi network has become a pretty standard practice it’s something that will be added to the ISRs at the branch locations.  However, since this is a guest network it is untrusted and should not have access to the internal network.

The first step is to create a VRF for the guest network.  This will prevent traffic from the guest network from ever being exposed to the routes to the internal network.

vrf defInition IWAN-Guest

    address-family ipv4

    exit-address-family

The guest machines will require DHCP, so the router will be configured to hand out IPs.  For the DHCP range the 192.168.254.0 was selected, and the IPs from 1 to 19 are excluded.  The Google DNS server at 8.8.8.8 is set as the guest DNS server.

ip dhcp excluded-address vrf IWAN-Guest 192.168.254.1 192.168.254.19

ip dhcp pool IWAN-Guest

    vrf IWAN-Guest

    network 192.168.254.0 255.255.255.0

    default-Router 192.168.254.1

    dns-server 8.8.8.8 

 Next comes the class maps for traffic filtering.  We are going to allow DHCP and ICMP between the router and the guest network, as well as allow outbound traffic.  Based on the security needs ICMP can be removed, and the protocols allowed outbound can be restricted.

class-map type inspect match-any Guest-RTR-ICMP

    match access-group name Guest-ICMP-In

class-map type inspect match-any RTR-Guest-ICMP

    match access-group name Guest-ICMP-Out

class-map type inspect match-any Guest-RTR-DHCP

    match access-group name Guest-DHCP-In

   class-map type inspect match-any RTR-Guest-DHCP

 match access-group name Guest-DHCP-Out

class-map type inspect match-any Guest-Outside-Class

    match protocol dns

    match protocol http

    match protocol https

    match protocol ftp

    match access-group name Guest-Out

The policies are configured to pass DHCP traffic and inspect everything else.

Policy-map type inspect Guest-Outside-Policy

    class type inspect Guest-Outside-Class

    inspect

    class class-default

    drop

Policy-map type inspect Guest-Self-Policy-In

    class type inspect Guest-RTR-DHCP

    pass

    class type inspect Guest-RTR-ICMP

    inspect

    class class-default

    drop

Policy-map type inspect Guest-Self-Policy-Out

    class type inspect RTR-Guest-DHCP

    pass

    class type inspect RTR-Guest-ICMP

    inspect

    class class-default

    drop

A zone will need to be created for the guest network

zone security Guest

The new zone will need to be configured to communicate with the router and internet zone, and the policies will need to be applied

zone-pair security Guest-Router source Guest destination self

    service-Policy type inspect Guest-Self-Policy-In

zone-pair security Router-Guest source self destination Guest

    service-Policy type inspect Guest-Self-Policy-Out

zone-pair security Guest-Internet source Guest destination Internet

    service-Policy type inspect Guest-Outside-Policy

 Next the guest interface will be created.  The VLAN 999 is being assigned for the guest network, and so a correlating subinterface will be created.  The IP used here needs to match the default gateway that was set earlier in the DNS settings

interface GigabitEthernet0/0/0.999

    description Guest-Network

    encapsulation dot1Q 999

    vrf forwardIng IWAN-Guest

    ip address 192.168.254.1 255.255.255.0

    ip nat inside

    zone-member security Guest

 Then a NAT statement is required to translate addresses.

ip nat inside source route-map NAT-Guest interface GigabitEthernet0/0/1 vrf IWAN-Guest overload

 A static route is needed to allow access to the outside network.

ip Route vrf IWAN-Guest 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1

A route map was used in the NAT statement to identify inside machines, so that route map needs to be created

Route-map NAT-Guest permit 10

    match ip address Guest-Internet

    match interface GigabitEthernet0/0/1

Lastly, we will create the ACLs.  Again, these ACLs can be adjusted to restrict traffic as needed.

ip access-list extended Guest-DHCP-In

    permit udp any eq bootpc any eq bootps

!

ip access-list extended Guest-DHCP-Out

    permit udp any eq bootps any eq bootpc

!

ip access-list extended Guest-ICMP-In

    permit icmp any any echo

    permit icmp any any echo-reply

!

ip access-list extended Guest-ICMP-Out

    permit icmp any any echo

    permit icmp any any echo-reply

!

ip access-list extended Guest-Internet

    deny ip 192.168.254.0 0.0.0.255 192.168.0.0 0.0.255.255

    deny ip 192.168.254.0 0.0.0.255 172.16.0.0 0.15.255.255

    deny ip 192.168.254.0 0.0.0.255 10.0.0.0 0.255.255.255

    permit ip 192.168.254.0 0.0.0.255 any

!

ip access-list extended Guest-Out

    permit ip 192.168.254.0 0.0.0.255 any

Now all that is needed is to assign the Guest SSID to VLAN 999 and configure switch ports accordingly.

Cisco ISR Project – NAT rules (10 of ?)

With the traffic rules in place next will come getting NAT rules set up.  In a nutshell Network Address Translation (NAT) is what converts internal IPs to public IPs, which allows internal machines to communicate on the internet.

With the IWAN design part of what I want to accomplish is to allow any internal site to be able to route through to another site in the event of an ISP failure.  To accomplish this the scope of the NAT rules will be expanded to cover all private IP ranges.  Getting NAT set up is pretty simple, though there are a number of steps.

  1. Define inside and outside interfaces
  2. Create ACL to define source machines
  3. Create route map for source machines
  4. Create NAT statement
  5. Create an ACL for traffic destined for inside
  6. Create route map to route traffic from internet to inside
  7. Apply the route map to the outside interface
  8. Create default route outbound

The NAT config will all be done via CLI, and it will all be from a config prompt.

The NAT inside interface would be the interface connected to the private side of your network, and the outside would be facing the public interface.  This is where the address translation will be taking place.  The interfaces in red may need to be modified to match your deployment.

int gi0/0/0  ip nat inside

 int gi0/0/1   ip nat outside

The next step is creating the ACL to define all inside networks.  Adjust this as needed.

ip access-list extended Inside_IPs

    permit ip 10.0.0.0 0.255.255.255 any

    permit ip 172.16.0.0 0.15.255.255 any

    permit ip 192.168.0.0 0.0.255.255 any

Then a route map is created with the previous ACL and the interface being used.

route-map NAT-Inside permit 10

    match ip address Inside_IPs

    match interface GigabitEthernet0/0/1

 Next would be NAT statement.  In it we specify that traffic from the inside interface that matches the route map is translated to the outside interface (and uses the IP of that interface), and “overload” means that it will be a many-to-one NAT.  Since it is many-to-one we are allowing multiple inside machines to use the single outside IP, and the router tracks the traffic by altering the source port and matching the return traffic.

ip nat inside source route-map NAT-Inside interface GigabitEthernet0/0/1 overload

That concludes the actual NAT portion, but without the related routing it really doesn’t help.  So there are two routes that are needed.  One to get the traffic out and the other to get traffic back in.  We’ll start with the return traffic. First we need a ACL to define the traffic coming back in.

ip access-list extended InternalNetworks

    permit ip any 10.0.0.0 0.255.255.255

    permit ip any 172.16.0.0 0.15.255.255

    permit ip any 192.168.0.0 0.0.255.255

Then we create a route map for it.

route-map Internet-Internal permit 10

    description Return routing for Local Internet Access

    match ip address InternalNetworks

    set global

That route map is then applied to our external interface

interface GigabitEthernet0/0/1

     ip policy route-map Internet-Internal

The last step is to create the default route from the inside to get to the outside.

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 Next_Hop_IP

Now internal machines should have internet access.  Here are a few commands that help with troubleshooting if there are issues:

show ip nat translation (shows current NAT translations)

clear ip nat translation * (clears all current translations, which is helpful if the NAT statement needs to be changed.)

Cisco ISR Project – Router access rules (9 of ?)

Now that most connectivity has been configured the next step will be creating access rules to restrict access as needed, as well as grant access where needed.  This is going to primarily apply to the branch routers, but the HQ routers can (and should) be configured similarly.

Before we get into what that means let’s cover how this is going to work.

Much to my chagrin, gone are the days of the “permit any any established” rules.  Those have been replaced with packet inspection to perform the stateful firewall feature.  What this means is that inbound packets are inspected to see if they match an existing outbound flow.  If the traffic is part of an established flow then it is allowed.  If not, then it’s dropped.

This gets a bit more complicated with the addition of the Zone-based Firewall (ZBF) in the ISR.  Instead of applying rules to the interface they are applied to the zone pairs.

Here’s the high level flow.

  1. Class maps are created (and specify ACLs as needed)
  2. Policy maps are created (and specify class maps as needed)
  3. Security zones are created
  4. Zone pairs are created, with source and destination specified, then the policy map is applied
  5. Interfaces are assigned to security zones
  6. ACLs are created for traffic definitions

Maybe a diagram will help.  This diagram shows the commands needed to allow traffic to flow from the inside IP range of 10.0.0.0/8 from the inside interface Gi0/0/0 to any IP on the outside interface Gi0/0/1.  Lines in red are the commands.

Access Control

For the ISR deployment there are a number of rules that we need to allow for the creation of VPN tunnels on the external interfaces.  Now, let’s get to what the basic config will look like.

This is all CLI commands, so you will need to be at a config prompt.  The first command is simply logging packets that are dropped by the policies.

parameter-map type inspect global

 log dropped-packets

The next step will be class maps.  There are five maps, inside to outisde, and then both pass and inspect traffic between the outside and the router.

class-map type inspect match-any Inside-Outside-Class

    match protocol ftp

    match protocol icmp

    match protocol udp

    match protocol tcp

class-map type inspect match-any Inspect-ACL-Out-Class

    match access-group name ACL-RTR-Out

class-map type inspect match-any PASS-ACL-In-Class

    match access-group name ESP-In

    match access-group name GRE-In

class-map type inspect match-any PASS-ACL-Out-Class

    match access-group name ESP-Out

class-map type inspect match-any Inspect-ACL-In-Class

    match access-group name ACL-RTR-In

Next comes the policy maps.  These are the policies that specify the classes that were just created.

Policy-map type inspect Inside-Outside-Policy

    class type inspect Inside-Outside-Class

    inspect

    class class-default

    drop

Policy-map type inspect ACL-In-Policy

    class type inspect Inspect-ACL-In-Class

    inspect

    class type inspect PASS-ACL-In-Class

    pass

    class class-default

    drop

Policy-map type inspect ACL-Out-Policy

    class type inspect Inspect-ACL-Out-Class

    inspect

    class type inspect PASS-ACL-Out-Class

    pass

    class class-default

    drop

By looking at the policies it’s easy to see that we will be passing inbound ESP and GRE traffic (the ACLs will follow), as well as outbound ESP traffic.  Everything else that is allowed through the ACLs will be inspected.

The next step will be to create the security zones for the ZBF.

zone security Internet

zone security MPLS

zone security default

For now we are just creating a zone for each connection type.  More zones will be added later as the config is built out.

Now that the zones are created we create zone pairs, which link a source and destination zone and apply one of the policies that were created to the traffic between those zones.  One thing to be aware of is the router itself uses the “Self” zone.  That means that traffic to the router will use the “Self” zone, so we can use that in the zone pairs.

zone-pair security Router-Internet source self destination Internet

    service-Policy type inspect ACL-Out-Policy

zone-pair security Router-MPLS source self destination MPLS

    service-Policy type inspect ACL-Out-Policy

zone-pair security Inside-Internet source default destination Internet

    service-Policy type inspect Inside-Outside-Policy

zone-pair security Inside-MPLS source default destination MPLS

    service-Policy type inspect Inside-Outside-Policy

zone-pair security Internet-Router source Internet destination self

    service-Policy type inspect ACL-In-Policy

zone-pair security MPLS-Router source MPLS destination self

    service-Policy type inspect ACL-In-Policy

The next step is to associate the interfaces with the corresponding security zones.  Since there are only two actual zones (Internet and MPLS) this is pretty straightforward.  All the other interfaces are using the default zone for now.  Replace the interface in red with the correct interface for your deployment.

int gi0/0/1

    zone-member security Internet

int gi0/0/2

    zone-member security MPLS

Now the only thing left to do would be to create the ACLs.  The ACLs here are based off a Cisco IWAN document.  There are a number of areas where they can be tweaked.  The obvious change would be disabling ICMP if that is a requirement for your environment.  Another change would be to put in specific addresses instead of “any” for the VPN related rules.  I would strongly recommend making at least the inbound rules more restrictive.

ip access-list extended ACL-RTR-In

    permit udp any any eq non500-isakmp

    permit udp any any eq isakmp

    permit icmp any any echo

    permit icmp any any echo-reply

    permit icmp any any ttl-exceeded

    permit icmp any any port-unreachable

    permit udp any any gt 1023 ttl eq 1

ip access-list extended ACL-RTR-Out

    permit udp any any eq non500-isakmp

    permit udp any any eq isakmp

    permit icmp any any

    permit tcp any any eq 8080

    permit udp any any eq domain

ip access-list extended ESP-In

    permit esp any any

ip access-list extended ESP-Out

    permit esp any any

ip access-list extended GRE-In

    permit gre any any

Now that these rules are in place the routers should still establish the VPN tunnels, and traffic from the outside world should be restricted.