The most popular solution today is to use some sort of interception caching mechanism such as WCCP. Now WCCP is a Cisco protocol that has been more or less adopted by many other vendors even though the name is different foundry supports this protocol in their layer 4 switches, juniper supports it although under a different name, as well as HP switch and router products. The way WCCP works is to grab packets matching either an access-list or the built in web-cache group and forward those packets to the proxy, their by intercepting the packets as they reach the routed interface upstream from the end user. Now Cisco routers do this by creating a one-way GRE tunnel while Cisco switches perform this by using L2 redirects. If you are configuring WCCP on a Catalyst 6500 switch you have a choice of using L2 redirects or GRE tunnels.

The second most popular way to insure inform proxy setting across an enterprise is to use WPAD or (Web Proxy Auto Discovery Protocol) . Wpad works by writing a small JavaScript function in a text file, which tells the browser the proxy settings and what domains or subnets are excluded from the proxy such as local settings. Once you create your text file you save it to a web server on the local LAN in the root directory. An example would be http://webserver.mycompany.com/wpad.dat .

An example of the contents of the above file are as follows:

function FindProxyForURL(url, host) {
// our local URLs from the domains below example.com don't need a proxy:
if (shExpMatch(url,"*.techinvasion.local/*"))   {return "DIRECT";}
// URLs within this network are accessed through
// port 8080 on fastproxy.example.com:
if (isInNet(host, "10.0.0.0",  "255.255.255.0"))    {
return "PROXY proxy.techinvasion.local:3128";
 }
// All other requests go through port 3128 of proxy.example.com.
// should that fail to respond, go directly to the WWW:
return "PROXY proxy.techinvasion.local:3128; DIRECT";
}

The next step would be to add option 252 to the dhcp scope with an ASCII text entry of the web server path to the wpad.dat file as listed above. On a Cisco router with DHCP the entry would look like the following:

ip dhcp pool lan
     network 10.0.0.0 255.255.255.0
     update dns both
     domain-name techinvasion.local
     default-router 10.0.0.254
     dns-server 10.0.0.9 10.0.0.2
     option 252 ascii "http://stats.techinvasion.local/proxy.pac"
     lease infinite
 !

After this is done you should be in business. The only problem with this approach is that if you do not have active directory to force enable automatic proxy detection in internet explorer you really have no way to force users to look for this pac file. This can create uniformity problems and generate more calls to the help desk.

The final way we can configure the proxy is to use route-maps to redirect all web traffic to the proxy. The only problem with this approach is that if for some reason the proxy Is to go down the route-map will be directing traffic to a black hole! To remedy this we can use the IP-SLA feature to monitor the proxy and deactivate the route-map if the proxy is unavailable.

Now some things to remember, the route-map is only sending the traffic on port 80 to the proxy on port 80, if your proxy runs on a different port you will need to do a port redirect using ipfilter on FreeBSD based proxies, or ipchains on Linux based proxies to change the traffic to the correct port. Ok let get started with our configuration.

Step one create a http monitor that will use your proxy to pull an outside site like yahoo.com.

ip sla monitor 1
 type http operation get url http://www.yahoo.com name-server 10.0.0.9 proxy http://10.0.0.8/
 timeout 5000
!
ip sla monitor schedule 1 start-time now

The above code polls yahoo.com every 60 seconds to verify that the proxy server is working. Once you have that turned on you can issue the following commands to test it.

#sh ip sla monitor statistics 1
Round trip time (RTT)            Index 1
            Latest RTT: 266 ms
Latest operation start time: 04:19:13.020 edt Mon Jul 13 2009
Latest operation return code: OK
Latest DNS RTT: 0 ms
Latest TCP Connection RTT: 18 ms
Latest HTTP Transaction RTT: 248 ms
Number of successes: 55
Number of failures: 5
Operation time to live: 0

If you see:
Last operation return code: OK

Then that means everything is ok, it will say timeout if the proxy is down. Now I do the proxy test on port 80 because I want to verify that the ipchains port redirection rule is working as well, however you could specify a different port such as 3128 or 8080 if you wanted to.

