Hi there

The anyconnect NAT rule is above the Site to Site rule, I looked at he packet tracer but it didn't reveal anything, If the source is anyconnect (wan) attempts to pass to lan with or without the target in the site to site acl it says denied, and when the target it not in the acl it also shows denied, even though it works in practice.

Other IPs in the range seem to work just not the one that is part of the site to site acl. 

I have played around with the wan part of the rule and it come back all working, the only thing that looks off is when the target IP is part of the VPN acl a static route is added to the routing table in the same way as the anyconnect connected addresses.

Both point at the same WAN gateway.

For AnyConnect clients to connect to a resource that is across the site-site VPN on the ASA, there must be an (outside,outside) NAT rule. Do you have that?

Hi there thanks for the response.

Do you mean

(anyconnect ip range -> far site IP range) no nat on outside interface?

I have

(anyconnect ip range -> local site IP range)  no nat

(local site IP range -> anyconnect ip range)  no nat

(anyconnect ip range <> anyconnect ip range) no nat

(anyconnect ip range -> Far site IP range)  no nat

(far site IP range -> anyconnect ip range)  no nat

(local site IP range -> Far site IP range)  no nat

(far site IP range -> local site IP range)  no nat

I think some is unnecessary but it still doesn't affect the outcome.

I wasn't planning to implement anyconnect to far end at this stage, I'm still trying to understand the logic of the fault.

as its anyconnect to local site while local site host ip is a member on the site to site acl in the destination location.

I would assume it would go from anyconnect to the local site, then onto the switch port of the local site even regardless of its acl inclusion in a site to site if neither send or receive was a included in the acl.

Another curiosity is the ASA can't ping the ip connected to the lan interface while the ACL allow on the site to site is in place.

For purposes of NAT the AnyConnect clients' addresses are considered outside as that is where their traffic enters the ASA (even though they are assigned a private IP that one might consider "inside" the network.

So the nat needs to be:

nat (outside, outside) source static vpnpool_range vpnpool_range destination static farsite_range farsite_range no-proxy-arp route-lookup

I think I've tried that, it doesn't seem to affect he issue, if I change the destination host object to a network range it solves the issue.

I'm staring to think this possibly an ios bug,

when I add the destination host object that's in the lan to the acl, the asa crates a route static route like 10.0.15.60 255.255.255.255 and attaches it to the WAN interface rather the lan.

The FW passes the traffic to the wan interface rather than the lan interface, that's the point when the firewall cant ping the ip either. if I change the host object for a network/24 everything continues working.

I'm thinking my best bet is to see about updating the ios on the firewall before I do much more with this.

I'm guessing the routing change from lan to wan is not expected behaviour where a host has a firewall entry.