Ticket #14055 (closed defect: duplicate)

Opened 5 years ago

Last modified 4 years ago

UDP source port changes, breaking VPN connections

Reported by: Jeff M Owned by:
Component: network/NAT Version: VirtualBox 4.3.26
Keywords: Cc:
Guest type: Linux Host type: Mac OS X

Description (last modified by vushakov) (diff)

I am having a problem very similar to the one described in #6667, except that it's on OSX using official packages version 4.3.26.

After discussion of a disconnect problem I was having with the OpenVPN developers, they believed the issue could lie with the VM NAT stack. They suggested capturing traffic on the OpenVPN server and indeed, when I did so I could see that in the middle of a connection (running rsync between two VMs via the server) the UDP source port for the VPN connection suddenly changed:

20:46:59.274161 IP > UDP, length 1445
20:46:59.274547 IP > UDP, length 1445
20:46:59.274555 IP > UDP, length 1445
20:46:59.276917 IP > UDP, length 1445
20:46:59.277719 IP > UDP, length 1445
20:46:59.277993 IP > UDP, length 1445

When this happens, of course, the VPN software thinks the old connection has died, and eventually times out and disconnects.

At this point I can trigger the problem extremely reliably by rsyncing files over the VPN connection -- it will happen within a minute. This suggests to me that what's triggering this problem is either the total data rate back and forth through the NAT stack or some total number of packets or bytes through the NAT stack. That, or for some reason at some point the NAT stack stops correctly tracking the connection, decides that it's a new connection, and gives it a new outbound port. Just my guesses.


VBox.log Download (63.4 KB) - added by Jeff M 5 years ago.
Log file

Change History

comment:1 Changed 5 years ago by Jeff M

(Deleted as the formatted traffic dump was moved to the issue description, thanks!)

Last edited 5 years ago by Jeff M (previous) (diff)

comment:2 Changed 5 years ago by vushakov

  • Description modified (diff)

comment:3 Changed 5 years ago by vushakov

  • Description modified (diff)

Changed 5 years ago by Jeff M

Log file

comment:4 Changed 5 years ago by Jeff M

I attached a log file. This is the log from startup until a few minutes after this UDP source port switch occurred -- note that there was *no* logging of anything at that time, so the end of the log is a minute or so before that happened.

The guest is running guest utilities from upstream Ubuntu repositories (I didn't find an updated version in your swupdate repositories): virtualbox-guest-dkms, virtualbox-guest-utils, virtualbox-guest-x11, all version 4.3.10-dfsg-1ubuntu3. If desired I can try installing updated definitions (I may try this anyways while waiting for a response).

comment:5 Changed 5 years ago by Jeff M

I removed the old guest additions and installed the 4.3.26 additions the recommended way (via the ISO). It did not make a difference.

comment:6 Changed 5 years ago by vushakov

I don't think guest additions has anything to do with this.

At this point I can trigger the problem extremely reliably by rsyncing files over the VPN connection -- it will happen within a minute.

Hmm, so, you have an active transfer and the source port changes suddenly in the middle of it? Interesting.

Can you provide a packet capture from the guest side, please? Just to make sure that the source port is not changed on the guest side.

comment:7 Changed 5 years ago by Jeff M

I captured the entire VPN session on the client side during the rsync, using -i any (so you'll see the outbound IP/port on the VM instead of the VPN's internal IP/port).

Following is the head and tail of the file, you'll see that the port remains constant.

~  ᐅ head rsynccap.txt
15:58:05.740150 IP > UDP, length 133
15:58:05.761457 IP > UDP, length 109
15:58:05.889454 IP > UDP, length 125
15:58:05.890649 IP > UDP, length 125
15:58:05.896495 IP > UDP, length 93
15:58:05.912088 IP > UDP, length 93
15:58:05.912383 IP > UDP, length 85
15:58:05.912625 IP > UDP, length 85
15:58:05.912705 IP > UDP, length 101
15:58:05.912978 IP > UDP, length 101
~  ᐅ tail rsynccap.txt
15:58:50.865005 IP > UDP, length 1445
15:58:51.749534 IP > UDP, length 277
15:58:52.750228 IP > UDP, length 277
15:58:53.751151 IP > UDP, length 277
15:58:54.751855 IP > UDP, length 237
15:58:58.304297 IP > UDP, length 1445
15:59:00.740492 IP > UDP, length 93
15:59:01.742825 IP > UDP, length 93
15:59:03.744134 IP > UDP, length 93
15:59:07.752130 IP > UDP, length 93

At the end there the packets simply stop being sent mid-stream, presumably because it has not received a reply from the VPN server in whatever window or time limit it requires (due to the server trying to send to the original port).

comment:8 Changed 4 years ago by vushakov

I think this is a duplicate of #13475 which I now managed to reproduce. It's probably killed by unreachable/fragmentation needed from some router upstream.

comment:9 Changed 4 years ago by vushakov

  • Status changed from new to closed
  • Resolution set to duplicate
Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use