Question regarding 2 core switches and two firewalls on same network

[#1]

Good Morning,

 We have 2 Catalyst  3750 switches and 2 ASA 5515x on the same network and vlan. One firewall is plugged in to one switch and the other firewall is plugged into second switch. We have a default route setup on SW1 pointing to FW1. I have no route setup for the second firewall on either switch. We just recently installed a new ISP circuit to replace our existing circuit. FW2 is on the new circuit and we are testing nats as well as VPN access . VPN will connect and authenticate with no issues but we are unable to access any network resources. FW2 is configured exactly to FW1 regarding routes and access. (the firewalls where originally setup as failovers and synced). By adding a static route to the core switch, will this help with my issue of not being able to access network hosts over vpn through FW2? I figured since there is no route setup anywhere this would cause the traffic not to respond to the requests. If I set route priority to 10 for the route to FW2 would VPN connections, once authenicated, on either FW's connect to hosts correctly?  I want to be able to utilize both circuits for sake of testing. Thanks

[Richard Burts]

Can you verify that my understanding is correct that your original environment was a failover pair of ASA and a route to the address of the primary ASA on switch1 and no route to the address of the standby switch. And what you have done is to remove the failover configuration so that both ASA will operate independently? In that case you certainly will need some routes on the core switches pointing to the second ASA. The question is what do you want to route to the second ASA. I am guessing that you do not want a default route with the second ASA as the next hop (since you probably do not want your production network traffic using the new circuit while you are testing). Perhaps you want a route to the address pool that the second ASA uses for VPN?

HTH

Rick

[#3]

Correct. For the sake of testing we broke our failover. What we are seeing is when we test VPN on the second firewall we are able to authenicate through AD but we are unable to access any of our servers. My guess is because we have no route setup in our core to point back to the FW. If I can accomplish my testing without changing default route on the core then that would be bonus. The address pool on FW2 is the same as FW1. From our initial testing we haven't had issues with conflicts at this time. Our end game is to make sure everything is working on FW2 the same way as FW1 so when we put the failover back in place FW2 will be primary. Keep in mind that all of our host machines are using the core ip as the gateway and we want to avoid changing that if possible. 

[Richard Burts]

First, can you verify that when you mention VPN testing that you are talking about Remote Access VPN and not site to site VPN?

Assuming that it is Remote Access VPN then I do not see how it could work as expected with the same address pool on both ASA. Essentially what that says is that the same IP subnet exists on two different devices. Your core switch has a route for the subnet of the address pool with some next hop address. That next hop now is pointing to the primary ASA and there is not a way for your core switch to forward to that subnet using the address of the "new" ASA. You need a new address pool on the new ASA and then need a route on the core switch for the new address pool.

HTH

Rick

[#5]

The pool that we use now is on the ASA. on the core we are routing to the ip of the primary FW. The secondary FW (that we are testing with) is on the same network. IE. FW1 ip is 10.10.10.1 and FW2 is 10.10.10.2. Both ASA have a 172 network for the pools. Based on your response I will then need to create a pool for FW2 for example 192 network and set a route on the core to point to that network?

[Richard Burts]

Yes you will need to create a separate pool. The new pool might be a 192 network. But the new pool might also be a different 172 network. Fox example if the existing pool uses 172.16.1.x then the new pool might use 172.17.2.x.

HTH

Rick

[#7]

Thanks I will try that out and see if I get the results I am looking for.