VPN Client broken in IOS 15?

Scott Pettit · ‎03-08-2010

Hi,

On the UC520 with both IOS 15.0(1)XA1 and XA1a, the VPN client seems to be broken? The moment I upgrade from 12.4(24)YB4 to 15.0, the VPN client can connect but there is no data transfer. If I downgrade to 12.4(24) again everything is fine. I really want to upgrade to IOS 15 to fix a number of other bugs that are annoying me but I can't do so if the VPN client does not work. AnyConnect still works however this gives us major issues for users with IP Communicator.

Can anyone confirm if this is a bug? I can't find any mention of it in the bug toolkit.

-Scott

John Platts · ‎03-08-2010

I had successfully connected to UC520 units running the 15.0(1)XA1a release with Cisco VPN Client 5.0.05.0290 without any problems. I believe that the Easy VPN server, which allows VPN clients to connect to the UC520, is behaving properly in 15.0(1)XA1a, which is included in the 8.0.1 software pack. What version of the Cisco VPN Client are you using? I am not aware of any Easy VPN bugs in 15.0(1)XA1a, and I am able to connect to devices behind the UC520 successfully with IOS 15.0(1)XA1a.

I believe that the problem is really a configuration issue, especially since I have been able to successfully connect to UC520 units running 15.0(1)XA1a with Cisco VPN Client 5.0.05.0290 without any data transfer problems. Could you please e-mail me the UC520 config to jplatts@ipdimensions.com.

dprzywara · ‎03-08-2010

Hey man,

I had the same problem you did last week and opened up a TAC case. The problem after upgrading I was told was with split tunneling enabled, the virtual tunnel inerface uses the split tunneling ACL as an access-list. The resolution was adding the VPN DHCP pool to the split tunnel ACL. For instance:

Original ACL had these 2 networks for split tunneling:

Extended IP access list 100
20 permit ip 192.168.254.0 0.0.0.255 any
30 permit ip 192.168.10.0 0.0.0.255 any

New ACL with the VPN DHCP pool:

Extended IP access list 100
    10 permit ip 192.168.250.0 0.0.0.255 any (383920 matches)
    20 permit ip 192.168.254.0 0.0.0.255 any
    30 permit ip 192.168.10.0 0.0.0.255 any

The TAC engineer didn't give me a bug ID but here is my service request for reference: 613760695

Scott Pettit · ‎03-08-2010

Sounds exactly like my problem dprzywara, I use a virtual interface for my VPN Client so this could be a resolution for me. I will re-attempt my software upgrade tonight and report back - is this a bug or is it a new "feature"?

Scott Pettit · ‎03-08-2010

Works! Thanks, this had been annoying me for some time

dprzywara · ‎03-08-2010

Awesome! The TAC engineer said it was a bug and should be fixed in the 15.x T train of IOS releases.

Steven DiStefano · ‎03-09-2010

I think maybe this could be: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCte69681

Also to be fixed in 15.0(1)XA2. Is a Sev 2 Defect.

I have heard that I must disable split tunneling on my VPN Server on the UC500 to get the VPN to work because of this bug, but I like your TAC workaround better.

Thanks for the discussion.

Steve

brian.russell31 · ‎03-09-2010

Hi Guys,

I have performed the upgrade to 8.0.1 with the new IOS image and I have recieved the same issue, I can no longer VPN back into my device.

I dont even have split tunneling enabled...

I have logged onto the CCO and can not find the new fixed IOS even though the report says it is fixed....

Can someone point me in the right direction?

Many Thanks

Brian

Steven DiStefano · ‎03-09-2010

Hi Brian, did you try the workaround given in the original case for your DHCP client pool?

For some reason the ACL being used for split-tunneling was being applied to the
Virtual-access interface as an access-group and it was dropping the packets. As a
workaround I added the pool of addresses for the VPN clients in that ACL as line 1 and
were were able to pass traffic:

AFS-UC520#sh access-list 100
Extended IP access list 100
    1 permit ip 192.168.250.0 0.0.0.255 any (42 matches)
    10 permit ip 192.168.254.0 0.0.0.255 any
    20 permit ip 192.168.10.0 0.0.0.255 any

bjames · ‎03-09-2010

Interesting post, for my own knowledge by split tunneling do you mean hairpinning?

Thanks,

Bob James

Steven DiStefano · ‎03-10-2010

I mean setting the VPN server so that only interesting traffic from the remote site comes to the UC500 over the tunnel, and other internet connections are made directly from the teleworker router to the cloud, without coming to UC500. Interesting traffic the data vlan, voice vlan and CUE interface in this case.

This is built in the CCA VPN Server configuration on the UC500

Steve

bjames · ‎03-10-2010

OK I understand this is the ACL pushed to clients to allow them to split tunnel...

I assume you can also hairpin once you come in via the tunnel (go back out to the Internet) as well.

Thanks

Bob James

rgarcia · ‎03-25-2010

Regarding this issue, i´ve recently updated to 8.0.2, IOS 15.0.(1)XA2, I read the following in this software pack release notes "TCP over IPsec issue with EZVPN session Traffic through EZVPN tunnel fails with Split-tunneling", I just wonder if this fix is related to this behavior.

After the upgrade split tunnel "interesting traffic" is still not flowing between UC520 and VPN software clients, I´ve tried the proposed TAC workaround already with no success.

Are there any other suggestions or workarounds?, if the issue is fixed in this software release, are there any additional instructions regarding ACL´s.

This issue is causing some headaches in our customers, thanks in advance for your help.

Steven Smith · ‎03-25-2010

The 15.0.1XA2 IOS fixed a known problem with split tunneling and using a virtual-template interface, which happens to be the type of configuration the CCA uses to configure the UC500. If you are using CCA and still having problems, I would delete the VPN configuration and readd using CCA.

rgarcia · ‎03-25-2010

Thanks for the quick reply Steven, i will try it right now, i´m using CCA 2.2.2, as you say I understand the issue has been fixed in this IOS release. Anyway, thanks for your support, I will post my conclusions.

Thanks,