The next step is to build the route-map and the track object. The track object is what the route map references to check availability of the next hop, in this case the next hop is the proxy. You setup as track object as follows.

Track option1 option2 option3

Option 1
(<1-500 > Tracked object)

Option 2
(interface Select an interface to track)
(ip IP protocol)
(list Group objects in a list)
(rtr Response Time Reporter (RTR) entry)

Option 3
(<1-2147483647> Entry number) ß this refers to the monitor number in the IP SLA command

In our case we want a response time reporter because we are interested in up/down information about the proxy.

track 1 rtr 1

Now we need to build and apply the route-map. First we need to build an access-list to specify the interesting traffic the route-map will be forwarding.

ip access-list extended proxy
10 deny ip host 10.0.0.8 any
! Block proxy traffic, we do not want to create a routing loop.
20 permit tcp 10.0.0.0 0.0.0.255 any eq 80

Here is the appropriate route-map below

route-map proxy permit 10
 match ip address proxy
 set ip next-hop verify-availability 10.0.0.8 1 track 1

To test this we can issue the command

#show route-map proxy
route-map proxy, permit, sequence 10
  Match clauses:
    ip address (access-lists): proxy
  Set clauses:
    ip next-hop verify-availability 10.0.0.8 1 track 1  [up]
  Policy routing matches: 41673 packets, 6145267 bytes

You will notice the “UP” this means that it sees our track object and it is getting th response time code from the ip sla monitor that we setup.

Juniper is also big on naming things, in JUNOS everything has a name, the Filter Lists have names, the terms in the Filter Lists have names, and even the address’s you are matching on have names. This is a big concept in JUNOS because it allows you to write snippets of Filter-Lists and use them for many different Filter Lists. JUNOS also supports grouping Filter Lists and applying an entire group of filter to an interface. If you apply Filter groups to a JUNOS interface they individual Filter Lists are evaluated in order sequentially.

To facilitate out discussion of Filter-Lists let’s take a look at a standard anti-spoofing access list which would be applied to most edge routers. First let’s talk about what a vanilla anti-spoofing ACL should contain! A standard ACL at a minimum should block all RFC-1918 address space from the internet, it should also block undesirable types of ICMP traffic, and depending on the setup should block packets with illegal combinations of TCP flags set, for example packets with the SYN-FIN flag set at the same time or FIN-URG-PSH or URG-ACK-PSH-RST-SYN-FIN at the same time. All of these combinations of TCP flags are illegal and should never be together as part of a legitimate packet. So without further ado lets talk about Filter Lists.
Filter Lists are defined under the Firewall section of the JUNOS configuration. Prefix Lists which are groups of networks, IP address ranges, or single hosts such as 1.1.1.1/32 are defined in these lists. These lists can later be used in as many Filter Lists as you define.

Below I will show you the actual Filter Lists as it looks in the configuration and some of the commands to create the list. For brevity I have opted to only show some of the commands used in creating the list as they are basically repetitive. The important thing to remember is that like all Access-Lists the terms in the Filter List are evaluated from top to bottom so it is important that the last term be an allow all statement otherwise the anti-spoofing filter will block all communication even legitimate communication.

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 192.168.0.0/16

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 172.16.0.0/12

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 10.0.0.0/8

[edit]
john# edit firewall

[edit firewall]
john# edit filter anti-spoofing

[edit firewall filter anti-spoofing]
john# edit term block-rfc1918

[edit firewall filter anti-spoofing term block-rfc1918]
john# set from source-prefix-list rfc1918-prefix-list

[edit firewall filter anti-spoofing term block-rfc1918]
john# set then log discard

[edit]
john# show policy-options

prefix-list rfc1918-prefix-list {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
}

[edit firewall]
john# show

