Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1550
Views
10
Helpful
8
Replies

ASAv Remote Access VPN clients cannot connect to internal hosts

JMJr
Level 1
Level 1

‎09-05-2019 02:46 PM - edited ‎02-21-2020 09:44 PM

Hi community,

 

I configured AnyConnect remote Access VPN on ASAv in the AWS cloud, and remote clients will use Clientless or VPN client to connect to the VPN server. The VPN is working however I cannot get the VPN clients to RDP or ssh to bastion hosts on the internal network. VPN is configured over the management interface. The full configuration is included as an attachment.

 

Trying to get remote clients to RDP or ssh to the following internal bastion hosts after connecting to the VPN:

 

object network LinuxHost-1.206
host 10.0.1.206
object network rdp-host-1.7
host 10.0.1.7
object network rdp-host-1.171
host 10.0.1.171

 

My ACL's:

access-list management_access_in extended permit tcp any4 host 10.0.1.206 eq ssh
access-list management_access_in extended permit tcp any4 host 10.0.1.7 eq 3389
access-list management_access_in extended permit tcp any4 host 10.0.1.171 eq 3389

access-group management_access_in in interface management

 

NAT statement:

nat (Inside,management) source static Anyconnect-Inet Anyconnect-Inet destination static VPN VPN

 

Same-security-traffic configured:

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

 

Sysopt connection permit-vpn is configured

 

I am a newbie and I don't know what I am missing in order to have the remote clients establish an RDP or ssh connection. Please assist and guide me here.

\

Thanks in advance.

Labels:
Preview file
8 KB
0 Helpful
8 Replies 8

user1024
Level 1
Level 1

‎09-05-2019 02:56 PM

Where is the 10.0.1.0 network located? What is the mask? I don't see any routes in the configuration for it. Also your split tunnel ACL does not have the 10.0.1.0 network only 10.0.0.0/24, access-list SplitTunnel standard permit 10.0.0.0 255.255.255.0

JMJr
Level 1
Level 1
In response to user1024

‎09-05-2019 03:05 PM

The 10.0.1 network is located in the cloud. It is the internal private IP off the management interface. The mask is 255.255.255.0. 

 

How would I configure that 10.0.1 route?  Would this be correct?   route inside 10.0.1.0 255.255.255.0 10.0.1.1 1

 

So, I would need to also specify another ACL for the split-tunnel 10.0.1....does this need to be applied to the group policy or just configured globally?

 

Thanks..

0 Helpful

JMJr
Level 1
Level 1
In response to JMJr

‎09-05-2019 03:20 PM

Tried to add a route:   route inside 10.0.1.0 255.255.255.0 10.0.1.1 1

 

Get error: Cannot add route, connected route exists

 

Routes are below:

Gateway of last resort is 52.222.73.114 to network 0.0.0.0

 

S*       0.0.0.0 0.0.0.0 [1/0] via 52.222.73.114, management

                         [1/0] via 10.0.1.1, management

S        10.0.0.0 255.255.0.0 [1/0] via 10.0.3.1, Inside

C        10.0.1.0 255.255.255.0 is directly connected, management

L        10.0.1.129 255.255.255.255 is directly connected, management

S        10.0.2.0 255.255.255.0 [1/0] via 10.0.3.1, Inside

C        10.0.3.0 255.255.255.0 is directly connected, Inside

L        10.0.3.227 255.255.255.255 is directly connected, Inside

S        10.0.4.0 255.255.255.0 [1/0] via 10.0.3.1, Inside

C        15.200.26.208 255.255.255.240 is directly connected, Outside

L        15.200.26.219 255.255.255.255 is directly connected, Outside

0 Helpful

JMJr
Level 1
Level 1
In response to JMJr

‎09-06-2019 07:46 AM

Still cannot connect to the internal hosts in the environment...

 

Created new ACL's (splittunnel) .....

 

access-list splittunnel standard permit host 10.0.1.206

access-list splittunnel standard permit host 10.0.1.7

access-list splittunnel standard permit host 10.0.1.171

access-list SplitTunnel standard permit 10.0.0.0 255.255.255.0

access-list SplitTunnel standard permit 10.0.1.0 255.255.255.0

 

and assigned to group policy, but still no access....

 

Group-policy xxxxxx attributes

Added: split-tunnel-network-list value SplitTunnel

 

 

 

 

0 Helpful

JMJr
Level 1
Level 1
In response to JMJr

‎09-06-2019 11:55 AM

Anyone....who might be able to help....???

 

Thanks

0 Helpful

user1024
Level 1
Level 1
In response to JMJr

