VirtualBox

Opened 15 years ago

Closed 13 years ago

#4499 closed defect (fixed)

Problems with Cisco VPN client on 3.x

Reported by: Zoltan Fekete Owned by:
Component: network/NAT Version: VirtualBox 3.2.0
Keywords: Cc:
Guest type: other Host type: other

Description

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.

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.

Attachments (4)

VBox.log (54.5 KB ) - added by Zoltan Fekete 15 years ago.
The log file
Capture.JPG (300.6 KB ) - added by Zoltan Fekete 15 years ago.
Ping command, left is guest, right is host.
Cisco Adapter Capture 3.pcap (187.9 KB ) - added by Zoltan Fekete 15 years ago.
Capture, inside of the cisco tunnel. This shows some packets re-transmited inside the tunnel.
nic1 capture.pcap (41.0 KB ) - added by Zoltan Fekete 15 years ago.
Capture from virtualbox, nic 1, on NAT, chunk

Download all attachments as: .zip

Change History (43)

by Zoltan Fekete, 15 years ago

Attachment: VBox.log added

The log file

by Zoltan Fekete, 15 years ago

Attachment: Capture.JPG added

Ping command, left is guest, right is host.

in reply to:  description ; comment:1 by vasily Levchenko, 15 years ago

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.

in reply to:  1 ; comment:2 by Zoltan Fekete, 15 years ago

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.

in reply to:  2 ; comment:3 by vasily Levchenko, 15 years ago

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.

comment:4 by vasily Levchenko, 15 years ago

Summary: Bad NAT reliability on 3.xProblems with Cisco VPN client on 3.x

in reply to:  3 comment:5 by Zoltan Fekete, 15 years ago

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.

comment:6 by vasily Levchenko, 15 years ago

thank you for information

by Zoltan Fekete, 15 years ago

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

comment:7 by Zoltan Fekete, 15 years ago

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.

by Zoltan Fekete, 15 years ago

Attachment: nic1 capture.pcap added

Capture from virtualbox, nic 1, on NAT, chunk

comment:8 by Zoltan Fekete, 15 years ago

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...

in reply to:  8 comment:9 by vasily Levchenko, 15 years ago

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.

comment:10 by Zoltan Fekete, 15 years ago

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...

comment:11 by Sachin Garg, 15 years ago

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.

comment:12 by vasily Levchenko, 15 years ago

Test build was send for verification

comment:13 by Zoltan Fekete, 15 years ago

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

in reply to:  13 comment:14 by vasily Levchenko, 15 years ago

Replying to zoltanf:

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

Thank you for feedback

comment:15 by vasily Levchenko, 15 years ago

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

comment:16 by amidsin, 15 years ago

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

comment:17 by Sander van Leeuwen, 15 years ago

Resolution: fixed
Status: newclosed

comment:18 by ddn, 14 years ago

Resolution: fixed
Status: closedreopened

Cisco VPN Client 32bit last version didn't working (IPSec) in 3.2.0 again with NAT networking. (guest winxp sp3 32bit/ host windows 7 64bit) i used TCP with port lower than 1024. Connection to host can't be established

comment:19 by vasily Levchenko, 14 years ago

Version: VirtualBox 3.0.2VirtualBox 3.2.0

Could you please collect pcap files (from guest and host ) and attach them to defect or send them to me (vasily _dot_ levchenko _at_ Sun _dot_ COM)?

in reply to:  19 ; comment:20 by ddn, 14 years ago

Replying to Hachiman:

Could you please collect pcap files (from guest and host ) and attach them to defect or send them to me (vasily _dot_ levchenko _at_ Sun _dot_ COM)?

i'll try consult with our security. wireshark sniff trace files contains private information and may lead to its disclosure :)

in reply to:  20 comment:21 by vasily Levchenko, 14 years ago

i'll try consult with our security. wireshark sniff trace files contains private information and may lead to its disclosure :)

Probably your security could investigate the traces and give some hint what missed in the packets sent from the guest.

comment:22 by vasily Levchenko, 14 years ago

Could you please VBoxDD.dll download debug bits and replace installed dll?

I'll have to ask you to collect trace files again with logs produced with this library.

How to start?

# set VBOX_LOG=drv_nat.e.l2
# set VBOX_LOG_DEST=file=nat.log
# VirtualBox -startvm <your-vm name>

Please send result log with traces to me again.

comment:23 by ddn, 14 years ago

okay. no prob. but can't download. Browser say HTTP 404. See below:

--20:42:26-- http://www.virtualbox.org/www/download/testcase/VBoxDD.dll.4499

