Using the Windows host VPNs in a Linux guest

[ptoniolo]

My host is Window 11, the guest is Oracle Linux 8.7 that I use for an Oracle XE 12c installation. The network adapter i use is NAT.
On my host I have two different VPNs that I use to connect to different customers. They are Cisco AnyConnect and Ivanti Secure Access Client. Those two can easily operate simultaneously, assuming there is no overlapping on the host routing table, but this is expected. Overall, I can use them both connected, and the host is just fine.

A first issue was that whenever I boot my Linux VM when the Ivanti VPN is connected, the guest OS automatically asumes a hostname "somestring.mycustomer.com" instead of the usual localhost.localdomain that is used when the VM boots when the Ivanti network is disconnected. The status of the Cisco VPN is irrelevant: if it is connected or not at boot, the hostname of the guest is always localhost.localdomain. I can add that a search on the files of the /etc root in the guest OS does not find anywhere the name "somestring", so I assume that the name is somewhat obtained from the "mycustomer.com" network.
This first issue was a nuisance for the Oracle server installed in the guest, because the Oracle Listener configuration files needed to be connected to the correct hostname, but I solved this problem configuring the Oracle config files with the "somestring.mycustomer.com" as host name, and adding the same name to the /etc/hosts file as a synonym for 127.0.0.1. So far, so good.

The problem I cannot solve is this. The Linux guest can see the network behind the host Cisco VPN, regardless of the VPN status at the guest boot. Even if the VPN was down during the guest boot, if I connect the host VPN afterward, the guest can see the network behind the just opened VPN.
But this is not the behavior I get when I boot the Linux guest while the Ivanti VPN is disconnected: even if I later connect that VPN, the guest will not be able to see the network behind it. The only way to use the host Ivanti VPN within the guest OS is to boot the guest while the VPN network is already connected.

The two problems may be related, I don't know what else to try to have a configuration of my guest that can dynamically recognize the Ivanti VPN, like it is already doing withe the Cisco VPN. I am afraid that this can be an issue for the Ivanti VPN software itself (or its configuration whatsoever) but I don't understand why I get this different behavior form the two VPNs.

Let me add that the same configuration runs correctly with a VM managed by VMware Player/Workstation: the name of the Linux hostname is always localhost.localdomain and the Linux guest can see the host VPN even when the host (Windows) VPN is opened after the guest (Linux) boot. And in that case too the network adapter configured for the VM is NAT.

Any idea?

Thanks
Pietro

[scottgus1]

This one is way too deep for me. Since the setup works under VMware's NAT but goes iffy under Virtualbox NAT (assuming its the same exact VMs being run under VMware at one time and then Virtualbox another time, not two copies of the VMs that could then have different configurations in the VM OS's) I'd say there could be a difference in NAT implementation, or a DNS setting that's in Virtualbox NAT which isn't in VMware NAT, or some such.

I'd suspect that the forum guru who might look into this would want to see Wireshark traces for when the setup works correctly under VMware and when failing under Virtualbox. (Remove the "somestring.mycustomer.com" workaround, so the original behavior can be seen in the traces.)

Also, zip and post the VM's .vbox file, and possibly the VMware configuration file.

[fth0]

There are some Fine Tuning the Oracle VM VirtualBox NAT Engine options that may or may not help in your situation. Take a look at the two DNS-related subsections for the DNS issue and the subsection for how to bind NAT to a specific host network interface. Regarding the latter, some VPN clients internally work with a virtual network interface themselves, and this could be the key to understand the different behavior of the VPN clients.

Additionally, you could modify the VirtualBox DHCP server (VBoxManage dhcpserver) to use very short lease times, so that the DNS server and gateway IP addresses delivered to the guest OS via DHCP change earlier.

Please let us know what you find out.

[ptoniolo]

Interesting suggestions, thanks to both.

The VMware and VirtualBox are running side-by-side, I configured both to try to understand what was the issue. I tried all possible combinations, but the behavior I can recognize is what I wrote in my post: VirtualBox has a strange behavior, but only with the Ivanti VPN, the Cisco VPN is OK, same behavior from VMware and VB.

I don't like the idea of connecting the NAT to one specific network interface, because this is not really helping my situation, and also because in that case I could use a bridged or something similar. Now this VM is used only to host an Oracle database, and so I just want to let it behave at best for that configuration and that configuration only. I will definitely study the fine tuning of the NAT interface, because I am sure that the problem lies in the interaction between the VirtualBox implementation of NAT and the Ivanti VPN.

Anyway, to be clear, I am not blocked by this problem: I must remember to boot my VM after opening the Ivanti VPN, that's all. I was just curious to understand the reason of this different behavior. Maybe I will try to see with wireshark if I can understand what is happening, but I am sure the message exchange is quite complex, also because I am rather convinced that the problem arises early in the boot phase, when the VM decides to get its hostname from the network...

[scottgus1]

The VMware and VirtualBox are running side-by-side

This looks like it means you have two VMs, then, and it leaves open the question of whether there's something inside the OS in each VM is different, and this might not be a Virtualbox problem at all.

Is one able to run Virtualbox and VMware on the same PC at the same time? I was not aware this was possible. If these are different hosts, then this is another possible source of difference that could take the problem away from being caused by Virtualbox.

If you made an exact copy of the VM, ran each identical copy under Virtualbox or VMware on the same host (not necessarily at the same time, though), and the problem came up right away without touching any OS settings, then it could be Virtualbox. (Note that installing the same OS in a Virtualbox or VMware VM is not identical VMs; you'd need to do the install in one hypervisor, using compatible peripheral hardware for both hypervisors, then make a copy of the VM disk file and set it up under the other hypervisor, to actually have identical VMs under each hypervisor, to exclude OS differences from the equation.)

Please clarify what you have going on per the above.

I don't like the idea of connecting the NAT to one specific network interface

You wouldn't have to try everything under the suggested manual link. Only what seems to be pertinent to the problem.

[ptoniolo]

I just installed the same iso of Oracle Linux 8.7, separately, in an empty VirtualBox VM and an empty VMware VM, with a similar hardware configuration, 4GB RAM, 2 CPUs, 40GB disk and one NAT network adapter. The installation has been made on the same Windows 11 host. In both, after the guest OS installation I added the respective additions. I did not try to install one version and use a copy of it with one and the other VM hypervisors. But I believe this should not change the fact that passing from one hypervisor to the other the virtual devices will be different, and so the internal connections in the guest OS will become different anyway. Moreover, correct me if I'm wrong, the "guest additions" of VB and the "VMware tools" of VMw are different, I presume.

Obviously the two environments for the guest OS provided by VB and VMw are different. But they can coexist without problem on the same Windows 11 host, assuming you have enough resources for both of them. I can run the two VMs independently or in the same time.

I am mostly working with the VirtualBox VM at the moment because I am preparing this environment to be used by some of my customers and colleagues too, and the Oracle license is permissive while even the VMware Player is now restricted to personal use only.
But this is the point. While the VMware VM is hassle-free, the VirtualBox need special care for this issue related to the NAT-VPN connection.

[scottgus1]

Ok, thanks for the clarification. So we don't have identical sources from which to trust that only Virtualbox might have the problem.

Please see about providing the succeeding VMware and failing Virtualbox Wireshark traces, maybe someone here can figure out what's up.

[fth0]

I'll describe a few general aspects of VPN clients that could play a role here:

DNS: VPN clients usually add DNS settings to the host OS, either locally configured or requested from the VPN server (e.g. via DHCP or IKE Config Mode). Those DNS settings are prepended to the existing DNS settings to take precedence. If the VPN server doesn't deliver DNS settings ...

Check the current DNS settings on the host while none, one or both of the VPN clients are connected. Additionally, check the log files of the VPN clients. Combine this with 1 of the 3 methods that VirtualBox offers for DNS resolutions to your liking.

Split/Full tunneling: VPN clients can be configured to use either split tunneling or full tunneling. In the former case, only some traffic uses the VPN connection, while Internet traffic does not. In the latter case, all traffic goes through the VPN connection, so that the company can (perhaps better) protect the VPN client device from malicious software from the Internet (at the cost of needing more bandwidth). This influences the DNS settings and routes that the VPN server delivers to the VPN client.

Virtual network interface: VPN clients often (always?) create a virtual network interface and change some of the (host OS) routes to point to that (corresponding to the split/full tunneling configuration), in order to intercept and secure the traffic. Those virtual network interfaces could be always active and working in some sort of pass-through mode while the VPN is not connected.

Check if (host OS) routes point to the virtual network interfaces while none, one or both of the VPN clients are connected.

The VirtualBox NAT engine acts as a normal host application when creating network connections in behalf of the guest OS. Therefore, it should be subject to the current host OS routing table at the time a new TCP/UDP network connection is created. Check the current state of the (host OS) routing table when initiating a network connection from within the guest OS, and use Wireshark traces on all host network interfaces (and possibly also in the guest) to check what really happens.