Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a machine for connecting via Cisco SSL VPN (\\speeder).

i can ping our our speeder on 10.0.0.3:

enter image description here

The routing table on \\speeder shows the multiple IP addresses we have assigned to it:

enter image description here

After connecting with the Cisco AnyConnect VPN client:

enter image description here

we can no longer ping \\speeder:

enter image description here

And while there are new routing entries for the Cisco VPN adapter, no existing routing entries were modified after connection:

enter image description here

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:

enter image description here

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:

enter image description here

As opposed the addresses we use, which are “additional” addresses:

enter image description here

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.

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

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.

share|improve this answer
    
...errrily similar; and maybe might just get fixed with the re-write. –  Ian Boyd Sep 8 '11 at 14:47
add comment

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 and split-tunnel-network-list commands in the relevant group-policy.

share|improve this answer
1  
That was the terminology, "split tunnel", of what was enabled on the server; and it didn't change. ("The RSA token for the SSL_Vendor profile now has split tunneling enabled. This should now allow vendors to access their local LAN when connected") It did allow the local LAN to access the vpn client machine on the "main" IP (whereas before we couldn't) - but it didn't allow connections to the vpn client machines via other IP addresses. –  Ian Boyd Sep 2 '11 at 21:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.