[Resolved] Host-only network stops working, when connecting to 192.168.x.x IP-network (#18857)

[scottgus1]

OK I tried the experiment last night. TL;DR version: I was able to ping with impunity all directions on the Host-Only network with 192.168.what.ever host network address space. No failure on any Host-Only pings.

The details: I set the spare router to 192.168.96.1 & mask 255.255.224.0. I set my PC to static IP 192.168.96.100 and was able to log into the router. Then I set my PC to static IP 192.168.127.100 and was still able to log into the router. I was not able to set the gateway to 192.168.100.1 - its firmware would not let me change the third number in the DHCP server address, it was fixed at 96. I also found that later on I was not able to access the router anymore at 192.168.127.100, I had to drop back to a .96 address. This router is really for a house and may not have enough bells & whistles to handle the exact copy of the RD network arrangement.

I had an Ubuntu 18.04 and an XP guest on the host. I set them to access the Host-Only network, defaulting to 192.168.56.###. The guests were .101 for Ubuntu and .102 for XP. I could ping the host from each guest just fine. I could actually ping all six directions with no trouble.

I set up a new Host-Only network at 172.16.0.### with no DHCP and static IPs in the guests at 172.16.0.101 & 102. Again guest-to-host and all six directions pinged happily.
Pinging continued as I unplugged the host from the router, attached the house network to the router's WAN port in a successful attempt to get internet on the host through the router, and at no time would pinging stop on the host-only. Pings successful all the time.

Though my router may not have exactly duplicated the RD network setup, I had no trouble on the Host-Only network no matter what I was doing with the physical LAN.

[Stradman]

This router is really for a house and may not have enough bells & whistles to handle the exact copy of the RD network arrangement.

It really did not take too many bells and whistles to reproduce here at the office: I just had a spare home VDSL router with the default network configuration, 192.168.1.0/24 and DHCP on. Right after connecting the cable to my laptop the ping stops, just like in the RD-net. I'll give this a try at home tonight.

I set up a new Host-Only network at 172.16.0.### with no DHCP and static IPs in the guests at 172.16.0.101 & 102. Again guest-to-host and all six directions pinged happily.

You don't mention it here explicitly, but I suppose you did ping the Host-only address 172.16.0.1 ?

[scottgus1]

Yes, from both guests, "ping 172.16.0.1" and "ping 192.168.56.1" All pings went through, no data loss, regardless of the state of the router LAN.

Thinking about it this morning I may have made a mistake in the subnet mask on the PC when I tried to set the IP address to 192.168.127.100. I'll try it again tonight.

[Stradman]

Ok, guys, I may (or may not) be on to something..

I brought my laptop home and tried it quickly. Here, at home, the ping does not reach 176.16.0.1, what ever I do, connect or disconnect. Or if I'm in Airplane Mode.

My best guess is that or IT guys are pushing some obscure super-paranoid policies, meant for Excel-wielding managers to not pose a threat to corporate IT security. And the F-Secure rules are set either to not actually notify us of anything happening, logging, events etc. (I did not bother studying this much further at this point, since I cannot access half the stuff I would need on the UI..)

So, my first task list tomorrow is: a cup of coffee, a knock on the IT-support door, and asking: "seriously?!"

[scottgus1]

my first task list tomorrow is: a cup of coffee, a knock on the IT-support door, and asking: "seriously?!"

And a three-week vacation after that until they get back to you...

IT guys are pushing some obscure super-paranoid policies

Rumors to that effect are usually true, especially in corporate settings.

If there's extra security software, that's a real good place to look.

[vushakov]

EDIT: a bit of Wiresharking and I find that the MAC-addess in the ping 10.0.0.1 reply shows it's coming from the default GW 192.168.100.1, when looking up the MAC-address from 'arp -a' output. So as such, I guess this network config is valid, but far from optimum. And also, missing a responsible admin..

This is exactly how it's designed to work. You ping 10.0.0.1, there's no prefix that covers it so the packet is sent to the default gateway. There is 10.0.0.1 somewhere in the network you are connected to and the ping request reaches it eventually. It sends a reply. That reply reaches your default gateway. The gateway needs to forward that reply (IP packet) to your machine, so it sends your machine an Ethernet frame with the IP packet of the reply. Obviously the source MAC of that Ethernet frame will be that of the gateway.

[Stradman]

Yes. But, it might be also possible if both the pinging host and something wild in the same network segment would be misconfigured. But, this is now all coming back to me, it has just been 10 years since I've had to debug network issues in this scale. I guess I've been blessesd with professional IT for a few years. Not to mention, I should be doing something else at the moment..

All in all, I think this is coming to a conclusion: F-Secure rules, how they are applied in our networks, and "funnily" how your PC thinks it still is in a trusted network, even if disconnected - until connected to another network. That kind of "inconsistency" gives a nice twist when trying to solve this kind of issues. I finally managed to fully block the pinging from Guest -> Host, when connecting my laptop to my home network. And it did not resume working until I got physically connected back to my office network.

EDIT: Also it is notable, that in this setup, using VPN from home to work did not qualify as "trusted" network connection. It really required physical network access.

[fth0]

@Stradman:
I haven't had much time lately, so I'll try to catch up now ... and I also come to the conclusion that the problem is some (security) software on the host interfering.

Take the following description with a grain of salt, since I do not have detailed knowledge of some of the layers I'll be describing:

If the Windows Firewall allows incoming ICMPv4 packets, there will be a windows service receiving the ICMP echo request packets (0). If all goes well, this service answers each request with an ICMP echo reply packet (1), that then goes through any security software drivers (2), through the Windows networking stack (3), through the Wireshark capture driver above the Host-Only network interface (4), through the VirtualBox Host-Only adapter (5), through the VirtualBox IntNet layer (6), through the Intel network adapter emulated for the Linux guest enp0s8 (7), through the Wireshark capture driver above the Linux network interface enp0s8 (8), through the Linux network stack (9), to the ping program (10).

This path is broken at some point in your setup(s), and we've all been trying to find the break (one way or the other). When capturing with Wireshark at (4) and (8), the path can be partitioned into three segments: Windows host, VirtualBox, Linux guest. I understand that you could not capture the ICMP echo reply packets at (4), so VirtualBox is probably out of the equation. Otherwise, if the ICMP echo reply packets would have been captured at (4) and not at (8), then the VBox.log files would give some numbers to compare with the Wireshark traces (interpret the ns as count):

00:01:43.222903 /Devices/E1k1/uStatRxFrm 27 ns
00:01:43.222963 /Devices/E1k1/uStatTxFrm 63 ns

00:01:43.223848 /Drivers/IntNet-0/Packets/Received 85 count
00:01:43.223856 /Drivers/IntNet-0/Packets/Sent 63 count

00:01:43.252160 E1000#1: Received frames : 27
00:01:43.252164 E1000#1: Transmitted frames: 63

00:01:43.262140 /Devices/E1k1/uStatRxFrm 1 ns
00:01:43.262188 /Devices/E1k1/uStatTxFrm 66 ns

00:01:43.262756 /Drivers/IntNet-0/Packets/Received 6 count
00:01:43.262761 /Drivers/IntNet-0/Packets/Sent 66 count

00:01:43.282003 E1000#1: Received frames : 1
00:01:43.282005 E1000#1: Transmitted frames: 66

The first and the third pairs of numbers are probably two views of the same data and are on the guest side, while the second pairs of numbers have been counted nearer to the host side. Note that the received counts are higher there. Comparing with Wireshark traces at (4) and (8) should clarify what kind of packets make up for the difference.


@vushakow:
I do not know many details about the VirtualBox networking implementation. If you care to enlighten us:
Is my description of (5) to (7) above somehow a little bit accurate?
Where do the nictrace options capture the network traffic?

[vushakov]

@vushakow:
I do not know many details about the VirtualBox networking implementation. If you care to enlighten us:
Is my description of (5) to (7) above somehow a little bit accurate?
Where do the nictrace options capture the network traffic?

Your description of (5)-(7) is accurate (though I'd rather not get into the gory details of (5) ).

"-nictrace" inserts the NetSniffer driver between the emulated device and the actual driver, so all the traffic coming to/from the guest is captured at the point where the virtual ethernet wire is plugged into the virtual device - i.e. where (6) is coupled with (7).

[Stradman]

Issue finally sorted by getting proper developer networking policies in place to F-Secure.

The previous policy silently dropped any inbound conncetions, when connected to other than corporate network.