Re: HSRP Track VPN

anthony.baker · ‎09-08-2009

Hey guys,

I have two 6500's with FWSM's. The 6500's have a VPN connection from each to a PIX for VPN between two sites.

The route out of the FWSM is the HSRP of the two 6500's so while both connections are up there's no problem. However, if one VPN connection goes down then although the other one is there it isn't used because the traffic is still sent to the other switch. The problem is that sometimes the VPN connection goes but the actual interface is still up.

Is there any way for me to get HSRP to track the VPN connection or a better way of doing things?

Cheers,

Anthony

Jon Marshall · ‎09-14-2009

Anthony

It's not entirely clear what your topology is ie.

you have an FWSM in each 6500. The outside interfaces of the FWSM's share a vlan with the 6500 and there are L3 SVI's for this vlan on teh MSFC. You have static routes ??, pointing to the HSRP VIP on the FWSMs.

Are the FWSMs running in active/standby or active/active ?

After that its a bit unclear.

"The 6500's have a VPN connection from each to a PIX for VPN between two sites."

Do you mean the 6500 switches have VPN cards or does the VPN start at the pix ?

"The route out of the FWSM is the HSRP of the two 6500's so while both connections are up there's no problem. However, if one VPN connection goes down ..."

So are you running 2 VPN connections at the same time and if so how do you ensure return traffic always comes back down the same tunnel.

If you are running 2 VPN connections are the pix firewalls active/active ?

Jon

anthony.baker · ‎09-15-2009

Hey Jon,

Thanks for the reply.

You're pretty much right, two FWSM's, one in each 6500 running active/standby. They have a static route to the HSRP of the outside VLAN from FWSM to 6500.

The 6500's don't have VPN cards. Each 6500 has it's own VPN connection from their 'Internet' interface.

The PIX is active/standby too, so both 6500's connect to the same PIX in effect.

I think my issue here really is how I get the traffic to return the right way if one of the tunnels disappears.

Could I use PBR to check the tunnel and make a decision based on that somehow?

Thanks for the help!

Anthony

Jon Marshall · ‎09-15-2009

Anthony

PBR together with IP SLA was indeed going to be my suggestion if it fitted in with your topology.

Apologies for being a but thick ! but you say -

"The 6500's don't have VPN cards. Each 6500 has it's own VPN connection from their 'Internet' interface."

My understanding what that without additional cards the 6500 switches will not support VPNs so i am a bit confused.

Jon

anthony.baker · ‎09-15-2009

Hey Jon,

Firstly, I've read many of your answers on here and you're far from 'thick'!!

What's IP SLA? And how would you suggest getting PBR to work out if the VPN connection is up or not?

I'm using the 6500 to run IPSEC VPN? I have an interface on each Supervisor that's connected to the internet (two different ISP's, not BGP'd) and the tunnel terminates on each - does that make sense?

I did this because the FWSM's don't support VPN's...

Cheers!

Jon Marshall · ‎09-15-2009

Anthony

Okay, i don't think we need PBR just IP SLA and HSRP track. Here's an example of how this would work -

6500 HSRP active switch

ip sla monitor 1

type echo protocol ipIcmpEcho

ip sla monitor schedule 1 life forever start-time now

track 10 rtr 1 reachability

int vlan 10

ip address 192.168.5.2 255.255.255.0

standby ip 10 192.168.5.1

standby ip 10 pri 110

standby ip 10 preempt

standby 10 track 10 decrement 20

6500 HSRP standby switch

int vlan 10

ip address 192.168.5.3 255.255.255.0

standby 10 ip 192.168.5.1

standby 10 priority 100

standby 10 preempt <-- very important you include this

So what the above will do is the HSRP active switch will ping an IP address at far end of the VPN tunnel. If that ip address responds within the specified timeout fine. If it doesn't the switch will take 20 off the priority making it's HSRP priority 90. This is less than the standby switches priority and so the standby switch takes over the HSRP duties.

Note that you will need to modify the timeout for the ping as it is going down a VPN tunnel. Do some ping tests to gt an idea of the sort of timeout you need.

One other thing. Depending on your 6500 IOS it may either be "ip sla ..." commands or the previous version "ip rtr ..." commands.

Does this sound like a workable solution ?

Jon

anthony.baker · ‎09-15-2009

Hey Jon,

It all looks good for a final setup but unfortunately I don't have RIPE addresses yet and no BGP so if I just fail the HSRP of that 'outside FWSM' VLAN accross then although the VPN traffic will be fine all other traffic will fail because it will be going out as the wrong IP address.

Is there a way for PBR to use IP SLA to check the far end and then route accordingly? So PBR on switch one sees it's tunnel is down so routes to switch 2 but all other non-vpn traffic would continue to use switch 1?

Your solution will work if the ISP's don't care about the source address as the route back will still be up, so I need to check that out.

Thanks again,

Anthony

Jon Marshall · ‎09-15-2009

Anthony

"Is there a way for PBR to use IP SLA to check the far end and then route accordingly? So PBR on switch one sees it's tunnel is down so routes to switch 2 but all other non-vpn traffic would continue to use switch 1?"

Yes, as long as you can define the vpn traffic as opposed to the non-VPN traffic.

Do the VPN and non-VPN traffic both come from behind the FWSM ?

I have a PBR/IP SLA lab setup on my laptop somewhere !!, so i'll try and dig it out.

I'm assuming that if we redirect VPN traffic to switch 2 it will then have routes that send the traffic over the VPN tunnel ie. it won't send it back to switch 1.

Jon

anthony.baker · ‎09-15-2009

Sounds like you might be onto something Jon!

Everything does come from behind the FWSM but it doesn't NAT the traffic that goes via the VPN so it's easy to differentiate. So, in this case anything destined for 10.1.0.0 goes via VPN, anything else goes out via the internet.

Switch two has the same access-list for VPN so will know to send that same traffic to the VPN tunnel if it arrives there.

I look forward to the configuration!!

Cheers,

Anthony

Jon Marshall · ‎09-15-2009

Anthony

Okay, that took a bit longer than i thought !, couldn't find lab so i created a new one.

For this example

HSRP active 6500 = CS1

HSRP standby 6500 = CS2

remote IP to ping - 192.168.5.10

CS1 next hop for all traffic + VPN traffic if 192.168.5.10 responds to a ping = 10.6.1.1

CS1/FWSM shared vlan IP = 10.5.1.2 - VIP 10.5.1.1

CS2/FWSM shared vlan IP = 10.5.1.3 - VIP 10.5.1.1

CS1 config

ip sla monitor 1

type echo protocol IcmpEcho 192.168.5.10

ip sla monitor schedule 1 life forever start-time now

ip sla monitor 2

type echo protocol IcmpEcho 10.5.1.3

ip sla monitor schedule 2 life forever start-time now

track 1 rtr 1

track 2 rtr 2

int vlan 10 (this is the shared FWSM vlan)

ip policy route-map PBR

access-list 101 permit ip any 10.1.0.0 0.0.0.255

route-map PBR permit 10

match ip address 101

set ip next-hop verify-availability 10.6.1.1 10 track 1

set ip next-hop verify-availability 10.5.1.3 20 track 2

What this does -

CS1 pings 192.168.5.10. As long as it is up then traffic for both the VPN and normal traffic is sent to 10.6.1.1.

If 192.168.5.10 stops responding then all traffic destined for 10.1.0.0 is sent to 10.5.1.3 instead where 10.5.1.3 is CS2. CS2 should then send the traffic via VPN.

Normal traffic is not affected and is still sent via 10.6.1.1

Now it worked in the lab but you would definitely want to either test this yourself or if you don't have the kit, implement out of hours and test. The PBR and IP SLA stuff works fine but i'm not entirely sure how the VPN will react. I didn't test with VPNs as i was using dynamips and my IOS doesn't have the IPSEC feature.

Hopefully the above makes sense. You may need to tweak it to fit your environment.

Let me know how you get on.

Jon

anthony.baker · ‎09-17-2009

Hey Jon,

Thanks for that. I do have a test environment so will put it together and give it a go.

Will let you know how it goes.

Thanks for all the help!

Anthony

anthony.baker · ‎10-01-2009

Hey Jon,

I'm really struggling to find an image that has both IPSec and the IP SLA functions. I'm looking at the list of features and it's saying it should have both (I can see a feature group called IP SLAs is that right?) but when I load it up I can only do the IPSec stuff. Wierd.

Do you have any ideas?

Cheers,

Anthony

Jon Marshall · ‎10-01-2009

Anthony

Which IOS version are you currently using ?

Jon

anthony.baker · ‎10-01-2009

Hey,

I'm currently on:

IOS (tm) s72033_rp Software (s72033_rp-IPSERVICESK9-M), Version 12.2(18)SXF9

(s72033-ipservicesk9-mz.122-18.SXF9.bin)

I've also tried:

IOS (tm) s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF17, RELEASE SOFTWARE (fc1)

(s72033-adventerprisek9_wan-mz.122-18.SXF17.bin)

Anthony

Jon Marshall · ‎10-01-2009

Anthony

Yes, according to feature navigator it should support IP SLA - what command are you trying to enter and what are you seeing ?

Jon