Can I use an extended access-list with Policy based routing to route based on destination network?

greenbeanx81
greenbeanx81 used Ask the Experts™
on
Hello All,

I have a question. I have a router that has to connection to diferrent remote networks. Can I use a extended access-list with Policy Based Routing to set the next hop based on the destination network not source host or network?
 
access-list 100 permit tcp any 10.1.2.0 0.0.0.255
access-list 100 permit icmp any 10.1.2.0 0.0.0.255
access-list 101 permit ucp any 10.1.2.0 0.0.0.255

route-map SwitchOver permit 10
match ip address 100 101
set ip next-hop 192.168.2.1

Would the ablove route any source address to 192.168.2.1 that has 10.1.2.0 0.0.0.255 has the network? I have this statement on a router but something doesnt seem right. Thanks
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2010

Commented:
you still need to apply the PBR to the interface of the source traffic

JuniperSucks(config)# interface fa0/0
JuniperSucks(config-if)#ip policy route-map SwitchOver

Billy

Author

Commented:
Yes that is done I just didnt show it. There is nothing that should prevent it.
Top Expert 2010

Commented:
that is it; you also have to think about the remote end, does it have a route back to 192.168.2.0 network?
Maybe post your entire config sanitized and we can probably get a better idea. Also, if the route is asymmetrical and you are doing any stateful packet inspections in your network, this could cause a device to drop the packet based and where the packet is entering the network/interface.

Billy
Exploring SharePoint 2016

Explore SharePoint 2016, the web-based, collaborative platform that integrates with Microsoft Office to provide intranets, secure document management, and collaboration so you can develop your online and offline capabilities.

Author

Commented:
The 192.168.2.0 is actually a router connected to a ASA firewall that provided a VPN tunnel to the remote route. The is an ASA on the remote end that is connected to a similar with configuration and then the 10.1.2.0 network So


                                                                              VPN Tunnel                                       10.1.2.1/32
Network Switch <------> Router <---------> ASA<------------------------->  ASA<-------------->Router<-----------> Switch
10.1.3.0/24         10.28.5.0/30         192.168.2.0/30                                  192.168.2.0/30                        10.1.2.0/24

I've been able to make this configuration work bsed off sorce but not destination..Let me post the configurations. Also the VPN tunnel is up. and all the routes look correct on the ASAs
Main-Internet-Router.txt
Branch-Internet-Router.txt
Top Expert 2010

Commented:
that diagram did not format correct, what is up with the overlapping networks?
what is it that you are trying to accomplish
do you have a better network diagram

Billy

Author

Commented:
I'm trying to use poicy based routing to route any traffic to the 10.1.2.0/24 network by sending to next hop 192.168.2.1 which is a Cisco ASA that has a VPN tunnel to a Cisco ASA on the 10.1.2.0/24 network that is connected to a similar router with config
network-diagram.txt

Author

Commented:
The packet should go Switch to Router to 2nd ASA over VPN tunnel to ASA to Router then to 10.1.2.0 network on switch and vice versa
Top Expert 2010

Commented:
do you have the source addresses 10.1.3.0/24 and 10.1.2.0/24 defined for the crypto on the ASAs?

Author

Commented:
At the main I have:

Access-list BARODA permit ip 10.1.3.0 255.255.255.0 10.1.2.0 255.255.255.0
access-list NONAT permit ip 10.1.3.0 255.255.255.0 10.1.2.0 255.255.255.0

nat (inside) 0 access-list NONAT

crypto map VPNmap 10 match address BARODA
crypto map VPNmap 10 set peer 64.x.x.x
crypto map VPNmap 10 set transform-set ESP-3DES-MD5
crypto map VPNmap interface outside

and I have an isakmp policy in place.

Same with the other site

Author

Commented:
Maybe I'm missing something I overlooked..??
Top Expert 2010

Commented:
on each of the routers run:

show route-map SwitchOver
show access-list

on the ASA devices run:

show crypto isakmp sa
show crypto ipsec
Top Expert 2010

Commented:
appears your PBR is working as expected, but your ipsec tunnel is not encapsulating the packets at the BeverlyCable ASA, so the issue is on the Main site side. Let me review the configs again, but I thought they looked ok.

Billy

Author

Commented:
Yep I saw the same thing..Everything looks fine..at least to me..
Top Expert 2010

Commented:
are you able to ping 192.168.2.1 from a system on the 10.1.3.0/24 network. What about some traceroutes. Maybe starting debugging on the devices in the path to find out of there are any denies going on.

Author

Commented:
I'm not able to ping to the other side


