vpnc no response from target after upgrade to 4.3.20 and 4.3.22

[Dave Musci]

Host is Win7, Guest is OEL6. Have been using vpnc to connect to Cisco VPN for several years. After upgrade of VirtualBox from 4.3.12 to 4.3.20 it stopped working with "vpnc: no response from target". Restarting guest and host did not help. Downgrading to VirtualBox 4.3.12 resolved the issue. Tried upgrading to VirtualBox 4.3.20 again, just in case a driver got hosed during first attempt, but it did not work. Reverted back to 4.3.12 and having been running that for months now.

Today I tried upgrading to VirtualBox 4.3.22, hoping the issue would be fixed, but it still doesn't work. I tried the same reboot guest and host after upgrade but no luck. Reverted back to 4.3.12 and it works fine now.

[Frank Mehnert]

Please attach a VBox.log file from such a VM session as well as the VBoxStartup.log file (located at the same directory as VBox.log).

[Dave Musci]

VBoxSVC.log from session

[Dave Musci]

vbox.log

[Dave Musci]

vboxstartup.log (zipped)

[Dave Musci]

sorry for not responding for so long - I assumed if there was follow-up on the ticket I would be notified, so I never checked back.

I just tried the latest and greatest version of virtualbox 4.3.28 - and I'm still having the same problem.

thanks

[keithf4]

I'm having this exact same problem. Upgraded from 4.3.12 to 4.3.26 and lost vpnc connectivity. Tried 4.3.28 as well. Attached logs from that. Downgraded to 4.3.12 and things are working again. Attached logs for that as well.

[keithf4]

Forgot to mention my Guest OS is Linux Mint 17 and host OS is Windows 8.1. I normally just use the command line vpnc interface but also tried the Network Manager interface to connect with 4.3.28. Neither worked.

[Valery Ushakov]

Do you have network connectivity in the guest in general, or is it only vpnc that's broken?

[Dave Musci]

yes, I have network connectivity. it is just vpnc that is broken.

[Valery Ushakov]

Please, can you provide packet captures from both guest and host sides?

[Dave Musci]

do you want packet captures from when it's working (v4.3.12) or not working (v4.3.28)?

I confirmed the ports needed for Cisco VPN connectivity. It is using UDP port 500 for IKE negotiation, and then tunnels the IPSec data traffic using UDP port 4500.

[Valery Ushakov]

When it's not working, primarily. Though if you can do both to have a reference that would be great. A first few seconds into the successful connection would be enough. Thanks.

I assumed if there was follow-up on the ticket I would be notified

Make sure you have notifications turned on in preferences. IIRC, they are opt-in.

[Dave Musci]

tcpdump from guest of vpnc no response using virtualbox 4.3.28

[Dave Musci]

wireshark capture of host when vpnc no response using virtualbox 4.3.28

[Dave Musci]

captures attached for guest and host

[Valery Ushakov]

Can you provide a pcap file, not text output, from the guest too?

[Dave Musci]

yes, but it will be a day or two. spent a while having to uninstall 4.3.12, installing 4.3.28 for the test, then uninstalling 4.3.28 and reinstalling 4.3.12 so I can work. no more time today to spend on this, unfortunately :(

I did see a posting on a virtualbox forum where someone reported issues with NAT in general after upgrading past 4.3.12 and it mentioned that some security hardening was done after 4.3.12. maybe this is related, since the packets aren't leaving the guest OS?

[Valery Ushakov]

Right, that's why I asked if you have network connectivity in the guest in general. Some setups that have an extra dll loaded along with winsock will exhibit this complete lost of connectivity.

The dump from the guest (txt file) actually looks wrong. It looks like it was taken with "NAT Network" attachment. 10.0.2.4 address of the guest and its asking ARP for 10.0.2.1 are the tells.

[Dave Musci]

I did switch to NAT Network just to see if it would make a difference, but it did not. I guess you need me to re-do both captures with networking set to NAT?

[Valery Ushakov]

If both NAT and NAT Network (completely unrelated implementations) have the same problem, it's very likely that the problem is somewhere on the host or in the guest.

Guest tries to connect to 56.105.128.196:500, but I don't see any matching packets on the host side. Any static routes in the guest, perhaps? Is the host multihomed and you are capturing on the wrong interface?

[Dave Musci]

adding four new files, 2 no response files generated using vbox 4.3.28 and 2 success files generated using 4.3.12. pcap files are tcpdump on linux guest. pcapng are wireshark on windows host.

[Dave Musci]

linux guest successful vpnc connection using 4.3.12

[Dave Musci]

windows host successful vpnc connection using 4.3.12

[Dave Musci]

linux guest no response from vpnc connection using 4.3.28

[Dave Musci]

windows host no response from vpnc connection using 4.3.28

[Dave Musci]

definitely no traffic on the host interface outbound to VPN when using 4.3.28, but it does show up on same host interface when using 4.3.12.

networking set to NAT for both tests.

[Dave Musci]

any updates on this?

[Dave Musci]

tried 4.3.30 and 5.0 but neither of them worked.

any estimate on when a working build will be ready?

or do I need to move to another VM host solution?

[Valery Ushakov]

What are your host's and guest's MTUs? I think your problem is that your host's MTU is smaller than the guest's. Your initial packet is 1326 bytes, but your host only seems to have MTU of 1314.

4.3.12 worked because proxy ignored DF flag on UDP packets from the guest, so it was happily fragmented by the host. Since 4.3.16 DF is propagated, so the host cannot send that 1326 bytes initial datagram.

[Dave Musci]

changing the MTU on the host to 1500 did the trick.

Thanks for your help.

For anyone else who needs to do the same, if you want to change the MTU on your Windows host, here's the commands:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1500 store=persistent

netsh interface ipv4 set subinterface "Wireless Network Connection" mtu=1500 store=persistent

You should get "Ok" back from those commands. To verify the settings, run: netsh interface ipv4 show subinterface "Wireless Network Connection"

[Dave Musci]

just to qualify my response, this was using VirtualBox 5.0, but it sounds like the fix should work on any version after 4.3.12 that was experiencing the problem.

[Dave Musci]

important follow-up to my previous posting about using netsh. even with persist=store, it does not save the settings to the registry, so they are lost after reboot. to make a permanent change that will survive a reboot, you need to modify the registry manually. the settings will be under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces

There will be many adapters listed. For me, the easiest way to find the adapters I wanted to update was to use "ipconfig /all" and find the IP addresses assigned to the IP addresses I wanted to change. in the case of a wireless adapeter, those are a bit easier to find in the registry as they will have subfolders, one for each wireless network profile you have saved.

the key you will want to change is "MTU"

[keithf4]

Just want to confirm the MTU fix worked for me as well. Thanks to davem72 for the detailed instructions on how to fix it! 5.0 is running a TON faster than 4.x as well, so good news all around!