=> `VBoxDD.dll.4499'

Resolving www.virtualbox.org... 88.198.19.108 Reusing existing connection to virtualbox.org:80. HTTP request sent, awaiting response... 404 Not Found 20:42:26 ERROR 404: Not Found.

in reply to:  23 comment:24 by vasily Levchenko, 14 years ago

Replying to ddn:

okay. no prob. but can't download. Browser say HTTP 404. See below:

--20:42:26-- http://www.virtualbox.org/www/download/testcase/VBoxDD.dll.4499

=> `VBoxDD.dll.4499'

Resolving www.virtualbox.org... 88.198.19.108 Reusing existing connection to virtualbox.org:80. HTTP request sent, awaiting response... 404 Not Found 20:42:26 ERROR 404: Not Found.

wiki tags have played a joke on me here the right URL: http://www.virtualbox.org/download/testcase/VBoxDD.dll.4499.debug

comment:25 by ddn, 14 years ago

i reply to your email (again HTTP 301 -> following -> HTTP 404)

comment:26 by Frank Mehnert, 14 years ago

Please try this link again, it works now.

comment:27 by ddn, 14 years ago

now all working. Im reproduced steps Hachiman wrote and emailed him all collected logs.

Thanks!

in reply to:  27 comment:28 by vasily Levchenko, 14 years ago

Replying to ddn:

now all working. Im reproduced steps Hachiman wrote and emailed him all collected logs.

Thanks!

Thanks, reading now.

comment:29 by vasily Levchenko, 14 years ago

Some intermediate report: bodies of tcp packets are the same from host and host-guest side (no data corruption). But anyway there're several retransmission from the NAT to guest, guest seems just ignore them, the difference with original packet (on host interface) is in PUSH flag, added by NAT. To make sure if it's a reason (and if it's a regression) I've asket ddn to collect the same logs on 3.1, or there're other reasons for such behavior.

comment:30 by vasily Levchenko, 14 years ago

Could you please verify the build?

comment:31 by vasily Levchenko, 14 years ago

Summary: Problems with Cisco VPN client on 3.x => fixed in SVNProblems with Cisco VPN client on 3.x

comment:32 by ddn, 14 years ago

"This installation package is not supported by this processor type. Contact your product vendor." displayed after executing .msi file i have 32bit system. does it ok?

in reply to:  32 comment:33 by vasily Levchenko, 14 years ago

Replying to ddn:

"This installation package is not supported by this processor type. Contact your product vendor." displayed after executing .msi file i have 32bit system. does it ok?

could you please try with 3.2.6 b2?

comment:34 by ddn, 14 years ago

ok, will try.

P.S. Did you receive mail from me (with attached logs in 3.1 version) ?

in reply to:  34 comment:35 by vasily Levchenko, 14 years ago

Replying to ddn:

ok, will try.

P.S. Did you receive mail from me (with attached logs in 3.1 version) ?

yes, thanks.

comment:36 by ddn, 14 years ago

still no luck with 3.2.6BETA2 and NAT-mode. works only in bridged mode

comment:37 by Markus Laker, 14 years ago

I'd just like to add that I had a similar problem using vpnc to connect to a Cisco VPN; guest is running 32-bit Kubuntu 9.10, host 64-bit Kubuntu 9.10. The problem I saw was wholesale packet loss, causing (for example) an ssh or telnet session to lock up if I typed 'ls -l', and preventing NoMachine NX from logging in. Moving the network adapter from Nat mode to bridged mode has solved the problem; many thanks to zoltanf for posting the workaround.

The reason I've piped up is that, in my case, VirtualBox 3.1.8 worked cleanly; the problem didn't appear until I tried 3.2.0 and 3.2.4.

in reply to:  37 comment:38 by vasily Levchenko, 14 years ago

Replying to mlaker:

I'd just like to add that I had a similar problem using vpnc to connect to a Cisco VPN; guest is running 32-bit Kubuntu 9.10, host 64-bit Kubuntu 9.10. The problem I saw was wholesale packet loss, causing (for example) an ssh or telnet session to lock up if I typed 'ls -l', and preventing NoMachine NX from logging in. Moving the network adapter from Nat mode to bridged mode has solved the problem; many thanks to zoltanf for posting the workaround.

The reason I've piped up is that, in my case, VirtualBox 3.1.8 worked cleanly; the problem didn't appear until I tried 3.2.0 and 3.2.4.

Was it changed for you with 3.2.6? If no please upload your log file to the ticket.

comment:39 by Frank Mehnert, 13 years ago

Resolution: fixed
Status: reopenedclosed

No response, closing.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use