05-02-2011 09:58 PM
We setup Load Balancing (Active/Active) on two ASA's. After logging in to Cisco VPN client, we can only SSH to the ASA that we connect to and we can't SSH to the other ASA. For example, if we connect to ASA1, we can only SSH to ASA1 and we cannot SSH to ASA2. The same is true if we connect to ASA2, we can only SSH to ASA2 and we cannot SSH to ASA1. Is there a way to set it up so that we can SSH to any ASA regardless of which ASA that we connect to?
ssh 0.0.0.0 0.0.0.0 Inside
ssh timeout 5
ssh version 2
management-access Inside
Thanks.
Diane
Solved! Go to Solution.
05-03-2011 01:42 PM
Diane,
The difference you are seeing is that an ASA is a firewall first and a VPN product second. The VPN Concentrators just did VPN and didn't concern themselves with routing, switching, or firewalls. By many peoples estimation this is not a good thing because in increased the attack surface of the ASA. However, Cisco allowed management of the ASA you are on by doing a hairpin reverse tunnel back to the ASA for management. This doesn't scale well to other ASA's and really wasn't intended to do so. From a security point of view the best solution is a managment server.
To setup the management server, you just need a Windows/Linux/Apple (whatever you're comfortable with) machine, configured to allow remote sessions. You can do this in the Windows platform with the Remote Desktop or VNC, if you use Linux or Apple, the both have solutions. Once you have your platform, just install a Terminal emulator like PuTTY or SecureCRT and you'll have access to your systems. If you are using the ADSM to configure your ASA you'll just need a compatible web browser on the management server and then open a connection to your ASAs.
Doing this method gives you the following:
1.) Limited access since a person will need to have an account on the management server to access the admin tools.
2.) Accountability since your event logs on the management server will show who logged in and when. You can even go so far as to setup process controls on what a person can access.
3.) Limits hacking surface. Once you have configured your management workstation, configure an ACL on your ASAs that limit any SSH, HTTPS, etc connection to the managment workstation. With this done, you need only worry about who has access to that workstation.
Hope this helps. I didn't want to flood you, but wanted to give you the reason behind going this route over the method employed by the VPN Concentrators. Let me know if you have further questions.
05-02-2011 10:37 PM
Diane,
It's been a couple of years since I worked with the ASA's in A/A mode but if my memory serves me the only reason you can SSH the one you are connected to is because of a hair-pinning command that allows management traffic to that one. I believe to get to the other one (and most other edge products on your network) you will need to have an internal management server with the appropriate rights. Maybe the better question is to understand why you would want to SSH back to the ASA's on the edge? Are you wanting to manage them, do some sort of cut-through configuration, etc? If the purpose is purely management, I would advise against creating an AnyConnect profile with these rights and instead move this to a centralized management server where you login and then connect to your network devices. Please let me know if this helps or if the question can be further clarified.
Regards,
Robert W. Rogier
05-03-2011 01:15 PM
Thanks Robert for your prompt response. We want to be able to SSH to other ASA for management purpose. We don't want to drive in the office since we live far away from the office and the traffic is terrible. When we had the VPN 3000 Concentrators, we were able to get to any VPN Concentrators regardless of which VPN Concentrator that we connect to.
How would you setup a management server? Is it a Windows server or a Cisco solution? I am looking for my options. Anything that you can think of will be greatly appreciated.
Thanks.
Diane
05-03-2011 01:42 PM
Diane,
The difference you are seeing is that an ASA is a firewall first and a VPN product second. The VPN Concentrators just did VPN and didn't concern themselves with routing, switching, or firewalls. By many peoples estimation this is not a good thing because in increased the attack surface of the ASA. However, Cisco allowed management of the ASA you are on by doing a hairpin reverse tunnel back to the ASA for management. This doesn't scale well to other ASA's and really wasn't intended to do so. From a security point of view the best solution is a managment server.
To setup the management server, you just need a Windows/Linux/Apple (whatever you're comfortable with) machine, configured to allow remote sessions. You can do this in the Windows platform with the Remote Desktop or VNC, if you use Linux or Apple, the both have solutions. Once you have your platform, just install a Terminal emulator like PuTTY or SecureCRT and you'll have access to your systems. If you are using the ADSM to configure your ASA you'll just need a compatible web browser on the management server and then open a connection to your ASAs.
Doing this method gives you the following:
1.) Limited access since a person will need to have an account on the management server to access the admin tools.
2.) Accountability since your event logs on the management server will show who logged in and when. You can even go so far as to setup process controls on what a person can access.
3.) Limits hacking surface. Once you have configured your management workstation, configure an ACL on your ASAs that limit any SSH, HTTPS, etc connection to the managment workstation. With this done, you need only worry about who has access to that workstation.
Hope this helps. I didn't want to flood you, but wanted to give you the reason behind going this route over the method employed by the VPN Concentrators. Let me know if you have further questions.
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