R
rvanspaa
Hi,
An ipv4 ping from my multihomed Windows 10 host to Ubuntu running under Hyper-V only works when using the same subnet as the source that is used by the internal NIC being used by Ubuntu. This also true when neither the host nor the Linux firewalls are enabled. Running Wireshark in Linux reveals that the ping is received, replied to and delivered back to the interface.
However the reply apparently gets dropped before being returned to the original source interface in Windows.
This is apparent from the following snippet from the firewall log when the firewall on windows is enabled. Note that the firewall rules are set to allow all pings - even external ones.
C:\Windows\system32>ping linux -S 192.168.20.2
Pinging Linux [10.2.1.101] from 192.168.20.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.2.1.101:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Resultant firewall log:
2019-04-04 13:32:46 DROP ICMP 192.16****0 - - - - 0 0 - RECEIVE
In short the echo-replies are being dropped (or the firewall log claims they are), while being delivered back to the source.
The routing is correct, because a ping of 192.168.20.2 initiated in Linux is returned without error.
This problem only arises with ipv4. ipv6 pings work fine in both directions.
Related facts:
1) Ping of Linux from windows running on a separate computer that is also on the 192.168.20 network also get's "dropped" at source on the other computer.
2) A ping of the other computer from Linux works fine (both 1pv4 and ipv6).
3) SSH from the other computer also fails, so the problem is not only ICMP related, however nothing shows up in the firewall log in that case of SSH.
4) When running Suse under SFU on the host (i.e. the same machine hosting both SFU and Linux under Hyper-V), "ping 10.2.1.101 -I 192.168.20.2" is returned, but the firewall log on the host claims that it was dropped.
5) The installation of SFU was done yesterday, and this problem has existed for weeks.
6) ipv4 - ipv6 preferences are set to 0 in the registry.
7) A ping to another subnet on the host is returned without error. E.g.
C:\Windows\system32>ping 10.4.4.103 -S 192.168.20.2
Pinging 10.4.4.103 from 192.168.20.2 with 32 bytes of data:
Reply from 10.4.4.103: bytes=32 time=15ms TTL=127
Reply from 10.4.4.103: bytes=32 time<1ms TTL=127
Reply from 10.4.4.103: bytes=32 time=3ms TTL=127
Reply from 10.4.4.103: bytes=32 time<1ms TTL=127
Ping statistics for 10.4.4.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 15ms, Average = 4ms
Continue reading...
An ipv4 ping from my multihomed Windows 10 host to Ubuntu running under Hyper-V only works when using the same subnet as the source that is used by the internal NIC being used by Ubuntu. This also true when neither the host nor the Linux firewalls are enabled. Running Wireshark in Linux reveals that the ping is received, replied to and delivered back to the interface.
However the reply apparently gets dropped before being returned to the original source interface in Windows.
This is apparent from the following snippet from the firewall log when the firewall on windows is enabled. Note that the firewall rules are set to allow all pings - even external ones.
C:\Windows\system32>ping linux -S 192.168.20.2
Pinging Linux [10.2.1.101] from 192.168.20.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.2.1.101:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Resultant firewall log:
2019-04-04 13:32:46 DROP ICMP 192.16****0 - - - - 0 0 - RECEIVE
In short the echo-replies are being dropped (or the firewall log claims they are), while being delivered back to the source.
The routing is correct, because a ping of 192.168.20.2 initiated in Linux is returned without error.
This problem only arises with ipv4. ipv6 pings work fine in both directions.
Related facts:
1) Ping of Linux from windows running on a separate computer that is also on the 192.168.20 network also get's "dropped" at source on the other computer.
2) A ping of the other computer from Linux works fine (both 1pv4 and ipv6).
3) SSH from the other computer also fails, so the problem is not only ICMP related, however nothing shows up in the firewall log in that case of SSH.
4) When running Suse under SFU on the host (i.e. the same machine hosting both SFU and Linux under Hyper-V), "ping 10.2.1.101 -I 192.168.20.2" is returned, but the firewall log on the host claims that it was dropped.
5) The installation of SFU was done yesterday, and this problem has existed for weeks.
6) ipv4 - ipv6 preferences are set to 0 in the registry.
7) A ping to another subnet on the host is returned without error. E.g.
C:\Windows\system32>ping 10.4.4.103 -S 192.168.20.2
Pinging 10.4.4.103 from 192.168.20.2 with 32 bytes of data:
Reply from 10.4.4.103: bytes=32 time=15ms TTL=127
Reply from 10.4.4.103: bytes=32 time<1ms TTL=127
Reply from 10.4.4.103: bytes=32 time=3ms TTL=127
Reply from 10.4.4.103: bytes=32 time<1ms TTL=127
Ping statistics for 10.4.4.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 15ms, Average = 4ms
Continue reading...