Problems with Cisco VPN client on 3.x => fixed in SVN

The log file

Ping command, left is guest, right is host.

Replying to zoltanf:

With Vbox 3.0, and 3.0.2, problems appeared with a NAT networking. (on 2.2 and 2.4 everything worked fine). Basically not all packages go trough the NAT. Attached is a log and a screenshot, on left a ping command from the guest, on right ping command from the host.

Ping is ICMP based application, and the picture you've attached could be admired on Windows host only. This behavior caused by problems with ICMP API used only on Windows, we expect that this problem will gone in 3.1 where we will replace ICMP API with sockets like it's done on Unix.

If you suspect packet lost please collect pcap files on guest and host with wireshark (to sent packets was sent from guest and host ). Intermediate networking is also will be helpful.

This is a problem for VPN and such connections (Cisco VPN for example) that breaks after couple of seconds or random. Bridge on the same physical adapter works just fine, only in NAT mode, this problem is evident.

Replying to Hachiman:

Ping is ICMP based application, and the picture you've attached could be admired on Windows host only. This behavior caused by problems with ICMP API used only on Windows, we expect that this problem will gone in 3.1 where we will replace ICMP API with sockets like it's done on Unix.

For ICMP, it is probably true. But, I did not try the PING for fun, I had real problems with the NAT (e.g. cisco VPN breaking up every few seconds to minutes).

If you suspect packet lost please collect pcap files on guest and host with wireshark (to sent packets was sent from guest and host ). Intermediate networking is also will be helpful.

I will collect the data today, and attach.

Replying to zoltanf:

Replying to Hachiman:

Ping is ICMP based application, and the picture you've attached could be admired on Windows host only. This behavior caused by problems with ICMP API used only on Windows, we expect that this problem will gone in 3.1 where we will replace ICMP API with sockets like it's done on Unix.

For ICMP, it is probably true. But, I did not try the PING for fun, I had real problems with the NAT (e.g. cisco VPN breaking up every few seconds to minutes).

What version of you Cisco VPN client?

If you suspect packet lost please collect pcap files on guest and host with wireshark (to sent packets was sent from guest and host ). Intermediate networking is also will be helpful.

I will collect the data today, and attach.

Replying to Hachiman:

What version of you Cisco VPN client?

Cisco VPN client, version is 4.8.02.0010

I have done some further testing today, and also did some network captures that I analyzed (I will attach them here later). It seems that the NAT is working fine with TCP/IP traffic, but with UDP it is a problem where some packets are lost (and a large number, especially if the HOST is connected trough wireless connection to the internet).

Cisco VPN in my configuration uses tunneling on UDP port 4500.

thank you for information

Capture, inside of the cisco tunnel. This shows some packets re-transmited inside the tunnel.

I have attached now a file, with a capture of network traffic inside the Cisco VPN tunnel. This is the best case scenario, as my host is currently running on LAN and not on wireless (when the host is on wireless, the number of re-transmited packages grows substantially).

I know that this capture is not of much use, as it is inside the tunnel and not outside where the UDP packages are actually exchanged. I will try now to do a dump of the adapter from VBox.

Capture from virtualbox, nic 1, on NAT, chunk

Attached the nic 1 capture, a junk of it anyway. Since it is UDP, and is encrypted (tunnel data), there is nothing to be seen here.

The trouble is, that UDP, unlike TCP, does not provide a mechanism for detecting dropped packets. You might see the dropped packets on some higher level protocol that uses UDP, but since this chunk is encrypted tunnel traffic, here it is impossible to see. Ah, well, you will probably need to try this with some other app protocol that uses UDP...

Replying to zoltanf:

Attached the nic 1 capture, a junk of it anyway. Since it is UDP, and is encrypted (tunnel data), there is nothing to be seen here. The trouble is, that UDP, unlike TCP, does not provide a mechanism for detecting dropped packets. You might see the dropped packets on some higher level protocol that uses UDP, but since this chunk is encrypted tunnel traffic, here it is impossible to see. Ah, well, you will probably need to try this with some other app protocol that uses UDP...

Right, will try reproduce it on TFTP.

Hichiman,

I don't know what is wrong with comments, but I don't see your last comment here in this ticket history, but did get the notification to email, so I will reply here directly:

---

`i've just thought Cisco clients has logging on board, it might be interesting if Cisco client detects these problems. About retransmit they could be initiated by TCP ... and there could be several reasons for retransmission : expiration, out of order packets deliviring, packet duplication and dropping. please check if it possible to sniff network traffic from Cisco driver with wireshark and logs from Cisco client?

---

About the Cisco wireshark sniffing, I did attach the file earlier. (Cisco Adapter Capture 3.pcap). This was captured inside the VPN tunnel, so you CAN see dropped and retransmitted packages inside this dump. I will check if there is some possibility to enable logging inside Cisco VPN client, and if it loges the dropped packages.

Today, while using the VM in NAT mode, on LAN, I have expirenced several complete networking blackouts, for no apperant reason. I find that here is a ticked open for this already, for 3.0.2., ticket no #4507. Could be releated to this tickets problem...

I am also seeing a problem with the Nortel Contivity VPN client on a Windows XP SP3 guest on a Ubuntu 9.04 hosts. My VPN client is unable to connect to the server in 3.x series (currently 3.0.2). I was able to use the exact same setup on 2.2.4 earlier.

Test build was send for verification

I can confirm that the test build 3.0.3 solves all NAT problems that I had.

Replying to zoltanf:

I can confirm that the test build 3.0.3 solves all NAT problems that I had.

Thank you for feedback

I have also noticed this problem while using VPN Client below there is detailed description just in case if somebody would need to confirm that they have similar symptoms. I was able to work around it by using bridged networking. I will be looking forward using 3.0.3.

After upgrading from VirtualBox version 2.2 to version 3 on Ubuntu host system, IPSec client in Windows guest system has stopped working. At first I blamed IPSec itself or network or Windows install and etc. Latter I narrowed it down to upgrading VirtualBox and have confirmed. I have downgraded it back a couple of time upgraded again. Each time when I was downgrading, problem went away. Each time after upgrading problem was returning.

How it used to work with version 2.2 of Virtual Box before upgrading – connecting to the IPSec gateway for about 10 sec, checking banner text for about 2 sec, connection is established.

Symptoms with version 3 of the VirtualBox after upgrading – Establishing IPSec connection is failing most of the times (~ 1 in 5 times it succeeds). Following scenarios were observed: - Most frequent - Connecting for a long time (~60 sec), switching over to back-up IPSec gateway, connecting for some time (~30 sec), connections is is failing with a message about failed login. - Sometimes - Connecting for a long time (~30 secods), checking for banner text for a long time (~30 sec) after which connection is failing (connection lost message). - Rarely - Connecting for a long time (~30 secods), checking for banner text quickly (~3 sec) after which connection is established.

Additional symptoms on version 3 of VirtualBox: Under Network Connections there is a single network adapter (Local Area Network), which is connected to virtual network adapter of the guest machine (AMD PCNET Family …).

VirtualBox version working with IPSec: 2.2.4 r47978 VirtualBox version failing with IPSec: 3.0.2 r49928

Host Operating System: Ubuntu 9.04 32 bit. Guest operating system: Windows XP MCE 2005 (32 bit). IPSec VPN Software: Nortel Connectivity VPN Client V06_01.054