AnyConnect disables native IPv6 when connected.

[Jonatan Jonasson]

Hi,

I'm working in a dual-stack environment.

So I'm natively using IPv6 (and v4 for that matter) to connect to different resources/hosts.

Whenever I use AnyConnect to connect to a remote location, all local/native IPv6 functionality stops working.

The gateways I'm connecting to with AnyConnect are not providing any ipv6 connectivity or addressing.

So to be clear, my question is not about getting ipv6 to work over anyconnect, or being able to connect using anyconnect via ipv6.

It's just that whenever I connect somewhere via AnyConnect I lose ALL my IPv6 connectivity.

I cannot even ping my gateway via either the link-local address or the global address.

c:\>ping fe80::217:eff:fea0:89c1

Pinging fe80::217:eff:fea0:89c1 with 32 bytes of data:

PING: transmit failed. General failure.

PING: transmit failed. General failure.

If I disconnect the AnyConnect client, this works fine.

It should be noted that when I'm connecting with AnyConnect I'm getting a limited split-tunnel list in return, not "tunnel everything".

All the information I find relates to using AnyConnect to transport IPv6...

Anyone that has a simular problem or can point me in the right direction to solve this problem?

I'm using AnyConnect version 3.0.4235 on Windows7 (64bit)

[Shilpa Gupta · Accepted solution]

Hi,

As per my understanding of the issue , you are working on dual-stack environment. When you use AnyConnect to connect to a remote location, all local/native IPv6 connectivity stops working.

And if you disconnect the client, everything starts working. I researched and found the following:-

In a dual stack or a dual interface environment, the IPv6 traffic would also be sent through the IPv4 AnyConnect tunnel since this is the default behavior and its not fixed yet. 
Although we can provision IPv4 split tunneling, there is no capability to do IPv6 split tunneling on the ASA. So until IPv6 split tunneling rules are available via the ASA, the client will not support arbitrary leaking of IPv6 data outside of

the tunnel. This is true even if ipv6 is not configured for anyconnect.

So to sum up, the AnyConnect client does not support split-tunneling of the IPv6 traffic.  All IPv6 traffic must go over the AnyConnect tunnel (ie TunnelAll).  If you are not supporting IPv6 over the tunnel, you will not be able to access IPv6 resources when connected.  There is currently an enhancement request in place to support split-tunnel on IPv6 - bug ID CSCtb74535.  You can reference the details of this bug ID via our Bug Toolkit:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtb74535

I hope it helps.

Thanks,

Shilpa

[Fabian L]

This discussion is still the first hit when searching on this issue. I ran into the same issue with ASA version 9.1(5) and Annyconnect client 3.1.05160.

bug CSCtb74535 still shows 'Known Fixed Releases: (0)'

If you don't want to tunnel IPv6 traffic but also don't want to break ipv6 connectivity for the enduser:

- just configure an ipv6 pool (with an unused ipv6 subnet)
- include it in the tunnel-group general-attirbutes as ipv6-address-pool
- create or update an extended accesslist for split tunneling, include the ipv4 subnet(s) which you do want to tunnel and add the bogus ipv6 subnet
- include the accesslist in the group-policy attributes split-tunnel-network-list
- ipv6-split-tunnel-policy tunnelspecified

[Ari2]

Thanks. This helped me a lot.

One little addition to avoid a problem I had when trying to make this work on ASA version 9.7.

Remember to activate local ipv6 addressing. Otherwise ASA won't give ipv6 addresses to Anyconnect clients even if ipv6-pool is created and set into tunnel-group or group-policy. The error message you would get in ASDM debug log is something like this: "ipv6 local pool address assignment disabled".

ipv6-vpn-addr-assign local

Source: https://www.cisco.com/c/en/us/td/docs/security/asa/asa90/configuration/guide/asa_90_cli_config/vpn_addresses.html#35831

[bcoverstone]

Since this post still comes up on google searches, I wanted to mention that there is a way to fix this.

If you enable client bypass, protocols that are not explicitly used by the VPN will be bypassed so they can be used independently.

Here's an example of the config:

group-policy xxxxxxxxx attributes
client-bypass-protocol enable

[PeterLMSD]

I wonder if this is related to my issue I found with the newer model HP laptops? General Failure when pinging hostname while on VPN - Cisco Community