filter anti-spoofing {
    term block-rfc1918 {
        from {
            source-prefix-list {
                rfc1918-prefix-list; ## 'rfc1918-prefix-list' is not defined
            }
        }
        then {
            log;
            discard;
        }
    }
    term block-fin-urg-psh {
        from {
            protocol tcp;
            tcp-flags fin,psh,urg;
        }
        then {
            log;
            discard;
        }
    }
    term block-syn-fin {
        from {
            protocol tcp;
            tcp-flags fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-urg-ack-syn-fin-rst-psh {
        from {
            protocol tcp;
            tcp-flags urg,ack,psh,rst,fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-icmp {
        from {
            protocol icmp;
            icmp-type-except echo-reply,unreachable,source-quench,time-exceeded;
        }
        then {
            log;
            discard;
        }
    }
    term accept-all {
        then accept;
    }
}

Remember to apply the Filter-List to the interface with the following command:

[edit]
john#set interfaces fe-0/0/0.0 family inet filter input anti-spoofing

Here is a related Article on ACL’s

Cisco routers have a very robust network address translation feature set. The NAT software allows you to control translation with access-list, route-maps, and destination pools. With the wide array of commands, it is sometimes difficult for beginners and experts to figure out how to combine these elements to solve a problem.

I have a small network at home for the computers in my house, and I find that some of the strangest configurations and explorations come about because I try to solve problems in a way that is cost affective with the limited broadband available to consumers. I recently purchased a CheckPoint UTM firewall appliance to add to my network. CheckPoint invented the stateful firewall and has one of the best firewalls in the market. I wanted to add this firewall to my network but I faced 2 main problems.

1. The first problem is that my ISP only offers 1 static IP, and my router connects with a WIC1-ADSL card.
2. The second problem Is that my router is also a call manager express server and therefore needs to be able to receive traffic destined for the router itself.

Notice that the outside interface of the firewall has a private IP address. This is a necessity because my ISP only offers 1 static IP and it must be assigned to the router. This is a problem if I leave my router configured the way it was with port overloading enabled, all the traffic not specifically forwarded via the router will be dropped at the Cisco which renders the inside firewall useless.

      So the first thing I did was to change the following configuration from port overloading to static NAT

Original Configuration

ip nat inside source list 10 interface dialer1 overload

access-list 10 permit ip 10.11.0.0 0.0.0.255
access-list 10 permit ip 192.168.10.0 0.0.0.255

New Test Configuration

ip nat inside source static 10.11.0.1 interface dialer1

     The problem with the above configuration is that it forwards all packets to the firewall. This means that packets from my VOIP provider destined for the call manager software on the router itself were being forwarded to the firewall. This is a big problem and one that stumped me for a while. In order to fix this problem I decided to use “Destination Lists.” Destination Lists allow the router to evaluate incoming connections based on an access-list and translate the packets matching the criteria to hosts in a specific pool.

     The interesting thing about this technique is that you can have as many pools and destination lists as you want, which means that you can use this technique to translate ranges of ports to different hosts. I know many newbies to Cisco routers look for a port range forwarding mechanism similar to what is available on consumer home gateways and routers like those from D-Link and Linksys. The following configuration allows all ports and protocols to be forwarded to the firewall except for any traffic from the VOIP provider.

ip host sip.broadvoice.com 98.98.200.12
!
!
ip nat inside source list 10 interface Dialer1 overload
!
ip nat pool nonvoip 10.11.0.1 10.11.0.1 netmask 255.255.255.0 type rotary
!
ip nat inside destination list 101 pool nonvoip
!
!
      access-list 10 permit ip 10.11.0.0 0.0.0.255
      access-list 10 permit ip 192.168.10.0 0.0.0.255
      !
      Access-list 101 deny ip host 98.98.200.12 any
      Access-lsit 101 permit ip any any

Lets take the above from the beginning.

The first line above code, hard codes the ip address of the Broadvoice server.

The second line configures the NAT for port address translation just like a normal PAT configuration.

The next line creates a rotary pool called nonvoip with the ip address of  the outside firewall as the only IP address in the pool.

The 4th line in the configuration tells the router to check access-list 101 and translate packets that match that access-list to the rotary pool nonvoip.

Access-list 10 is used to PAT the VOIP network And the 10.11.0.0 network which is used for the external interface on the firewall. Access-list 10 is required for nat to function.

Access-list 101 tells the router to exclude all traffic from the NAT process, but send every other protocol and port to the outside interface of the checkpoint firewall.

The above configuration can also be easily modified to forward port ranges to different hosts on the network. Once you figure out that you can have as many destination pools as you want with as many access-lists as you want the combination of port forwarding options becomes almost endless. For instance the above can be modified as follows to forward a range of ports to two different hosts.

ip nat inside source list 10 interface Dialer1 overload
!
ip nat pool groupA 10.11.0.1 10.11.0.1 netmask 255.255.255.0 type rotary
!
ip nat pool groupB 10.11.0.2 10.11.0.2 netmask 255.255.255.0 type rotary
!
ip nat inside destination list 101 pool groupA
!
ip nat inside destination list 101 pool groupB

!
      access-list 10 permit ip 10.11.0.0 0.0.0.255
      !
      Access-lsit 101 permit tcp any any range 8000 9400
      !
       Access-list 102 permit tcp any any range 50 1024

#ip access-list extended  (name goes here)

The neat thing about named access-lists is that when you do a show access-list command you see number s next to the lines in the acl. This allows you to add or remove lines without deleting the whole access-list.

test#sh ip access-list

extended ip access-list example
	10 permit ip any any
	20 deny tcp any any eq 80
	30 permit udp any any eq 53

Reflexive access-lists allow you to filter connections based on session. Reflexive ACL’s are part of the ip plus feature set and was the first attempt to create a statefull inspection firewall on routers. Before the invention of reflexive access-lists the only way we had to allow stateful return traffic from the internet was by using the establish keyword. The problem with the established keyword is that the router only checks for the ack bit on the packets. The ack bit is set on packets once the 3 way handshake has been completed. the problem with this is that it does not do anything for udp packets since those connections are stateless, and it is very easy for hackers to set the ack bit. To get around this problem Cisco invented the reflexive access-list.

permit tcp any any eq 80 established

Reflexive access-lists are very easy. I have added the code for the access-list below. Basically reflexive access-list are made up of two parts. The first part, is the access-list that filters outbound traffic. This access-list is made up of statements that allow outbound traffic. thekey part here is the reflect statement. What this means is that you want to reflect that packet in another access list.

In my example below I reflected the statements in an access-list called dynamic. Now I created two access-lists. I created an inbound access-list to allow static inbound traffic to my webserver. I created an outbound access-list to allow traffic from my lan to the internet. I told my inbound access-list to check the reflexive entries before blocking traffic using the evaluate command. This is all there is too it. With these simple commands you can commands you can configure a statefull firewall to protect your network from harm. As good as this is though it isn’t perfect. It doesn’t work for application which use dynamic port numbers for return traffic. To solve this problem cisco added layer 4 inspection and refined reflexive access-lists in what they call Content Based Access Control or CBAC. However CBAC is part of the ios fw feature set and is a topic for another time.

interface FastEthernet0/0
 description WAN Interface
 ip address 192.168.0.1 255.255.255.0
 ip access-group internet_in in
 ip access-group lan_out out
 duplex auto
 speed auto
!
!
ip access-list extended internet_in
 remark Internet---->lan traffic
 permit tcp any any eq 80
 permit tcp any any eq 443
 evaluate dynamic
!
!
ip access-list extended lan_out
 remark inside----->internet traffic
 permit tcp any any eq www reflect dynamic
 permit tcp any any eq 443 reflect dynamic
 permit tcp any any eq 22 reflect dynamic
 permit tcp any any eq ftp reflect dynamic
 permit tcp any any eq telnet reflect dynamic
 permit tcp any any eq pop3 reflect dynamic
 permit tcp any any eq nntp reflect dynamic
 permit tcp any any eq smtp reflect dynamic
!
!

Access-lists are used to match traffic and can be applied in either the in or out direction. It is important to note that the direction is from the perspective of the interface. For instance on a switch port “IN” would be coming into the switch or traffic being sent to the switch, whereas “OUT” would be the traffic the switch sends to the device connected to the port. So think of it like this:  OUT means traffic flowing out of the switch, while IN means traffic flowing into the switch. See I knew you would get it, it’s very easy stuff.

There are two basic kinds of access-lists extended and standard. Access-lists over 100 inclusive are extended access lists, while access-lists numbered 99 and less are standard access-lists. Standard access lists can only filter based on ip address, while extended access-lists can filter based on layer 3 protocols such as tcp, udp, gre, and others. They can also filter based on tcp/udp port numbers. Lets take a look at an access list :

access-list 1 permit any any
access-list 2 permit host 127.0.0.1 0.0.0.255  any
access-list 3 deny 10.0.0.0 0.0.0.254  any
access-list (1-99) (permit/deny) (source) (destination)

All of these are standard access-lists, let’s take them apart in detail. The first part is the command “access-list” this is followed by either a “permit/deny” the next entry is the source and can be “any”, it can be a individual ip “host x.x.x.x” or it can be a network “192.168.1.0 0.0.0.255” The last part is a wild card mask which is the opposite of a subnet mask. Remember that standard access-lists can only filter based on source and or destination, but not any other information. If you want to filter on more than source and destination you can choose extended access-lists. Extended access-lists can filter on much more and take a slightly different format.

Access-list 101 permit tcp any any eq 443
Access-list 101 deny udp any any eq 500
Access-list 101 permit gre any any

Lets have a look at some of the possible options that the Cisco IOS gives you to match packets, if you don’t understand all of the options or know how to use them at first, don’t worry. These kind of things look useless or seldom used at first, however as you progress you will make use of most of these options.

#access-list 102 ?

  deny              Specify packets to reject
  dynamic       Specify a DYNAMIC list of PERMITs or DENYs
  permit          Specify packets to forward
  remark        Access list entry comment

!

#access-list 102 permit ?

  <0-255>  An IP protocol number
  ahp      Authentication Header Protocol
  eigrp    Cisco's EIGRP routing protocol
  esp      Encapsulation Security Payload
  gre      Cisco's GRE tunneling
  icmp     Internet Control Message Protocol
  igmp     Internet Gateway Message Protocol
  ip       Any Internet Protocol
  ipinip   IP in IP tunneling
  nos      KA9Q NOS compatible IP over IP tunneling
  ospf     OSPF routing protocol
  pcp      Payload Compression Protocol
  pim      Protocol Independent Multicast
  tcp      Transmission Control Protocol
  udp      User Datagram Protocol

!

#access-list 102 permit tcp any any ?

  ack          Match on the ACK bit
  dscp         Match packets with given dscp value
  eq           Match only packets on a given port number
  established  Match established connections
  fin          Match on the FIN bit
  fragments    Check non-initial fragments
  gt           Match only packets with a greater port number
  log          Log matches against this entry
  log-input    Log matches against this entry, including input interface
  lt           Match only packets with a lower port number
  neq          Match only packets not on a given port number
  option       Match packets with given IP Options value
  precedence   Match packets with given precedence value
  psh          Match on the PSH bit
  range        Match only packets in the range of port numbers
  rst          Match on the RST bit
  syn          Match on the SYN bit
  time-range   Specify a time-range
  tos          Match packets with given TOS value
  urg          Match on the URG bit
  

!

#access-list 102 permit tcp any any eq 80 ?

  ack          Match on the ACK bit
  dscp         Match packets with given dscp value
  established  Match established connections
  fin          Match on the FIN bit
  log          Log matches against this entry
  log-input    Log matches against this entry, including input interface
  option       Match packets with given IP Options value
  precedence   Match packets with given precedence value
  psh          Match on the PSH bit
  rst          Match on the RST bit
  syn          Match on the SYN bit
  time-range   Specify a time-range
  tos          Match packets with given TOS value
  urg          Match on the URG bit
  

!

This has been a brief intro to access lists. In the next Installment we will talk a little bit about named access-lists and how they can be used to construct reflexive access lists. Reflexive access-lists can be used to create dynamic entries in an access-list based on some event or matching criteria, and can be really important tool for securing a network. Also named access-lists allow you to easily manage a large access-list more easily by allowing you to change an entry or change the order of the acl without rewriting removing and rewriting the entire access-list.

One last thing…. Access-lists are applied to an interface by using the following command:

#Config t
(config )# Int fastethernet 0/1
(Config int)# Ip access-group in
Or
(Config int)# Ip access-group out

!
crypto isakmp policy 10        #create crypto policy file
authentication pre-share      #use pre shared key
crypto isakmp key integer address 192.168.1.2 #address of remote tunnel
!
!
!
#use aes encryption and comp-lzs conpression. use transport mode.
crypto ipsec transform-set myset esp-aes esp-md5-hmac comp-lzs
!
mode transport   # transport mode tells IPSEC not to create a tunnel,
                       # this is used when you are using IPSEC for
                       # encryption only and not for tunneling.
!
crypto map mymap 10 ipsec-isakmp   # create the crypto map
set peer 192.168.1.2                      # the peer must match the ISAKMP statement
set transform-set myset                  # use the encyption we defined above
match address match-gre                # encrypt only packets in GRE tunnel
!
!
!
!
interface Tunnel0
ip address 172.20.1.1 255.255.255.252
keepalive 10 3
tunnel source FastEthernet0/0
tunnel destination 192.168.1.2
tunnel path-mtu-discovery
crypto map mymap              # crypto map must be applied to tunnel
!
!
!
!
interface FastEthernet0/1
description LAN INTERFACE
ip address 10.0.0.254 255.255.255.0
ip nat inside
duplex auto
speed auto
!
!
!
!
interface FastEthernet0/0
description Internet Interface
ip address 192.168.1.1 255.255.255.0
ip access-group allow-gre in
ip nat inside
duplex auto
speed auto
crypto map mymap   # crypto map must be applied to tunnel and public interface
!
!
!
!
ip access-list extended allow-gre
permit gre any any               # allow gre through the firewall
permit esp any any              #allow esp for ipsec through the firewall
permit udp any any eq 500    #allow udp port 500 through which ipsec also uses
!
!
#access-list to match tunnel traffic.
#This access list must be in the form (my public ip) (destination public ip)
ip access-list extended match-gre
 permit gre host 192.168.1.1 host 192.168.1.2 log

Each type of connectivity offers advantages and disadvantages. Some of these tunnels can even be overlaid on top of one another. For instance IPSEC can be used in a transport mode, which allows you to use the encryption with other tunnels or protocols. For this article we are going to discuss GRE tunnels. GRE is unique as tunneling technologies go in that is started out as a proprietary protocol developed by Cisco and later adopted as a standard. GRE was invented as a way of encapsulating non routable protocols in IP which is a routable protocol. In this way protocols such as multicast (this include OSPF, EIGRP), and other protocols like IPX could be tunneled across routable links.

GRE offers several advantages today when used as a tunnel to connect private LANs. The main advantages are the ability to carry multicast traffic, i.e. routing protocols across the internet. For instance, lets say you had a main office in London, which has Frame Relay links to 15 offices in Europe, and you have your headquarters in Washington D.C. with a MPLS network of 25 offices across North and South America. Now suppose due to the costs of bandwidth and particularly the cost of private connection such as frame across the pond, you decided to go with a 45mbps T3 line. Between London and D.C.  Now you could connect these offices with an IPSEC VPN however if you did this you would be limited to building static  routes for each network on each side of the ocean, this is not a very scalable solution and does not allow you the advantages of a dynamic routing protocol. This solution may even limit you should you decide to add a second T3 later say to an office in Madrid. With dynamic routing protocols, the traffic would automatically swing to the Madrid office if something were to happen to the link between D.C. and London. The solution  to this problem is to use GRE tunnels, since GRE tunnels pass all types of traffic you can easily run a dynamic routing protocol, like OSPF or EIGRP. These protocols will allow seamless easy route adjustments when a route goes down.

Configuring GRE tunnels is easy with a few simple steps you will be on your way. Before we can talk about configuring GRE tunnels we need to discuss exactly what the requirements for GRE are! GRE is a protocol, like IP you need to make sure this protocol is allowed through your firewall if you want to terminate a GRE tunnel. GRE to be more exact is protocol 47. Please be mindful that this is not port 47 but protocol 47. Allowing port 47 through your firewall will not allow GRE to work.

Steps to configure a GRE tunnel

1. create access-list on outside interface to permit GRE
2. create tunnel interface

interface Tunnel0
 ip address 172.20.1.1 255.255.255.252
 keepalive 10 3
 tunnel source FastEthernet0/0
 tunnel destination 192.168.1.2
 tunnel path-mtu-discovery
!
!
!
!
interface FastEthernet0/1
 description LAN INTERFACE
 ip address 10.0.0.254 255.255.255.0
 ip nat inside
 duplex auto
 speed auto
!
!
!
!
interface FastEthernet0/0
 description Internet Interface
 ip address 192.168.1.1 255.255.255.0
 ip access-group allow-gre in
 ip nat inside
 duplex auto
 speed auto
!
!
!
!
ip access-list extended allow-gre
 permit gre any any

Switch# test cable-diagnostics tdr interface gigabitethernet0/2
TDR test started on interface Gi0/2

A TDR test can take a few seconds to run on an interface. Use "show cable-diagnostics tdr" to read the TDR results.

Switch#show cable-diagnostics tdr interface gigabitEthernet 0/2
TDR test last run on: Dec 10 09:05:10

         Interface Speed Local pair Pair length Remote pair Pair status
         --------- ------ ---------- ------------ ------------ ----------
         Gi0/2 auto Pair A   22 +/- 4 m N/A Open
           Pair B    21 +/- 4 m N/A Open
           Pair C    5 +/- 4 m N/A Open
           Pair D    20 +/- 4 m N/A Open

A lot of engineers prefer to use dedicated systems for network security such as Pix and ASA devices. However the Cisco recommended methodology is to filter packets as close to the egress point as possible thus saving network resources and enhancing security. In times past it was considered better to apply security features on dedicated devices deeper in the network while putting as few strains on the edge routers as possible. This methodology used to be a necessity as routers typically had much less horse power and a significant amount of CPU cycles and memory was used just routing and switching packets, add to that the wide spread use of Port address translation which requires a large amount of CPU cycles and memory to maintain the port translation state table and the situation was dire. It was not uncommon to see a branch office level router such as a 2500, or 2600 series overloaded by P2P programs which open up thousands of ports for connections. In these situations a single user could easily destabilize the network and cause the router to drop packets from the load. Cisco realizing the changing world of networking and the relative cheapness of CPU power released the XM series routers as a stopgap measure until the new integrated services platform routers were available such as the 2800 and 3800 series routers. These new routers are more powerful than ever and allow IPS, stateful firewall features, and deep packet inspection to be performed at the network edge thus enhancing security and availability of network resources.

Besides the IPS features the Cisco routers can also perform CBAC or Content Based Access Control. With CBAC the router can inspect TCP, UDP, and ICMP packets for fragments and irregularities. The IOS can also inspect sever layer 7 protocols, and with the latest 12.4 IOS and current generation of routers this list has expanded to many many layer 7 protocols. When using CBAC the router monitors the outgoing packets on an interface, and dynamically creates holes in the inbound access list to allow only packets that match up to the outgoing request. This means that CBAC enables the IOS to perform true stateful Firewalling.  In the 12.4 IOS CBAC uses deep packet inspection to determine the true protocol of the packet and better protect the network from intrusion. With deep packet inspection the router will recognize an FTP packet and scan it for known issues even if the packet arrives on a port other than the standard FTP control port. The IOS also uses access lists to secure interfaces and drop unwanted traffic at the network edge which will prevent network resources from being wasted.

I hope this brief overview of the Cisco IOS security methodology as it relates to packet filtering was informative. I will follow up later with a more technical article on how to configure CBAC stateful firewalling, and IPS signatures on the Cisco router.