ACL and Route-map work together?

Unanswered Question
Oct 7th, 2008

I have a route-map set up which redirects all port 80 traffic from hosts to a web page which is routed on another router.

The route-map is placed on the vlan interface for the vlan, and sets the next-hop as the IP address for the second router, where the redirect web page is routed.

The next-hop on that router for this traffic is the IP address of the redirect web page.

This works fine UNTIL I apply an extended ACL on the vlan interface for the subnet. The ACL restricts access to certain networks and hosts, but it does explicitly allow all port 80 traffic.

As soon as I apply the ACL to the vlan the redirect fails to work. Removing the ACL restores the redirect feature.

What am I missing here?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Richard Burts Tue, 10/07/2008 - 10:28


A route map is used in Policy Based Routing to examine traffic and to make a routing decision that effectively over rides the normal routing logic. Most of the time the route map makes use of an access list as the mechanism to identify the traffic. In this case any traffic permitted by the access list is policy base routed and any traffic not permitted in the access list is not policy base routed and uses the normal routing logic.

If your PBR stops working when you apply the access list then I would guess that there is a flaw in the access list and that it is not permitting the correct traffic. If you provide more details about your environment and the details of your PBR and the access list then perhaps we can make a suggestion about how to fix it.



lynne.meeks Tue, 10/07/2008 - 11:06

Sure. here you go:

Here's the PBR info:

route-map WirelessVPNInfo permit 10

match ip address 155

set ip next-hop

Extended IP access list 155

10 permit tcp any eq www

20 deny ip any any

Here's the ACL; which does explicitly allow all port 80 traffic:

ip access-list extended packets-leaving-vlan15-10-07-08-01


remark Hosting vpn.mobileconfig for iPhone

permit ip host any

remark VPNINFO web redirect page

permit tcp any any eq www

permit ip host any

remark Allow access to LWAPP controller

permit ip host any

permit ip any

remark DNS access

permit ip host any

permit ip host any

remark DHCP access

permit ip host any

permit ip host any


permit ip host any

permit ip host any

remark LDAP access for Macs

permit ip host any

remark VPN access

permit ip host any

permit ip host any

permit ip host any

Here's the VLAN config,

interface Vlan15

ip address

ip helper-address

no ip redirects

ip dhcp relay information trusted

no ip route-cache

ip policy route-map WirelessVPNInfo

ip access-group packets-leaving-vlan15-10-07-08-01 out

mls rp vtp-domain UVMBackbone

no cdp enable



Richard Burts Tue, 10/07/2008 - 11:27


Thank you for the additional information which does help to clarify the issue. Seeing this and re-reading your original post I realize that I did not understand correctly your question and my answer was about something different from what you were really asking. I am sorry about that.

Having seen the access list and the config I now understand what you were really asking, and I believe that I have a better answer to your question. I believe that this is the line in question:

permit tcp any any eq www

To get to the problem let us remember that when the client sends a request to the server that port 80 is the destination port. And that when the server sends a response to the client that port 80 becomes the source port. And since the access list is applied out on the VLAN interface it is permitting responses (rather than requests). So it needs to permit 80 as the source port and not as the destination port (which is what you have). I believe that if you change it to this you will find that it works:

permit tcp any eq www any



lynne.meeks Wed, 10/08/2008 - 03:46


that was exactly the problem.

I added the line permitting 80 as the source port, and it works perfectly.

Seems so obvious now, but I guess hindsight is 20/20.

Thanks for your assistance- much appreciated.

Richard Burts Wed, 10/08/2008 - 03:55


Thanks for posting back to the thread and indicating that the problem was solved. I am glad that I was able to help you find the solution. Hindsight does tend to make things look simple when they were not nearly so obvious when it was an active issue. And the source port/destination port issue is an easy one to overlook.




This Discussion