DAP - Connection from inside to AnyConnect Client

[hash2k2]

Hi,

we are using AnyConnect in combination with dynamic access policies and it's working fine.

Now we need to have tcp connection build up from a server on inside interface to a anyconnect Client.
But this blocked by the ACL.

syslog message is: 106103 access-list SSLVPN_ACL-PowerUser denied tcp for user <unknown> inside/10.x.x.x -> outside/10.29.x.x ...

What do I have to configure to allow this traffic?

We are running on 9.10(1)17 - 5525x

[Pulkit Saxena]

Hi,

Once you are connected, ideally the traffic from inside server should be allowed to anyconnect client without any issues unless we have an explicit ACL on inside interface or VPN-filter.
The log that you have shared points to a VPN-filter configuration :
https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslogs1.html#con_6393188

106103
Error Message%ASA-4-106103: access-list acl_ID denied protocol for user username interface_name /source_address source_port interface_name /dest_address dest_port hit-cnt number first hit hash codes

Explanation A packet was denied by an access-list that was applied through a VPN filter. This message is the VPN/AAA filter equivalent of message106023.

So I believe we need to check the VPN-filter ACL and allow this traffic there.

-
Pulkit

Keep rating helpful posts.

[hash2k2]

Hi,

thank you for your reply.

Currently we have an acl configured under "Dynamic Access Policies". In this ACL we just have permits like "Network SSLVPN -> internal server". Do I have to add a line like "permit internal sever -> Network SSLVPN" to allow traffic from inside to the vpn clients?

[Pulkit Saxena]

It has to be either the DAP ACL or the VPN filter, can you check where you have this configured, as per your log :
access-list SSLVPN_ACL-PowerUser denied tcp for user <unknown> inside/10.x.x.x -> outside/10.29.x.x
On basis of that, you can make the change.

-
Pulkit

[hash2k2]

okay,

since we havn't configured a vpn-filter on the group policy, it only could be the DAP ACL. I will add an entry like internal server ip -> network sslvpn and test it.

[hash2k2]

This does not solve the problem. I still get the syslog message like in my first post.

[Pulkit Saxena]

Check where exactly this ACL is configured.
Also best way would be to run a "packet-tracer" from the server IP as source to destination IP of anyconnect client once client is connected, and check where it is getting blocked.

-
Pulkit

[hash2k2]

okay, here is a packet-trace:

packet-tracer input inside tcp 10.29.7.126 20000 10.29.90.$

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.29.90.4 using egress ifc outside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static DM_INLINE_NETWORK_65 DM_INLINE_NETWORK_65 destination static Netzwerk-VPNSSL Netzwerk-VPNSSL no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 10.29.90.4/135 to 10.29.90.4/135

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit object-group DM_INLINE_SERVICE_49 object VSRV-TEST object Netzwerk-VPNSSL
object-group service DM_INLINE_SERVICE_49
service-object icmp
service-object tcp destination eq 135
service-object tcp destination eq 445
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static DM_INLINE_NETWORK_65 DM_INLINE_NETWORK_65 destination static Netzwerk-VPNSSL Netzwerk-VPNSSL no-proxy-arp route-lookup
Additional Information:
Static translate 10.29.7.126/20000 to 10.29.7.126/20000

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map sfr
match access-list sfr_redirect
policy-map global_policy
class sfr
sfr fail-open
service-policy global_policy global
Additional Information:

Phase: 8
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: WEBVPN-SVC
Subtype: out
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: ACCESS-LIST
Subtype: filter-aaa
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[Pulkit Saxena · Accepted solution]

Hi,

So you can see that the drop happened on "Phase 10" with sub-type "filter-aaa" which is either for VPN-filter or DAP policy.
You need to allow it in your DAP policy and then disconnect and connect again from the client.

-
Pulkit

[hash2k2]

okay, I have added a permit from inside maschines to the vpn network into the DAP policy. The user has reconnected with anyconnect. But still the same syslog message.

Could this be a bug like: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd97319/?rfs=iqvred

There is definitly no vpn-filter added to the DfltGrpPolicy

[hash2k2]

you were correct.

This line solved my issue for a connection from an inside host to a vpn client.

access-list SSLVPN_ACL-PowerUser line 3 extended permit tcp 10.29.90.0 255.255.254.0 eq 9594 host 10.29.7.124

This line is for a connection from 10.29.7.127/32 -> 10.29.90.0/23 Port tcp/9594