02-12-2012 09:12 PM - edited 03-07-2019 04:53 AM
Experts,
I have configured my router with policy based routing. For some odd reason, I can't get my traffic to failover to the new VPN Tunnel in case my GRE fails.
My source ip address is: 192.16.5.10 and my destination is 192.168.148.114.
This all started because the remote PEER 192.168.200.254 doesn't allow ping, so my SLA 2 doesn't work. (I'm trying 4.2.2.2 that allow ping and then trying to forward to another destination, but it is not encrypting)
This is my scenario.
ISP1 - Dedicated line (Goes over GRE) - interface FastEthernet0/1/0 and GRE Tunnel
ISP - Internet line (VPN) backup link
I'm not sure if I'm missing something
PC 192.16.5.10 (Gateway 5.60)-------->Router with 2 interfaces specified on the config below.
This is my config:
crypto isakmp policy 21
encr 3des
authentication pre-share
group 2
crypto isakmp key test123 address 192.168.100.1 no-xauth
crypto isakmp key test123 address 192.168.200.254 no-xauth
crypto isakmp keepalive 15 localodic
!
crypto ipsec transform-set MyLab esp-3des esp-sha-hmac
crypto ipsec transform-set GRE-Tunnel-forCompany esp-3des esp-sha-hmac
mode transport
crypto ipsec profile VPN-MyLab2
set transform-set VPN-MyLab2
crypto map 3desmap 70 ipsec-isakmp
set peer 192.168.200.254
set transform-set MyLab2
match address MyLab2
!
crypto map MyLab1 17 ipsec-isakmp
set peer 192.168.100.1
set transform-set MyLab1
match address MyLab1
track 123 rtr 1 reachability
!
track 222 rtr 2 reachability
!
interface Tunnel20
description VPN GRE to MyLab2
ip address 192.233.141.238 255.255.255.252
keepalive 5 3
tunnel source 192.233.141.150
tunnel destination 192.233.141.254
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN-MyLab2
!
interface FastEthernet0/0
description OUTSIDE Internet
ip address 192.168.216.82 255.255.255.252
ip nat outside
crypto map 3desmap
!
interface FastEthernet0/1
ip address 192.16.5.60 255.255.255.0
ip nat inside
!
interface FastEthernet0/1/0
description MyLab1
ip address 192.233.141.150 255.255.255.252
ip route 0.0.0.0 0.0.0.0 192.168.216.81
ip route 192.233.141.252 255.255.255.252 192.233.141.149 name WAN_local
ip route 192.168.50.22 255.255.255.255 192.233.141.237 name local
ip route 192.168.148.114 255.255.255.255 192.233.141.237 name local-MyLab2-Nvo
ip access-list extended MyLab2
permit ip 192.16.5.0 0.0.0.255 host 192.168.148.114
ip access-list extended MyLab1
permit ip host 192.16.5.10 host 192.168.50.22
permit ip host 192.16.5.10 host 192.168.148.114
ip sla 1
icmp-echo 192.233.141.254
timeout 1000
threshold 2
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.2
timeout 1000
threshold 2
frequency 3
ip sla schedule 2 life forever start-time now
access-list 101 permit ip host 192.16.5.10 host 192.168.50.22
access-list 101 permit ip host 192.16.5.10 host 192.168.148.114
route-map MyLab1 permit 10
description sends traffic thru separate interface
match ip address 101
set ip next-hop verify-availability 192.233.141.254 1 track 123
set ip next-hop verify-availability 192.168.200.254 2 track 222
!
route-map MyLab1 permit 20
description Permits everything on the Default Gateway
Thanks for any help!
02-12-2012 10:48 PM
Hi Randall,
Where have you used route-map MyLab1 ? I do not see it applyed anywhere.( fa0/1 )
Also if you are using this route-map (MyLab1 ) for PBR purpose you can delete the seq 20.
Dan
02-13-2012 05:53 AM
Hi Dan-Ciprian
Thanks for your time. I forgot to add it. I have it applied on the
interface FastEthernet0/1
Thank you,
Randall
02-13-2012 06:48 AM
Hi Randall ,
And what is the effect ? Does your backup work now ?
Dan
02-13-2012 07:58 AM
Dan,
No, unfortunately it is not working.
Could it be because of this static route:
ip route 192.168.148.114 255.255.255.255 192.233.141.237 name local-MyLab2-Nvo
I would assume that the Policy based routing takes preference over the static routes, doesn't seem to be working this way.
02-13-2012 09:59 AM
Hi Randall,
PBR takes preference over the routing table not only static, using set ip next-hop.
The set ip next-hop command verifies the existence of the next hop specified, and…
if the next hop exists in the routing table, then the command policy routes the packet to the next hop.
if the next hop does not exist in the routing table, the command uses the normal routing table to forward the packet.
There are some thinks that I do not understand :
1) You applied on the tunnel profile VPN-MyLab2 which uses transform set VPN-Lab2, but you have configured only MyLab
interface Tunnel20
description VPN GRE to MyLab2
ip address 192.233.141.238 255.255.255.252
keepalive 5 3
tunnel source 192.233.141.150
tunnel destination 192.233.141.254
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN-MyLab2
crypto ipsec transform-set MyLab esp-3des esp-sha-hmac
crypto ipsec transform-set GRE-Tunnel-forCompany esp-3des esp-sha-hmac
mode transport
crypto ipsec profile VPN-MyLab2
set transform-set VPN-MyLab2
2) On PBR sequence 1 of the set ip next-hop is 192.233.141.254, but I understood that you would like to route this traffic over the tunnel ( 192.233.141.237 , I suppose that is the other end of the tunnel )
Dan
02-14-2012 03:29 PM
Hey Randall,
Hope you well. You have configured the transform set as MyLab but you are using MyLab2 and MyLab1 as transform sets on your cryptomap. Have you configured them ? cuz I couldnt see them in your config
from your config:
crypto ipsec transform-set MyLab esp-3des esp-sha-hmac
crypto ipsec transform-set GRE-Tunnel-forCompany esp-3des esp-sha-hmac
mode transport
crypto map 3desmap 70 ipsec-isakmp
set peer 192.168.200.254
set transform-set MyLab2
match address MyLab2
!
crypto map MyLab1 17 ipsec-isakmp
set peer 192.168.100.1
set transform-set MyLab1
match address MyLab1
If you change them to MyLab. it should work
HTH
Kishore
03-01-2014 09:33 AM
I have this issue too.
It's not a config issue - its something to do with order of operations as traffic is encapsulated / before after routing- I'll fix shortly then tell what I did
11-11-2014 12:36 PM
Hello all,
I just had this happen in my network and I have no idea why. The second I turn off the tunnel protection packets are passed without issue using PBR.
Has anyone find a resolution for this?
Thanks in advance,
db
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide