Yes, it can be done thanks to the fact that you are running your Web Server in a Linux VM. The first fact (that you are using Linux) is an absolute prerequisite, the second one (that it is a VM, not a physical machine) makes it easier and less expensive.
When you set up a VPN, it changes your routing table, establishing (in your case) that all traffic must go through a different server. If a connection comes in through your local router, the Mint VM will try to answer by following the routing instructions of the only table it knows, i.e through the VPN. However, the pc trying to contact your Web server will see that its query to your non-VPN address has been answered by a distinct, third party, the VPN server. For obvious security reasons, these replies are immediately discarded.
To solve this problem, Linux has the ability to handle two (or more) distinct routing tables, with rules specifying when each is to be used. So what you want to do is to create a second interface on your Mint VM (let's call it eth1), and make sure that it has an IP address on your LAN (if you are using VirtualBox, that means creating a bridged interface.
Now all you have to do is to set up two routing tables, in such a way that if a communication comes in via the OpenVPN, it is answered by the routing table set up by the OpenVPN, but if comes in through the LAN (the NIC we called eth1) it is answered by a different routing table that routes traffic where it came from, i.e your local router, not the OpenVPN server.
You do this as follows:
before starting the VPN, create two tables: we will call them main (the one destined to be used by the OpenVPN) and NONVPN:
echo 200 main >> /etc/iproute2/rt_tables
echo 201 NONVPN >> /etc/iproute2/rt_tables
Add a gateway to each routing table (if needed):
ip route add 192.168.1.0/24 dev eth0 src <SRC1> table main
ip route add 192.168.1.0/24 dev eth1 src <SRC2> table NONVPN
Then a default route:
ip route add default via 192.168.1.1 table main
ip route add default via 192.168.1.1 table NONVPN
where I assumed 192.168.1.1 is your local router, and 192.168.1.0/24 the LAN.
Now you may start your VPN: it will modify your main routing table.
Lastly you the rules to select the route table based on the source address:
ip rule add from 10.0.0.0/24 table main
ip rule add from 192.168.1.0/24 table NONVPN
where I assumed your OpenVPN tunnel has addresses in the 10.0.0.0/24 range, modify accordingly.
You are done.
Best Answer
I just discovered what was going on on Linux, and this probably applies to Windows too.
Hamachi makes a bridged network interface to run the gateway through, and that becomes the "normal" network interface for the machine (on Linux, this is
ham-br0by default).VirtualBox however, keeps the machine configuration bridged to the original physical network interface (
eth0on Linux). I ran the following while the VM was powered off to make VirtualBox bridge to the Hamachi adapter:This sets the adapter VirtualBox ties into to
ham-br0. The VM is still visible from the non-Hamachi network as well. Like I said, this was on Linux, but VirtualBox's networking model remains more or less the same cross-platform.