We have a machine for connecting via Cisco SSL VPN (\\speeder
).
i can ping our our speeder
on 10.0.0.3
:
The routing table on \\speeder
shows the multiple IP addresses we have assigned to it:
After connecting with the Cisco AnyConnect VPN client:
we can no longer ping \\speeder
:
And while there are new routing entries for the Cisco VPN adapter, no existing routing entries were modified after connection:
It is to be expected that we cannot ping Speeder’s IP address on the Cisco VPN adapter (192.168.199.20) because it is on a different subnet than our network (we are 10.0.x.x 255.255.0.0), i.e.:
C:\Users\ian.AVATOPIA>ping 192.168.199.20
Pinging 192.168.199.20 with 32 bytes of data:
Request timed out.
The problem we are experiencing is that we then cannot ping existing IP addresses on \\speeder
:
C:\Users\ian.AVATOPIA>ping 10.0.1.17
Pinging 10.0.1.17 with 32 bytes of data:
Request timed out.
C:\Users\ian.AVATOPIA>ping 10.0.1.22
Pinging 10.0.1.22 with 32 bytes of data:
Request timed out.
C:\Users\ian.AVATOPIA>ping 10.0.1.108
Pinging 10.0.1.108 with 32 bytes of data:
Request timed out.
etc
What’s interesting, and might provide a clue, is that there is one address we can communicate with:
This address we can ping and communicate with:
C:\Users\ian.AVATOPIA>ping 10.0.1.4
Pinging 10.0.1.4 with 32 bytes of data:
Reply from 10.0.1.4: bytes=32 time<1ms TTL=128
What makes this one IP address special? This one IP address has the virtue of being a “main” address:
As opposed the addresses we use, which are “additional” addresses:
To sum up, when the Cisco AnyConnect VPN client connects, it blocks us from all-but-one address associated with the computer.
We need the Cisco Client to stop doing that.
Does anyone know how to make Cisco AnyConnect SSL VPN client stop doing that?
Note: Firepass SSL VPN from F5 Networks does not suffer the same issue.
We've contacted Cisco, and they say that this configuration is not supported.
The Cisco VPN adapter is special, in that in "default" mode, it's designed to send every last bit of network traffic over the tunnel's link. I mirrored that configuration to test, and a normal tunnel actually wouldn't even let me ping the primary address of the local interface.
However, with a split tunnel, where the VPN adapter handles traffic for only specified networks, it seems to be working great for secondary addresses.
If you can, get the connection's configuration changed to be a split tunnel; if your endpoint is an ASA, it'll be
split-tunnel-policy
andsplit-tunnel-network-list
commands in the relevantgroup-policy
.I reported Cisco Bug ID CSCts12090 (CCO required) to Cisco a few weeks ago. I just started using AnyConnect about 6 months ago and have only used version 3.0 and up. Looks like you are using a version earlier than 3.0.
Anyway, the bug I reported is very similar (but worse). AnyConnect is unable to successfully connect when multiple IP's are assigned to the local NIC in certain cases. See the full bug report linked earlier for complete details. It was a confirmed bug and is going to be fixed in AC 3.1. AC 3.1 promises, as I have been told, to be a pretty big rewrite of the local routing table update code that is going to fix this and a slew of other quirks with AC.
While the problem you are experiencing is not exactly like the one I reported in CSCts12090, it is eerily similar.