Most enterprise engineers MPLS experience goes something like this: The company needs to connect the office in Miami and the office in London with the corporate headquarters office in Chicago. The VPN design needs to be flexible, and most importantly the network connecting all 3 sites needs to be full mesh. By this I mean to say that any office should be able to talk to any other office using this MPLS VPN. At this point you contact your MPLS provider and ask them to provision 3 MPLS links, 1 for each of the above mentioned offices. The MPLS Sales team puts you in contact with their engineering department and they ask you a couple questions that they need answered in order to properly provision your lines. the number one question that they ask is “How do you want to send us routes?”  now depending on the size of your organization and the dynamic or static nature of your network you can opt for several options here are 3 of the most common.

1. Static Routes

2. BGP Peering

3. OSPF Peering

Now if your network is very small, say for instance you have 3 shoe stores that need to talk to the corporate office / warehouse, then you might opt for the static route option. If you are a large organization that is publicly traded and has a robust network and security policy in place you will most likely choose the second option as this gives you the most security and control over what routes enter and leave your network.  However the third option is also very popular, mainly because many organizations are already running OSPF, so this makes it that much easier to peer with the ISP. However using the same IGP to peer with your MPLS provider as you use to run your internal networks does leave you at risk. There are a host of vulnerabilities OSPF has that could be exploited even if you are using OSPF MD5 authentication such as LSA injection attacks. However the biggest reason not to do this is that if the ISP makes a mistake they could inadvertently dump hundred or thousands of routes into your routing table which could destabilize your entire network.

Now wouldn’t you know after all that negative talk about ospf peering. The example I am going to talk about below is exactly that OSPF peering.

Please click on the above diagram for a larger view, you may want to download it as well and open it in a image view to zoom in on some of the smaller text and details.

In the example above you have 2 companies. To keep things simple we will call them Company A and Company B. Company A has 2 sites that need to communicate using MPLS, Company B also has 2 sites that need to communicate using MPLS. This ISP is lucky enough to get the business for both Company A and Company B. The ISP has a core network made up of an unspecified number of routers. In this example we will look at a small portion of the companies network. Our little piece of the network shows both customer sites connected to PE routers or (Provider edge) routers. These routers are responsible for providing access to the customers. The core of the network is made of P routers, or Provider routers. This provider has decided to convert their entire network to MPLS. This gives the ISP better performance by allowing the routers to utilize the ASICS built into the routers to switch the packets at incredible speeds. It also allows the ISP to offer many new services such as MPLS VPN’s as well as VPLS or (Virtual Private Lan Service.) In addition to these services the ISP can Use the tunneling aspect of MPLS to create Traffic engineering tunnels that will allow it to very precisely control which paths through the Provider network certain traffic takes. It also allows them to set very specific and granular QOS or COS policies for customers.

MPLS confuses many people because of its amorphous place in the OSI model. MPLs officially is a layer 2.5 protocol because Layer 3 protocols can be encapsulated in MPLS. MPLS stand for Multi Protocol Label Switching. MPLS can carry many different Layer 3 protocols inside it, just as ethernet a layer 2 protocol can carry TCP/IP inside its frames. However MPLS is more complicated than that. Many people can easily be confused because MPLs depends on the routing table in order to function, in this sense you could think of it like a layer 4 protocol. MPLS cannot function if the routing table is not working. MPLS depends on LDP or the Label Distribution Protocol to form adjacencies with neighbors and distribute its list of labels as well as receive labels from peers. LDP forms adjacencies at the layer 3 level and used the routing table to find peers. LDP is similar to OSPF in that is uses the highest Loopback address to identify itself. In our network Diagram each switch has a loopback address. All of the P routers including the PE routers are running OSPF. This OSPF instance is advertising the subnets owned by the ISP, many ISP’s use ISIS for this purpose, in fact many ISP’s use private addresses in their network especially if there network is a transit network. There are many situation in which you have public IP traffic traversing a private network connecting another public network. The 3 P routers and 2 PE routers need to know how to get to all of the non public IP addresses that the ISP is using to connect their network together. OSPF is used to synchronize these addresses as well as advertise each routers loopback address. Once all routers have formed neighbor relationships and all routes have been distributed through OSPF LDP is able to use the routing table to form adjacencies with other routers using their loopback addresses.

Once LDP has formed neighbor relationships with other routers using their loopback addresses it is able to start synchronizing the tag database. MPLS Assigns a tag or label to every route in the routing table. when a packet enters the MPLS PE routers interface, the router does a route lookup to determine the tag for the destination of the packet. Once this decision had been made, the router will push the tag on the packet and send it out the appropriate interface. The next router in line  has a simpler job. This router does not even have to look at the routing table, it can just look at its forwarding table and see what new tag should be assigned to the packet and send the packet on its way. the reason why this is so fast is because the MPLS tags were designed to look like layer 2 frames to the ASICS on the routers. This allows the programmers to leverage the same high speed chips used to route packets from one switch port to another based on mac addresses.

In MPLS the language is push and pop. to push a tag is to add a tag to a packet and to pop is to remove a tag from a packet.

Once MPLS is working the ISP can begin to configure its client connections. To do this the ISP creates two VRF tables (Virtual Routing forwarding). The first VRF table we will call CompanyA and the second VRF table we will call CompanyB. It is important to add 2 things to each VRF table. The first thing is the route-target and the second is the route-discriminator. The route target is used by BGP as an extended community attribute. This lets BGP and other protocols determine what routes should be added to a VRF instance, and it also lets BGP know what routes are from a VRF instance.

This is important, because we need a way to get the routes from Company A site 1 into Company A site 2 router without mixing them up with routes from any other client. This is one of the key factors that lets two way route redistribution function correctly.

Once the VRF is created the next thing to do is go to the interface that connects the customer and add that interface to the Companies VRF. Once you do this the connected route for that interface should no longer show up on the main routing table. Once this step is complete it is time to configure a second instance of OSPF to communicate with the CPE equipment. this is done by specifying the VRF name when creating the new instance of OSPF.

Now that the OSPF adjacency is up with the customer you should be able to see a list of the routes under that VRF. The next step is to establish a BGP neighbor relationship with the other PE routers in the ISP or a Route Reflector depending on the size of the environment. Once the BGP relationship is established, the only thing you have to do is redistribute the OSPF routes into BGP and vice versa under the appropriate OSPF Instance.

The end users should see the OSPF routes as simple IA routes. At the end of this post I will attach the full configs for all routers used incase you want to duplicate this in a lab or use GNS3 or Dynamips.

Routes as seen by end USER or MPLS Subscriber

Here are links to all the configs for all routers used in the lab –>Router Configs

The important part here is I wanted to create a web form which requests the internal and external address ranges of anyones network. Once that person submits that information I will have a Peal script pull those messages from the web form, parse the information, insert the networks and IP addresses into a J-Script template and apply it to my Juniper SRX router automatically.

This project will enable Cisco and Juniper students to participate in the environment and create a public VPN network where p2p APPS and anything else can run over the network without having to worry about any prying eyes. I want to see how far this project will scale. I was even envisioning a time when other people with idle equipment can volunteer to become a secondary hub to take some of the load once my connection reaches 10 thousand or so tunnels. Because of the way DMVPN works. The tunnels between sites will open up as needed when a user from site A needs to talk to site B. This combined with using BGP as the routing protocol will mean that it will require very little bandwidth as traffic destined from site A to C will not transit site B if site B in this scenario is the hub.

Anyways if anyone out there is interested please leave a comment.

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.

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

The access-list thought that these packets were part of an ongoing conversation and allowed them to sneak past. To fix this problem God shook heaven and earth and created reflexive access-lists. With these new and improved protectors of Gods interfaces packets were only allowed through if they matched a rule created for traffic flowing in the other direction. With this new method, return packets would only be allowed through if they matched a dynamic rule created by the original outgoing packet. God set back and looked at his creation and all was as it should be. Then one day applications were created that used dynamic ports for return traffic. For instance a person connects to a server on port 80, and the server responds with a packet on a random port between 45000 and 62000. Since the return packets did not match the originating packets the return packets would be dropped.

To fix this new problem God created CBAC or Content Based Access Control. With this new enhanced type of security found in the Firewall Feature set, traffic is inspected at layer 4 on the way out, and a dynamic access-list is created inbound on the interface to allow the traffic to return. Since CBAC inspects traffic on a higher level of the OSI model it can understand protocols that use dynamic port assignment, it can glean useful information from upper layer protocols that will help it make intelligent state full firewalling decisions and improve security while reducing false positives. You can see how over the years the security that we use has become ever more sophisticated to combat the ever clever internet hacker.

Below I will show you how to use CBAC on your router, Keep in mind that CBAC is part of the firewall feature set so may require additional licensing if your organization has to upgrade the ios. Ip inspect is configured in two areas. The first thing you have to do is create an inspection rule, and define what higher layer protocols you want to inspect. The next thing you have to do is apply the rule in the outbound direction on the interface you want to protect. You must also have either an access-list applied in the inbound direction; the access-list can be blank. When configuring the inspection rule you can choose from a number of protocols to look at. For ip inspect to work and to fix the issue with reflexive access-lists you only have to inspect layer 4 protocols such as tcp and udp. However CBAC supports many higher level protocols such as http, SMTP, real-audio, and other session and presentation, layer protocols.

Here is a config that shows some of the many possible protocols that can be inspected with CBAC. I have listed the two main ones at the top. Another tip, if you have sip phones with private nat’d addresses behind this router and you want them to connect outside you need the ip inspect sip command to translate that properly through nat.

!
ip inspect name cbac-example tcp
ip inspect name cbac-example udp
ip inspect name cbac-example vdolive
ip inspect name cbac-example smtp
ip inspect name cbac-example http
ip inspect name cbac-example rtsp
ip inspect name cbac-example sip
ip inspect name cbac-example skinny
ip inspect name cbac-example tftp
ip inspect name cbac-example ftp
ip audit po max-events 100
!
!
!
!
!
interface FastEthernet0/0
 ip address 192.168.1.254 255.255.255.0
 ip access-group from_internet in
 ip inspect cbac-example out
 duplex auto
 speed auto
!

Here is a related article on ACL’s.

#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