|Read about Greg|
There are so many really cool features in IOS these days that you often don't even know they are there. You don't...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
hear much about them and you don't see them used very often. That doesn't mean they aren't useful. In fact, some of them should be used every day.
In CCIE Corner, we'll look at some of the lesser-known capabilities of IOS and give practical case studies showing how to use them every day. We'll address configuring and debugging, so that you can really get down to business in your network.
What are reflexive access lists?
How many times have you said to yourself, "I want to allow everything out and nothing in"? You get out your trusty access lists and proceed to try and configure something that will do just that. It's not easy, and it's even harder to debug. And after your done, it's still not very secure.
This might be the time to consider using reflexive access lists, or session filtering. This is a special type of access list that allows traffic from the inside out to be allowed to return in a stateful and secure way. When Cisco first brought these lists out, they were called "reflexive access lists," but they have since been renamed "session filters." I like the term "reflexive" so that's what I'll use here.
You know all about normal access lists. (Hey, this is an advanced article! Check out the Router Expert articles by Michael Martin if you need to bring yourself up to date on access lists.) There are times, however, when regular access lists don't cut the mustard. Let's look at a practical example.
Consider accessing a Web server across your router, just like when you access the Internet, as shown in this diagram:
You can create an access list to allow traffic out to Web server, but you don't want the workstation out there to be able to come in. So you deny all traffic from the outside. An access list filter looks at each packet by comparing information in the IP header against the rules in your access list. So when a packet goes through your access list, it is allowed or denied. When you use simple access lists to block the workstation but allow the Web server, that creates a problem. You either allow no access from the Web server traffic to return (and thus break your Web access), or you allow too much access for the Web server. That creates a security problem because you allow all ports above 1024.
What you really want is to permit inbound traffic from the Web server in reaction to your outbound traffic flow. And guess what? That's what reflexive access lists do.
Why use reflexive access lists?
To summarize, reflexive access lists are useful if:
- You need to block all access coming in to your network
- You want to allow access out of your network (and thus you must allow that traffic to return)
- You might want to allow any traffic out…
- Or only specific IP addresses or port numbers
- You want to allow certain types of traffic inbound
- You don't want a firewall solution, just access control.
When to use reflexive access lists
I often use reflexive access lists when two companies wish to connect their networks, especially when the security profile is not high or there is some level of trust. They work well when you need to consider:
- Cost savings -- reflexive access lists became available in the IOS 11.2 release and mainlined on 11.3, so most routers have the feature. You can probably use your existing router and save money.
- Setup time -- you need to something fast (your firewall has just blown up and you need to do something to get the connection back up)
- Interim –- you need something for a short time
- Ease of implementation -- reflexive access lists are easy to create and easy to look after.
Tune in next week, when I'll look at some practical examples of using and debugging reflexive access lists.
Read the follow-up to this article, Using reflexive access lists to allow traffic out but not in.
Do you have questions for CCIE Greg Ferro, or other topics you'd like him to cover? E-mail us and let us know.