Opened 9 years ago
Last modified 9 years ago
#14055 closed defect
UDP source port changes, breaking VPN connections — at Initial Version
| Reported by: | Jeff Mitchell | Owned by: | |
|---|---|---|---|
| Component: | network/NAT | Version: | VirtualBox 4.3.26 |
| Keywords: | Cc: | ||
| Guest type: | Linux | Host type: | Mac OS X |
Description
I am having a problem very similar to the one described in https://www.virtualbox.org/ticket/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 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.274547 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.274555 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.276917 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.277719 IP 172.19.45.154.59878 > 172.27.102.152.443: UDP, length 1445 20:46:59.277993 IP 172.19.45.154.59878 > 172.27.102.152.443: 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.