Trace route stops at 10.28.5.20 at Main side which is the router..so it doesnt get beyond the router or past the tunnel.

Top Expert 2010

Commented:
what is this device? 10.28.5.10
any policies on that would be denying traffic coming back in?

Billy

Author

Commented:
10.28.5.20 is the main router that does Policy Based Router. Two ASAs are connected to it, one of which is the BeverlyCableASA. Here is the trace route..it stops at the router....
trace.txt
Top Expert 2010

Commented:
what I am asking is what is 10.28.5.10, there is a static route for 10.1.3.0/24 on the main router:
ip route 10.1.3.0 255.255.255.0 10.28.5.10

Billy

Author

Commented:
Thats the switch that has vlans on it. vlan 99 is 10.28.5.0 network.  The switch is 10.28.5.10 and the router is 10.28.5.20
Top Expert 2010

Commented:
what is the IP of the source of the ping and traceroute?

Author

Commented:
both 10.1.3.10

Author

Commented:
Could there be an issue with the access-list 100 101 not routing to the ASA. Maybe the other access lists are routing to the first ASA before the 100 and 100 can route to the second. But the extended are routing based on destination only. How about precedence in the route-maps? Everything looks right. The second ASA is bogged down with constant video traffic of high bandwidth applications. Could nothing be getting through not even ICMP requests.
Top Expert 2010
Commented:
that is what I was thinking; I have never used the match clause with multiple access-list and not familiar with the logic:
route-map SwitchOver permit 10

 match ip address 100 101
 1 4
 set ip next-hop 192.168.2.1

give that a shot

per Cisco:
Like matches in the same route map subblock are filtered with "or" semantics. If any one match clause is matched in the entire route map subblock, this match is treated as a successful match. Dissimilar match clauses are filtered with "and" semantics. So dissimilar matches are filtered logically. If the first set of conditions is not met, the second match clause is filtered. This process continues until a match occurs or there are no more match clauses.

Author

Commented:
I remember when I routed traffic over a VPN tunnel using the first ASA to the remote network that people connecting using Remote VPN could not access services not even ping until the VPN tunnel and the traffic across the tunnel was brought down  
Top Expert 2010

Commented:
that was odd, it did not like the format of that:

route-map SwitchOver permit 10

match ip address 100 101
 1 4
set ip next-hop 192.168.2.1
Top Expert 2010

Commented:
just added it as a code snippet
route-map SwitchOver permit 10
 match ip address 100 101 1 4
 set ip next-hop 192.168.2.1

Open in new window

Author

Commented:
Changed on both sides and still the same issue..*sigh* maybe its a bandwidth issue..
Top Expert 2010

Commented:
what is interesting is that you can see the encaps increase on the branch side and decap on the main site. You are not able to ping 192.168.2.1 which does not use any PBR and that is a bit interesting. Maybe what you can do is debug ip icmp and debug ip policy and possible debug ip access-list on the main router to see what is going on.

Billy

Author

Commented:
yes, could those my arp requests are misc trffic going across the tunnel or trying to. I cant ping, remote desktop, file share, or the see XOSoft replication is not working..

I'm not able to ping 10.1.2.254 or 10.1.2.1 on the other side using icmp..or trace to this addresses from the 10.1.3.0 network . I'll continue with your sugesstions
Top Expert 2010

Commented:
earlier I asked you to ping 192.168.2.1 , and you said that you were not able to ping the other side, are you able to ping 192.168.2.1 (main ASA)  or able to ping from Main ASA to  10.1.3.10?

Author

Commented:
I just tried and I cant it is the following below. The 10.1.3.0 can only go to the main ASA network not the 2nd ASA because of the route-map SwitchOver permit 20:

access-list 1 permit 10.1.13.0 0.0.0.255
access-list 2 permit 10.1.3.0 0.0.0.255
access-list 3 permit 10.1.5.0 0.0.0.255
access-list 4 permit 10.1.3.15
access-list 4 permit 10.1.3.40
access-list 4 permit 10.1.13.50
access-list 4 permit 10.1.3.200
access-list 4 permit 10.1.3.201
access-list 4 permit 10.1.3.202
access-list 100 permit tcp any 10.1.2.0 0.0.0.255
access-list 100 permit tcp any 10.1.12.0 0.0.0.255
access-list 100 permit icmp any 10.1.2.0 0.0.0.255
access-list 100 permit icmp any 10.1.12.0 0.0.0.255
access-list 101 permit udp any 10.1.2.0 0.0.0.255
access-list 101 permit udp any 10.1.12.0 0.0.0.255
!
!
!
route-map SwitchOver permit 10
 match ip address 1 4 100 101
 set ip next-hop 192.168.2.1
