cannot ssh an interface: deny IP spoof

[sawasa]

Hi all,

I thought I have fixed one problem but actually I have created another.

I got an ASA 5508, connected to AWS cloud via AWS direct connect, which uses a cross-connect in the datacenter, and communicates via BGP (this is not a VPN). 

AWS net: 10.15.1.1/22
inside net behind the ASA: 10.50.3.1/24

I simply need to let ssh access from a given IP in the AWS cloud to the if-inside of the ASA, for admin purposes.

The connection comes via the directConnect interface, which got an statement for ssh.
But I keep having the message:

Deny IP spoof from 10.15.1.1 to 10.50.3.1 on 
interface directConnect.

My relevant configuration is as following:

!
interface GigabitEthernet1/3.2
description "direct connect to AWS"
vlan 2
nameif directConnect
security-level 0
ip address x.x.x.x 255.255.255.252
!
interface GigabitEthernet1/5
nameif if-inside
security-level 100
ip address 10.50.3.1 255.255.255.0
!

ssh 10.15.1.1 255.255.255.255 directConnect

!

access-list directConnect_access_in extended permit ip host 10.15.1.1 host 10.50.3.1 (it's getting hits)

!

nat (directConnect,if-inside) source static AWS15 AWS15 destination static inside-net inside-net

I don't really undestand why I got this denies. I have read about entering the command no ip verify reverse-path interface for those messages not to be logged, but what I actually need is to accept that ssh to the if-inside.

I feel I'm missing something basic here, thank you if you could shade some light.

[Marius Gunnerud]

As mentioned in your previous post, you cannot connect to an ASA interface that is not the ingress (inbound) interface.  So traffic entering the directConnect interface cannot connect to if-inside interface.  The only way you can do this is to either setup a VPN to the ASA and administrate the ASA over the VPN or setup a jump server on the inside of if-inside interface, connect to the jump server and then administrate the ASA if-inside interface from there.

[sawasa]

Thanks Marius.
Looks like I didn't understand you fully in my prev. post. I understood from your answer that I could also as an option add a ssh statement for the directConnect, now I see that I would have to administrate the ASA from the directConnect interface. I hope this is not a problem for my devops, I'll ask her. 

We actually created the directConnect to get rid of VPNs, so I would like to avoid creating one just for administration.

One thing I quite don't understand is why if the connection with cloud was via VPN through an outside interface I would be able to ssh from outside to if-inside, but since I have configured through the directConnect this is not permitted. 

Thanks again for your help! 

[Marius Gunnerud · Accepted solution]

The reason the direct connect doesn't work is because this is not "to the box" traffic as seen from the ASA perspective.  VPN is seen as "to the box traffic".  In a VPN the traffic terminates on the box itself, therefore it is just encrypted traffic entering the outside interface and not data traffic.  VPN traffic is subject to different, for lack of a better word, rules than regular data traffic.