anyconnect to site to site routing

[Alan Douglas]

Hi there

I'm looking at a strange issue with a ASA, there is a site to site VPN and an any connect vpn.

The asa is on site 1 where the anyconnect vpn connects, on that site is a domain controller.

Site B is an external vpn site to site which connects to site A and is to have a Domain controller.

Both work independent and at the same time,

The issue is if a rule is added to the fw, to allow domain controllers at each end of the site to site to communicate with each other, the anyconenct VPN can no longer contact the DC's at site A.

I could understand if the destination was a site B, I don't see why including the dc host object for site A in the site to site rule causes it to become inaccessible to the anyconnect VPN.

Has anyone see this sort of issue before?

Thanks

[Marvin Rhoads]

If you used a NAT exemption when allowing the DCs to communicate, it may have been added above the rule that NAT exempts VPN users.

Packet-tracer should show you the ASA logic. Just be sure to use a source IP address that is in the VPN pool but not currently in use by a VPN client.

[Alan Douglas]

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. 

[Alan Douglas]

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.

[Marvin Rhoads]

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?

[Alan Douglas]

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.

[Marvin Rhoads]

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

[Alan Douglas]

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.