Cisco: Use CBAC to achieve firewall functionality on router device

Sometimes, because of cost saving usually, the network engineers are forced to use a Cisco router as a firewall (instead of Cisco PIX or ASA). One of the big difference between router and firewall devices is that the ports have different characteristics. If on routers, ports are permitting by default traffic of any packets in and out, on the firewall devices, any packets are denied, if not explicit permitted.Also firewalls look at ports as Inbound at Outbound while for routers this has no meaning.

Anyway I don’t want to discuss here the differences between firewalls are routers, but to show you an example of how to achive firewall functionality by using Control-based Access Control (CBAC). CBAC intelligently filters TCP and UDP packets based on application-layer protocol session information. You can configure CBAC to permit specified TCP and UDP traffic through a firewall only when the connection is initiated from within the network you want to protect. (In other words, CBAC can inspect traffic for sessions that originate from the external network).CBAC inspects traffic and manage state information for TCP or UDP sessions, which allow it to create temporary openings in the access-lists, to allow returning traffic. Without CBAC, traffic filtering is limited to access list implementations that examine packets at the network layer, or at most, the transport layer.

The above explanation is a very technical one. Please have a look at the topology, to understand better what I’m explaining here and also to understand the example below. I will use telnet protocol in this tutorial. From the topology, imagine that you allow on the LAN interface of R2 (Fa0/0) telnet traffic to R3 and nothing else. Also to protect your environment on R2 WAN interface S1/0 you drop and inbound connection by using “deny ip any any” in an access-list. Good you are protected now. But what about the telnet connection? It will no work! Why? It is obivious that if the packet leaving from LAN on port 23 is allowed, the response from R3 is automatically dropped on S1/0 of R2 because of the deny anything access-list. By configuring “ip inspect” you enable CBAC which will keep track your session, so when you will open a telnet connection toR3, the return connection on random port (xxxxx) will be automatically opened by CBAC, despite the deny all access-list configured. In this way you are protected from outside (access is deny) but still able to use the connections you defined (open certain ports for certain session by CBAC).

So, to achieve firewall functionality on a router you have to follow some simple steps:
– use access list to deny any traffic on router’s ports (like firewall behavior)
– open in access-list traffic that you want to establish (remember that this line has to be above the deny line in ACL)
– enable ip inspect rules to open the connection back port

Please have a look into the example below for a better understanding:

Context-based Access Control

Cisco: Engineer’s trick to avoid suboptimal path

I was explaining in the previous post what is the difference between optimal and suboptimal path and how to avoid the use of not such a good path in your routed environment. Also there I presented this so call “dirty trick” you can use to force the routing protocol to choose the path that you want, based on the Administrative distance modification.

As I said there is another way (for sure more than one) to do it, using a more elegant approach and from the networking point of view more safe considering the complex routing environment. I will use the same topology like in the previous post to offer you the possibility to compare these 2 methods presented and to choose the one that you understand and fit better to your needs. Also there are some other ways to do it and please feel free to discussed them in the comments section and maybe to present them here in a future post.

We will achive the desired results by setting one community on R1 for the advertised network 192.168.82.1 and dropping the prefixes, marked with the same community, on R2. Please be aware that for this method to work you have to allowed BGP peers to send communities list with the command “neighbor xx.xx.xx.xx send-community …” under “router bgp xxx” process.

Please see the example by clicking the image below:

Optimal path engineer trick

Cisco: Dirty trick to force optimal path in routed environment

Everywhere in the world people try to find the optimal path to achieve something.If we speak about roads, trips and in our case networking, choosing the best path to an end point can have only advantages.

I took the term optimal / suboptimal path from the routing issues that can appear in the OSPF network environment and which are called by the experts suboptimal routing. What I want to explain here, maybe you already seen it, is that in some network environment the best path to a destination is not always preferred by the routing protocol due to some unhappy situations. To understand better what I’m talking here, please have a look at the topology that I will use for this tutorial and for the next one regarding optimal path.

In the example below I will show you a simple and dirty trick how you can escape from this situation. I recommend to use this dirty trick only in urgent cases and only temporary as this can lead to more problems if you have a complex network environment. In the next days I will show you a more elegant method to escape from suboptimal path problem.

As you can see in the topology we have a network environment formed by 4 routers. On R1 we have configured a BGP session with the peer R3 and OSPF with R2. Since the peers are in different autonomous systems the BGP session will be external. For OSPF this does not matter.The Loopback100 interface in R1 is advertised into BGP and OSPF, and it is learned by R2. On R2 the interface 192.168.82.1 arrives on BGP table and OSPF table, but since the Administrative Distance of the eBGP (20) is better that the one of OSPF (110) on the routing table will appear the route through R4. This is bad because without considering the obvious longer path through R4, we can see that the links between R2-R4 and R1-R3 are Serial interfaces and definitely with more limited bandwidth than FastEhernet interface R1-R2 (we assume that we do no have any QoS or other limitation). Last note before we begin, all the routing processes on the devices are completely configured and functional.

Optimal path dirty trick

Cisco: Layer 1 link failure detection

It has been a while since I didn’t post anything here, but it was holidays and I used that time to relax and rest after a year of work. Following this idea I wish you all “Happy New Year” and all the best in 2009.

Today I planned to write about something easy to implement (just to get in shape), but ignored by some network engineer. For me, Layer 1 issues are very annoying, and here I’m talking mostly about the cases when everything look perfect on your side, cable is plugged in, you have green light for the link, but nothing is working.

Luckily some smart engineers think to develop and implement a feature called Unidirectional Link Detection (UDLD). UDLD is used to detect when the send channel (Tx) of a cable is down, but not the receive channel (Rx) and vice versa. This situation typically can occur in a fiber optic cable when there is a break on one side of the cable run or in copper cable when Rx or Tx pair is broken. When UDLD detects this situation the interface is brought down to prevent spanning-tree loops and black holes due to  unidirectional links.Remember, UDLD is a Layer 2 protocol that with Layer 1 mechanisms to determine the physical status of a link.

Please have a look below for a configuration example:

UDLD