My IT department just succeeded in the Herculean task of getting both Cisco and our VPN provider to admit the problem existed and was caused by the VPN, and got Cisco to provide a solution that our VPN provider had to implement. VPN settings are definitely not my strong suit, but he sent me this excerpt from Cisco's docs:
Configure IPv4 or IPv6 Traffic to Bypass the VPN
You can configure how the AnyConnect client manages IPv4 traffic when the ASA is expecting only IPv6 traffic or how AnyConnect manages IPv6
traffic when the ASA is only expecting IPv4 traffic using the Client Bypass Protocol setting.
When the AnyConnect client makes a VPN connection to the ASA, the ASA can assign the client an IPv4, IPv6, or both an IPv4 and IPv6 address.
If Client Bypass Protocol is enabled for an IP protocol and an address pool is not configured for that protocol (in other words, no IP address for that protocol was assigned to client by the ASA), any IP traffic using that protocol will not be sent through the VPN tunnel. It will be sent outside the tunnel.
If Client Bypass Protocol is disabled, and an address pool is not configured for that protocol, the client drops all traffic for that IP protocol once the
VPN tunnel is established.
For example, assume that the ASA assigns only an IPv4 address to an AnyConnect connection and the endpoint is dual stacked. When the endpoint attempts to reach an IPv6 address, if Client Bypass Protocol is disabled, the IPv6 traffic is dropped. If Client Bypass Protocol is enabled, the IPv6 traffic is sent from the client in the clear.
If establishing an IPseç tunnel (as opposed to an SSL connection), the ASA is not notified whether or not IPv6 is enabled on the client, so ASA always pushes down the client bypass protocol setting.
You configure the Client Bypass Protocol on the ASA in the group policies.