!
route-map SwitchOver permit 20
 match ip address 2 3
 set ip next-hop verify-availability 192.168.1.1 1 track 100
 set ip next-hop verify-availability 192.168.2.1 2 track 150
!

Should I create extended access-lists example access-list 102 permit tcp 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255 and bind it to route-map SwitchOver permit 10 to solve this problem..sounds like it could work.
Top Expert 2010

Commented:
well, it appears that you have traffic from 10.1.5.0 going to 10.1.2.0 with no issues correct?
Top Expert 2010

Commented:
--I just tried and I cant it is the following below. The 10.1.3.0 can only go to the main ASA network not the 2nd ASA because of the route-map SwitchOver permit 20:

Main ASA:

interface Vlan1

 description Connection to Beverly Internet Router

 nameif inside

 security-level 100

 ip address 192.168.2.1 255.255.255.252

it has 192.168.2.1, so if you are not able to ping 192.168.2.1, then something is up with filtering or routing from 10.1.3.0 to 192.168.2.1 (to main ASA vlan1)

Billy

Author

Commented:
same problem so ACL for that binded to the route-map SwitchOver permit 10

Author

Commented:
I am able to ping 192.168.2.2 from the ASA which is ip address 192.168.2.1. I cant ping 10.1.3.1 (internal router interface) or 10.1.3.10
Top Expert 2010

Commented:
--Should I create extended access-lists example access-list 102 permit tcp 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255 and bind it to route-map SwitchOver permit 10 to solve this problem..sounds like it could work.

you can try, but you have an any statement in 100:

access-list 100 permit tcp any 10.1.2.0 0.0.0.255

which is covered in permit 10
Top Expert 2010

Commented:
--I am able to ping 192.168.2.2 from the ASA which is ip address 192.168.2.1. I cant ping 10.1.3.1 (internal router interface) or 10.1.3.10

Good, can you post the config of the switch at the main site?

Billy

Author

Commented:
I cant ping the 10.1.3.254 or .1 from the 2nd VPN ASA but I can from the router behind it so the problem would be on the router, right?:

access-list 2 permit ip 10.1.3.0 0.0.0.255

route-map SwitchOver permit 20
 match ip address 2 3
 set ip next-hop verify-availability 192.168.1.1 1 track 100
 set ip next-hop verify-availability 192.168.2.1 2 track 150

Included config of switch


Switch.txt
Top Expert 2010

Commented:
yeah, at this point it appears to be the router, I would start running some debugs on access-lists, policies and packets on the main router to find out what is going on.

Billy

Author

Commented:
yes I can ping 10.1.3.10 from the primary ASA so the router is sending packets to the Main ASA but not back to the 2nd ASA because the rout-map is directing packets from the 10.1.3.0/24 to the primary ASA. the icmp traffic does make it back to the 2nd ASA on the round trip when pinged
Top Expert 2010

Commented:
not sure what you are referring to when talking about primary, Main and 2nd ASA. Do you have a network diagram that depicts your entire network and how they are connected? At this point I am a bit confuse on your topology now. How many total ASAs do you have.

Billy

Author

Commented:
Two ASAs connected to the Main router. On the router you can see a route-map with priority 20.

access-list 2 permit 10.1.3.0 0.0.0.255
access-list 3 permit 10.1.5.0 0.0.0.255

route-map SwitchOver permit 20
 match ip address 2 3
 set ip next-hop verify-availability 192.168.1.1 1 track 100
 set ip next-hop verify-availability 192.168.2.1 2 track 150

Its sending the traffic from 10.1.3.0/24 to 192.168.1.1 based of the track 100 object. That is what is causing the issue I believe. If track 100 is down then it will send it to the 2nd ASA..So by default everything on 10.1.3.0/24 network is going to 192.168.1.1 because I can ping from 192.168.1.1 to 10.13.10 but cant from 192.168.2.1.
Top Expert 2010

Commented:
But permit 20 should never be used:

route-map SwitchOver permit 10

 match ip address 1 4 100 101

 set ip next-hop 192.168.2.1

access-list 100 permit tcp any 10.1.12.0 0.0.0.255

access-list 100 permit icmp any 10.1.2.0 0.0.0.255

access-list 100 permit icmp any 10.1.12.0 0.0.0.255

1 will fail, 4 will fail, 100 will be matched at will never goto permit 20

This is how I see it.

Billy

