ASA Failover

Let's say I have two ASA devices configured in an Active/Passive failover pair. Right now the inside interface on each of these is connected to different 6513s which is great. Here's the problem. Work is trying to introduce a Web proxy which will be between each of the ASAs and their respective 6513s. Since these web proxies do not do any intelligent routing it pretty much screws up my failover implementation.

For example:
Let's say that the link between the 6513 and the web proxy dies (for whatever reason). Since the link between the web proxy and the ASA is still alive, a failover does not occur. How can I force the ASA to failover in situations like this? Is there any way to use an SLA monitor object to force the ASA to failover? Any thing else I can do? Suggested topologies? I'm running into dead ends with everything I come up with.

Find more posts tagged with

Comments

unclerico

What kind of proxy and is it an absolute requirement to be inline??

mikearama

Damn bro... good one.

cisco_trooper wrote: »

Is there any way to use an SLA monitor object to force the ASA to failover?

Nope, fraid not. The SLA monitor process will remove a route from the routing table if the far side of the proxy goes down, but won't cause the interface to drop, so failover won't happen.

Thinking out loud... since the ASA needs a downed interface to initiate failover, the proxy would have to do something it won't be able to, and down the interface facing the firewall when the inside interface fails. Good luck figuring that out.

I think you have to go with the suggestion of unclerico and not have the proxy inline. It doesn't need to be. It can be in your server farm, or in the DMZ... anywhere. You will, of course, have to configure all client browsers to use the proxy, but then all you'd need to do is allow the proxy to get out. Give it http/https/ftp/dns permissions via ACL's, and deny everything else. Plug it into a port on the big Cat in the same vlan you have the ASA... they'll talk fine.

If you don't put it local to the ASA (same vlan), make sure you have a route on the ASA pointing to the next hop to reach the proxy.

I don't think it gets any easier than that. Good luck.
Mike

Ahriakin

Is it a Layer3+ proxy or a Layer 2 transparent filter (bump in the wire)? It sounds more like the latter. As long as you have the interface in question monitored the ASA can still register failure beyond the link being physically down, if it receives no hellos on the interface after half the hold time it begins a series of connectivity tests, if they all fail but the Secondary is still okay (and your Failover interface-policy allows) it will failover. Now the problem is the tests are very simple,; Are Any packets RX on that interface?, Arp Requests to the last 2 cached address and finally a broadcast Ping. If it receives packets at any point during testing it will not fail the interface. So if your proxy responds basically you're still hosed, if you can work out a way to stop it responding in anyway on the interface facing the ASA you might get this to work. Also you'd need to set your interface policy to failover at 1 IF failure.
It's not likely this will work for you though.

cisco_trooper

unclerico wrote: »

What kind of proxy and is it an absolute requirement to be inline??

The product being tested right now is a SonicWALL CSM 3200. The project lead is suggesting is has to be in line. I would have thought we could point the client browsers at it via group policy.

cisco_trooper

Ahriakin wrote: »

Is it a Layer3+ proxy or a Layer 2 transparent filter (bump in the wire)? It sounds more like the latter. As long as you have the interface in question monitored the ASA can still register failure beyond the link being physically down, if it receives no hellos on the interface after half the hold time it begins a series of connectivity tests, if they all fail but the Secondary is still okay (and your Failover interface-policy allows) it will failover. Now the problem is the tests are very simple,; Are Any packets RX on that interface?, Arp Requests to the last 2 cached address and finally a broadcast Ping. If it receives packets at any point during testing it will not fail the interface. So if your proxy responds basically you're still hosed, if you can work out a way to stop it responding in anyway on the interface facing the ASA you might get this to work. Also you'd need to set your interface policy to failover at 1 IF failure.
It's not likely this will work for you though.

The tech we talked to yesterday suggested that it is a transparent proxy, but through messing with it I tend to disagree, assuming my definition of transparent is the same as his. The inside and outside (x0 and x1) interfaces, get configured with the same IP address (W T F, right?). There is an ability, and apparently a requirement, to add static routes to this device. That alone along with IP address assignment disqualifies it from being transparent in my mind.

unclerico

cisco_trooper wrote: »

The tech we talked to yesterday suggested that it is a transparent proxy, but through messing with it I tend to disagree, assuming my definition of transparent is the same as his. The inside and outside (x0 and x1) interfaces, get configured with the same IP address (W T F, right?). There is an ability, and apparently a requirement, to add static routes to this device. That alone along with IP address assignment disqualifies it from being transparent in my mind.

Yeah, in looking at the admin guide for that appliance it looks like it is a hard requirement for it to be placed in line. It looks like there is the ability to purchase a failover unit and configure IP monitoring. What do you have set for the failover delay on the ASA's?? If you adjust the heartbeat interval and the failover trigger level on the SonicWalls to be something shorter than the failover delay on the ASA's you could potentially force the SonicWalls to failover.

Other than that you should look at another solution that will allow you more options for placement in your network.

cisco_trooper

unclerico wrote: »

Yeah, in looking at the admin guide for that appliance it looks like it is a hard requirement for it to be placed in line. It looks like there is the ability to purchase a failover unit and configure IP monitoring. What do you have set for the failover delay on the ASA's?? If you adjust the heartbeat interval and the failover trigger level on the SonicWalls to be something shorter than the failover delay on the ASA's you could potentially force the SonicWalls to failover.

Other than that you should look at another solution that will allow you more options for placement in your network.

Yeah. Talked to some vendors today and I'm going to look into trying out a pair of St Bernard iPrism devices. Not sure how that is going to go since I haven't heard of them before, but initial inspection of their website etc looks promising. Hope this works out because I know the powers that be aren't going to pony up the $$$ for WebSense.

Web Filter for Enterprise

unclerico

cisco_trooper wrote: »

Yeah. Talked to some vendors today and I'm going to look into trying out a pair of St Bernard iPrism devices. Not sure how that is going to go since I haven't heard of them before, but initial inspection of their website etc looks promising. Hope this works out because I know the powers that be aren't going to pony up the $$$ for WebSense.

Web Filter for Enterprise

I hear ya. We just purchased the WebSense Security Suite but we were also looking into their hosted solution as a lower cost option. Depending on your requirements it may be worth a shot.

Isn't researching and testing products a blast?? I love doing it

. I'd like to hear what you ultimately end up with though.

cisco_trooper

Update:

Going through old posts is so much fun. Going with a pair of iPrisms. In testing it works exactly as expected and failovers occur as they should. The funny part - we've yet to buy it!! Ahhh well.