SSH to inside interface of secondary ASA over VPN

[mdc1973]

Hi,

I currently manage a 5520 over a VPN to the inside interface. This works fine, all requisite config is in place. However, I wish to be able to connect to the secondary firewall in this way- ie. across the VPN to the inside interface- but currently this doesn't work. Is there a way of getting this to work? I can't seem to find anything on the Cisco site that covers this but I would have thought it's a reasonably common requirement. Am I missing something obvious?

Cheers.

 

[North323]

you want to connect to another ASA in the same manner? is this over the same VPN? post a scrubbed config of the firewall you are tyring to ssh in to.

 

[mdc1973]

I have an HA pair of ASAs that I need to manage over the VPN- the primary is fine, I can ssh to the inside interface over the tunnel, but I can't ssh to the inside interface of the secondary ASA (over the tunnel). Maybe it's not possible to do?

Anyway, here's what I believe are the relevant bits of config (plus some other possibly helpful bits):

interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.1.0.1 255.255.255.0 standby 10.1.0.2
!
access-list inside_nat0_outbound extended permit ip 10.1.0.0 255.255.255.0 10.5.0.0 255.255.255.0
access-list outside_cryptomap_10 extended permit ip 10.1.0.0 255.255.255.0 10.5.0.0 255.255.255.0
!
nat (inside) 0 access-list inside_nat0_outbound
!
route outside 0.0.0.0 0.0.0.0 212.x.x.x 1
!
ssh 10.5.0.0 255.255.0.0 inside
!
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4108000
crypto ipsec security-association replay disable
crypto map outside_map 10 match address outside_cryptomap_10
crypto map outside_map 10 set peer 84.x.x.x
crypto map outside_map 10 set transform-set ESP-AES-256-SHA
crypto map outside_map interface outside
crypto isakmp enable outside
!
management-access inside

To reiterate, tunnel is working fine, management of primary is fine, it's literally just trying to connect to inside interface of secondary that's causing me grief (ie ssh from my source ip- 10.5.x.x- to 10.1.0.2)...

Thanks!

 

[North323]

ip address 10.1.0.1 255.255.255.0 standby 10.1.0.2

ssh 10.5.0.0 255.255.0.0 inside

maybe its just me but the IP address of the inside is 10.1.0.1 and your ssh line is 10.5.0.0 and your acl includes 10.1.0.0 10.5.0.0. do you have another interface configured? if you are allowing ssh in to your 'inside', then i would think you have to change ssh 10.1.0.1 255.255.255.0 inside?

 

[mdc1973]

I am on the other end of the VPN (where the 10.5.x.x network is). So when I ssh to the primary ASA (10.1.0.1), my packet goes over the VPN and, thanks to the 'management-access inside' command, allows me to connect to the inside interface. I need 'ssh 10.5.0.0 255.255.0.0 inside' also to allow this.

However, I also need, for various reasons, to connect to the secondary firewall (which is the backup and doesn't have an active tunnel to it- the active tunnel terminates on the primary firewall). So when I try and ssh to 10.1.0.2, my packet is sent across the tunnel to the active ASA, sent on to the secondary firewall inside interface (confirmed with a capture), but then the packet is either dropped or routed through the outside interface (via default route). So I need to know if there's a way of getting my ssh access to the inside interface of the secondary firewall, when I am accessing it from the other side of the VPN.

 

[North323]

basically you want to ssh in to the active then ssh in to the secondary?

 

[mdc1973]

No, I want to ssh directly into the secondary, but to the inside interface- so my packet will arrive on the outside interface of the primary ASA, be decrypted and sent out the inside interface of the primary ASA to the inside interface of the secondary ASA. I think it's the route back that's the problem. I've managed to get a login prompt if I add a route back on the secondary ASA to my ip via the inside interface, but the problem with this is a) it throws the configs out of sync and b) causes issues when the firewalls fail over.

To be honest, I'm not sure it's possible, but I thought I'd raise it as a query as it's something I've got stuck with a couple of times.

 

[North323]

i am not sure that is possible either. sorry...out of my scope of knowledge

 

[mdc1973]

No problem, appreciate you taking the time to respond

Anyone know if this is possible?

 

[North323]

the more i think about it..the secondary firewall may see that packets as being spoofed. have you tried opening up a TAC case?

 

[mdc1973]

Yes, the spoofing issue has occurred to me- though I think it's related to a route back which raises its own set of problems...

I think I may need to raise a TAC case for it...

Thanks again.

 

[Supergrrover]

you should be able to do it without a problem. can you post a whole configs (scrubbed of passwords and mask the middle 2 octets of public ips.)

are these a failover pair by chance?

Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[mdc1973]

Yes, it's a failover pair. Scrubbed config below (removed irrelevant parts as well for ease of viewing):

:
ASA Version 8.2(1)
!
!
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 213.x.x.62 255.255.255.240 standby 213.x.x.61
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.1.0.1 255.255.255.0 standby 10.1.0.2
!
interface GigabitEthernet0/3
description LAN/STATE Failover Interface
!
same-security-traffic permit intra-interface
access-list inside-in extended permit ip 10.1.0.0 255.255.255.0 any log notifications
access-list inside_nat0_outbound extended permit ip 10.1.0.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list outside_cryptomap_10 extended permit ip 10.1.0.0 255.255.255.0 10.0.0.0 255.0.0.0
failover
failover lan unit primary
failover lan interface faillink GigabitEthernet0/3
failover key ***
failover replication http
failover link faillink GigabitEthernet0/3
failover interface ip faillink 172.16.254.1 255.255.255.252 standby 172.16.254.2
global (outside) 1 interface
nat (inside) 1 10.1.0.0 255.255.255.0
nat (inside) 0 access-list inside_nat0_outbound
access-group inside-in in interface inside
route outside 0.0.0.0 0.0.0.0 213.x.x.57 1
aaa-server tacacs protocol tacacs+
aaa-server tacacs (inside) host 10.5.1.85
key ******
aaa authentication enable console tacacs LOCAL
aaa authentication http console tacacs LOCAL
aaa authentication serial console tacacs LOCAL
aaa authentication ssh console tacacs LOCAL
http server enable
http 10.1.0.0 255.255.255.0 inside
http 10.5.0.0 255.255.0.0 inside
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4108000
crypto ipsec security-association replay disable
crypto map outside_map 10 match address outside_cryptomap_10
crypto map outside_map 10 set peer 94.x.x.212
crypto map outside_map 10 set transform-set ESP-AES-256-SHA
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400
telnet timeout 5
ssh 94.x.x.212 255.255.255.255 outside
ssh 10.1.0.0 255.255.0.0 inside
ssh 10.5.0.0 255.255.0.0 inside
ssh timeout 60
console timeout 0
management-access inside
tunnel-group 94.x.x.212 type ipsec-l2l
tunnel-group 94.x.x.212 ipsec-attributes
pre-shared-key *

I can't honestly see how it can be achieved though- as the secondary has the same config as the primary, when my ssh packet arrives on the inside interface, it's routed back via the default route which is the outside interface, rather than back to the primary and across the tunnel. But if you know of a way round this (and I've tried adding a route just to the secondary, but it's not an option I can run with permanently for various reasons), I'd be most interested.

Cheers.

 

[North323]

i would be interested in solution as well