Author

Commented:
It has to be used because it is sending traffic to the 192.168.1.1 with track object 100 from the 10.1.3.0 network. I can ping from 192.168.1.1 but not from the other ASA.. If I could ping from the second then I shouldnt be able to from the first. Something has to be sending the icmp packet to the 192.168.1.1.

Somehow 10 is not not being met and it moves on to 20. I should specify the source and destination networks I think.
Top Expert 2010

Commented:
--Somehow 10 is not not being met and it moves on to 20. I should specify the source and destination networks I think.

Correct, I agree; maybe debug to see what is going on

Billy

Author

Commented:
I added the following lines on the main router and mirrored the configuration on the branch I works but now I can ping across to the other side but no tcp or udp traffic is being sent across. the Access-lists are not matching that traffic:

access-list 100 permit tcp 10.1.3.0 0.0.0.225 10.1.2.0 0.0.0.255
access-list 100 permit tcp 10.1.3.0 0.0.0.255 10.1.12.0 0.0.0.255
access-list 100 permit icmp 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
access-list 100 permit icmp 10.1.3.0 0.0.0.225 10.1.12.0 0.0.0.255
access-list 100 permit udp 10.1.3.0 0.0.0.225 10.1.2.0 0.0.0.255
access-list 100 permit udp 10.1.3.0 0.0.0.225 10.1.12.0 0.0.0.255
access-list 101 permit tcp 10.1.5.0 0.0.0.225 10.1.2.0 0.0.0.255
access-list 101 permit tcp 10.1.5.0 0.0.0.255 10.1.12.0 0.0.0.255
access-list 101 permit icmp 10.1.5.0 0.0.0.255 10.1.2.0 0.0.0.255
access-list 101 permit icmp 10.1.5.0 0.0.0.225 10.1.12.0 0.0.0.255
access-list 101 permit udp 10.1.5.0 0.0.0.225 10.1.2.0 0.0.0.255
access-list 101 permit udp 10.1.5.0 0.0.0.225 10.1.12.0 0.0.0.255
access-list 102 permit tcp 10.1.13.0 0.0.0.255 any
access-list 102 permit udp 10.1.13.0 0.0.0.255 any
access-list 103 permit tcp 10.1.3.0 0.0.0.255 any
access-list 103 permit tcp 10.1.5.0 0.0.0.255 any
access-list 103 permit udp 10.1.3.0 0.0.0.255 any
access-list 103 permit udp 10.1.5.0 0.0.0.255 any
access-list 104 permit tcp host 10.1.3.15 any
access-list 104 permit tcp host 10.1.3.40 any
access-list 104 permit tcp host 10.1.13.50 any
access-list 104 permit tcp host 10.1.3.200 any
access-list 104 permit tcp host 10.1.3.201 any
access-list 104 permit tcp host 10.1.3.202 any
access-list 104 permit udp host 10.1.3.15 any
access-list 104 permit udp host 10.1.3.40 any
access-list 104 permit udp host 10.1.13.50 any
access-list 104 permit udp host 10.1.3.200 any
access-list 104 permit udp host 10.1.3.201 any
access-list 104 permit udp host 10.1.3.202 any
!
!
!
route-map SwitchOver permit 10
 match ip address 100 101 102 104
 set ip next-hop 192.168.2.1
!
route-map SwitchOver permit 20
 match ip address 103
 set ip next-hop verify-availability 192.168.1.1 1 track 100
 set ip next-hop verify-availability 192.168.2.1 2 track 150


ping-to-other-side.txt
Show-Access-list-on-main-router.txt
Top Expert 2010

Commented:
You need to to utilize debugging to find out what is happening; As I stated before, the configs looked ok, just need to find out if one ACL is been caught be the other and why. You could be running into a bug, who knows.

Author

Commented:
Thank you for your help. I just came to the conclusion that the 102 and 103 access list is over riding everything and there isn't much I can do about it. It was sending everything to the primary device. I  do not have the time to worry about it so I just separated the two gateways and used a layer three switch to do routing. I appreciate your help on this matter.

Author

Commented:
Thank you for the dedication. You really helped me in a tough situation.
Top Expert 2010

Commented:
no worries; it is odd that it is not working for you. I took your same configs with the same equipment and setup a lab and had no issues. So I suspect that you are running into a bug issue (possibly)

Billy

Author

Commented:
Just wondering..what version of the IOS..possible bug..icmp was rerouting but not tcp or udp traffic..very fustrating
Top Expert 2010

Commented:
Service Provider Version 12.4(15)T13

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial