I have created a Ubuntu 10.04LTS VM running openvpn. I use this as a VPN server appliance for my clients. I use it on a Ubuntu 10.04LTS host system. Both are x64 based. My VM has stopped forwarding ipv4 on a new host server I built running VBox 4.0.8. The same VM is forwarding ipv4 requests just fine on a server running VBox 4.0.4. Both are running the same version of Ubuntu 10.04LTS. On the VM from the new server I can ping the host system's IP, but no other systems on the network (including the gateway). The host is 10.1.1.20, the VM 10.1.1.220, the GW 10.1.1.1, all using a netmask of 255.255.255.0. cat /proc/sys/net/ipv4/ip_forward shows "1", so I know ip_forward is set correctly.

This appears to be regression from 4.0.4 to 4.0.8. I'm setting up a test system now to allow me to verify this. Do any of you know how I can test what is going wrong in the meantime? I'm not sure where to look. Should I tcpdump on the host NIC, the VM NIC, or ??? and what should I be looking for. Any help would be appreciated. I've been pulling my hair out on this one for the past week.

OK, I was able to test my VPN VM on a different server running VBox 4.0.8 and reproduce that ipv4 forwarding was not happening. I then removed: "virtualbox-4.0_4.0.8-71778~Ubuntu~lucid_amd64.deb" and installed: virtualbox-4.0_4.0.4-70112~Ubuntu~lucid_amd64.deb. There were no modifications to the VM (in fact, it still showed as registered in 'vboxmanage list vms' after the 4.0.4 install).

My VPN VM now works and ipv4 forwarding behaves as it should. Can someone help me define what the bug is so I can submit a bug report?

Even though I have a good understanding of networking, I have no idea how to exactly pinpoint this problem. What I do know, is that you have to report it in the Bugtracker (separate account needed). If you can, please try 4.0.6 as well, so the team has a smaller window to look for the problem.

Thanks Sasquatch. I re-tested using 4.0.6 and it does not work, so the bug was introduced between 4.0.4 and 4.0.6. I'll try to get a bug report submitted when I have another free moment over the next day or so.

Hello Scott,I appear to be having the same issue with OpenVPN, though I am running 4.1.2 with Debian 6 as both the host and guest. Just wondering if you ever submitted a bug for this? Were you ever able to find a solution (besides reverting to 4.0.4)? Thanks!

Just to follow up should anyone with this problem stumble on this thread. It appears a bug report for this over 4 months ago, but it has not even been assigned at this point. 4.1.4 was released earlier today and I have confirmed the issue is still present.

FWIW, I had the same issue with a Ubuntu 12.04 server host, Ubuntu 12.04 server guest in VBoxHeadless setup on VBox 4.1.18.

Since I had a different guest/host combo and more info on the issue, I opened up ticket #10811 <New member, can't post the address>

I suspect this may have been related to the source of the bug: <pretend this is the link to the 4.0 changelog>"Host-Only & Bridged & Internal Networking: fix for processing promiscuous mode requests by VMs, defaulting to switch behaviour"

If they used a static MAC table for defined guest MAC addresses (I had specified mine statically in the VM definition) and also didn't flood unknown unicast frames to the guest adapters, this issue would be the result.

Dobler wrote:Using 4.1.20 on Solaris. Still having the same issue. I may try downgrading.

OK, to make things more interesting, I have identical VBox environments (4.1.8r75467) running on two host Ubuntu 10.04 LTS x64 systems. I created a new Ubuntu 12.04 server VM and configured it with OpenSWAN, ppp, and xl2ptd and copied it to both servers. On one of the servers, net.ipv4.ip_forward = 1 works as expected. On the second one, it's not forwarding. I have verified that /proc/sys/net/ipv4/ip_forward is set to "1". Are we dealing with an issue with the host's NIC driver (the hardware is different on the 2 servers)? This is most confusing. I don't know where to begin on troubleshooting this. As I stated when I stated this thread, I though it was release specific. Now I'm not so sure. I haven't tried this out on the new 4.2 release yet. I have other servers available and will try to reproduce the problem on them (the existing 2 servers are in production).