Normally to understand things we split networking to the layers (in the OSI meaning) and abstract away from the unrelated details belonging to other layers. In layer 1 (physical), we have a host which is physically connected to some network. In layer 2, however, we have two systems here: a host with two Ethernet interfaces (one of which is happened to be eth0 and the other vboxnet0) and a VM with one. The host connected to WAN on via eth0, and the vboxnet0 is connected to the VM's interface.
This is how it should be understood. Abstract away for a minute from all those details about virtual machines, virtualization hosts, "host only" networking and its perceived "restrictions" and so on. This is how your network looks like (albeit, virtual, but the network is always virtual, it's just an imaginary layer above the physical things):
(Internet) --- [eth0] Host [vboxnet0] --- [eth0] VM
So, assign some addresses to eth0 and to vboxnet0, and make sure those are from different subnets. VM's vNIC eth0 should have an IP from the same subnet as the vboxnet0 address, so your VM and host can communicate.
You have two computers which are connected to each other and one of them is also connected to the Internet. Without special setup on the "host" computer, there will be no Internet connectivity on the "VM", right? This is why "host-only" networking is often thought that it doesn't allow internet connection.
But if you perform this special setup on the "host" computer, the "VM" will be able to reach Internet through it. For that, the "host" computer should become a router, and, optionally, do the NAT to somewhat "hide" the presence of another computer, so it's internet connection will be "tethered".
The special setup I am talking about is the following: you need to enable packet forwarding on the "host" computer, so it will pass packets for the other computer, which happens to be a VM, and, whichever address you assigned to the host's vboxnet0 is configured as the default gateway on the VM, so it knows it should access Internet through the host.
The systems on the eth0 side of the host should know where to find this network you used for the vboxnet0 and VM's eth0, you need to add routes to them towards this network through the host's eth0 address. Or, if you choose NAT path, you need to translate all VM's packets going out of the "WAN" interface to the address of the host's "WAN" address. The "WAN" interface is eth0 in this case:
iptables -t nat -A POSTROUTING -s <vboxnet0-network> -o eth0 -j MASQUERADE
(-j SNAT --to-source <eth0-address> will work too and allow more granular NAT setup, but -j MASQUERADE is easier and more convenient if eth0 receives its address dynamically).
In principle, if you did not set up any other firewall on your host, this is all you need. The ACCEPT rules that you added into filter table are redundant in this case. But if you have additional setup (for instance, if FORWARD policy is set to DROP traffic or if you have a dropping rule in the filter FORWARD table), you've need to add other rules, which permits VM packets to be passed forth and back.
A short summary
- Abstract unrelated details. Virtual networks are networks in the full right and should be treated as such. Virtual machines don't differ absolutely from physical ones when it comes for the network connectivity. Just presume all computers and all interfaces and connections are real and go further.
- Host-only networking never meant to "isolate" virtual machine from the Internet. It means just what it states: in this mode the virtual machine has the only connection — its virtual network interface is wired to some the special network interface on the host. If the host happens to be a router, it may well route packets for the VM, enabling it to access the Internet.
Update
even though both host machine (not host VM) and the bridged VM are in the same subnet
This is why it is not able to ping. Bridged and host-only machines are in different Ethernet segments. Think again you have three Ethernet cards in a single computer named "Host". Two of them are bridged together. Cards are connected to other systems:
(Internet) --- [eth0 + BridgedHostIf] --- [vNIC] VM-2
Host
[HostOnlyIf]
|
[vNIC]
VM-1
So, you have three Layer 2 interfaces here, but only two Layer 3 (IP) interfaces: bridge (which is named eth0 because it is a "kind of" bridge made with VirtualBox quirks) and HostOnlyIf.
Now, when I decomposed your network for you, let me ask your second question in different terms: what happens if you configure the same network on two different network interfaces on the same computer? Will those machines be able to communicate with each other? What needs to be done for them to be able to communicate?
Notice we really have some deep VirtualBox magic here. Where exactly VirtualBox bridging code taps into host networking stack and how it interacts with other networking inside the kernel, including the Netfilter code (which performs NAT) and routing / packet forwarding code. I don't really know. If VirtualBox bridge would be the native Linux bridge, I would be able to explain. But to to understand how VirtualBox "bridges" really work you need to read its sources. Sorry here.
The lesson for this part is to not to try to run VirtualBox in production on servers. It is designed to be used on dev's desktop machines, considering its user-friendly desktop-oriented interface. It is not really designed to be run on servers. If you want to have predictable and configurable virtualization production environment, use something appropriate, like libvirt-based or Proxmox VE.
