UDP source port changes, breaking VPN connections

[Jeff Mitchell]

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.

[Jeff Mitchell]

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