‎09-06-2019 12:29 PM

It's a bit odd that you are attempting to access hosts on the same network as the VPN interface. What is the gateway for the devices on the 10.0.1.0/24 network? You don't need the 10.0.0.0/24 network in your split tunnel ACL because that is the VPN pool. The split tunnel ACL is for the networks you want to access via the VPN so you only need the 10.0.1.0/24 network. You will also need to add sysopt connection permit-vpn to bypass any interface ACLs. You should also remove the VPN filter for testing purposes.

JMJr
Level 1
Level 1
In response to user1024

‎09-06-2019 12:58 PM

Yes, I agree it is odd. It's in the AWS cloud and the subnet for the internal networks are off the inside private management eth0 interface. 

The gateway for the subnet is 10.0.1.1, the inside private IP.

I'll remove the 10.0.0.0/24 from the split tunnel and the VPN filter command.

I added the sysopt connection permit-vpn command already with same result.

 

One question that I have is that when I use the nat command, since the traffic is coming in on the management int and then using the inside private ip of the same interface, will nat (management,management) xxxxx xxxx possibly work since that is where the 10.0.1 subnet lives?

 

Thanks...

0 Helpful

JMJr
Level 1
Level 1
In response to JMJr

‎09-06-2019 01:58 PM

Packet tracer output....any thoughts? I understand this is being dropped by an ACL but not sure which one it is...

 

M-ASAv1(config)# packet-tracer input management icmp 10.20.0.2 8 0 10.0.1.7 de$

 

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7f3827e42860, priority=13, domain=capture, deny=false

hits=764959, user_data=0x7f381d37a7c0, cs_id=0x0, l3_type=0x8

src mac=0000.0000.0000, mask=0000.0000.0000

dst mac=0000.0000.0000, mask=0000.0000.0000

input_ifc=management, output_ifc=any

 

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7f381c1a7730, priority=1, domain=permit, deny=false

hits=36864364, user_data=0x0, cs_id=0x0, l3_type=0x8

        src mac=0000.0000.0000, mask=0000.0000.0000

        dst mac=0000.0000.0000, mask=0100.0000.0000

        input_ifc=management, output_ifc=any

              

Phase: 3      

Type: UN-NAT 

Subtype: static

Result: ALLOW

Config:       

nat (Inside,management) source static Anyconnect-Inet1 Anyconnect-Inet1 destination static VPN VPN

Additional Information:

NAT divert to egress interface Inside

Untranslate 10.0.1.7/0 to 10.0.1.7/0

              

Phase: 4      

Type: ACCESS-LIST

Subtype:      

Result: DROP 

Config:       

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7f381d0b1e60, priority=11, domain=permit, deny=true

        hits=4, user_data=0x6, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

        input_ifc=management, output_ifc=any

              

Result:       

input-interface: management

input-status: up

input-line-status: up

output-interface: Inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

 

ACL's below:

 

M-ASAv1(config)# sh run access-l

access-list vpn-acl extended permit ip any any log

access-list AnyConnect_Client_Local_Print extended permit ip any4 any4

access-list management_access_in extended permit tcp any4 host 10.0.1.206 eq ssh

access-list management_access_in extended permit tcp any4 host 10.0.1.7 eq 3389

access-list management_access_in extended permit tcp any4 host 10.0.1.171 eq 3389

access-list VPN_CLIENTS_OUT extended permit ip object VPN any

access-list splittunnel standard permit host 10.0.1.206

access-list splittunnel standard permit host 10.0.1.7

access-list splittunnel standard permit host 10.0.1.171

access-list SplitTunnel standard permit 10.0.0.0 255.255.255.0

access-list SplitTunnel standard permit 10.0.1.0 255.255.255.0

access-list SplitTunnel standard permit 10.0.3.0 255.255.255.0

access-list SplitTunnel standard permit 10.0.4.0 255.255.255.0

 

** Since traffic is coming into Management int and leaving via the inside private ip on the Management int via 10.0.1.1/24, should (inside,) be replaced with management..?

 

NAT statements below:

nat (Inside,management) source static Anyconnect-Inet3 Anyconnect-Inet3 destination static VPN VPN

nat (Inside,management) source static Anyconnect-Inet4 Anyconnect-Inet4 destination static VPN VPN

nat (Inside,management) source static Anyconnect-Inet1 Anyconnect-Inet1 destination static VPN VPN

nat (Inside,management) source static Anyconnect-Inet Anyconnect-Inet destination static VPN VPN

!

nat (Inside,management) after-auto source dynamic any interface

 

 

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents