in your opening message you wrote
this going to transfer in eth0 in the virtual machine
eth1 in the virtual machine
but I could not find out how you’re forwarding - is it bridging or routing?
And if the VM is doing routing, then the IP addresses of the VM’s interfaces would be relevant, too.
So what I concluded from your traces and descriptions is
- host:eth0 (connecting to no external network), connected to host:br1 (IP 192.168.178.37), connecting to vnet0, connecting to VM:eth1
- host:eth1 (connecting to an external network 192.168.2.x), connected to host:br (IP 192.168.2.9), connecting to vnet1, connecting to VM:eth0
The output of “ip addr list; brtcl show; netstat -rn” from the host might help to verify these assumptions.
user@host # ping -I 192.168.2.9 192.168.178.37
A problem I see is that 192.168.178.37, which you’re trying to ping , is a local address to the machine you’re pinging from. I wouldn’t expect any ICMP echo request to leave the machine at all. OTOH, you’re trying to ping via a different interface, so the ICMP echo request might get ignored. (I would have to dig up the details of that situation, IP stack wise).
I have no default router active.[…] But earlier I had one
Please use “netstat -rn” to verify the situation - looking at the files will only show you what the system would try to configure upon the next network (re)start.
Second: This extract shows at least a ICMP action in the dump file:
linux-jwys.site > 192.168.2.1: ICMP linux-jwys.site udp port netbios-ns unreachable, length 86
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 78)
But I don’t know exactly what this means.
What you’re actually looking for are “ICMP echo requests” and “ICMP echo replies”.
12:51:19.615455 IP yourhost > someotherhost: ICMP echo request, id 5006, seq 1, length 64
12:51:19.618148 IP someotherhost > yourhost: ICMP echo reply, id 5006, seq 1, length 64
Your trace shows a “port unreachable” notification, send by linux-jwys.site to the site router (192.168.2.1), telling that no-one is listening on the port for “netbios-ns”.
What are you trying to achieve with your setup and tests? Your test violates some basic operations principles.
- pinging an address in a different subnet requires a router
- pinging local addresses via a different interface may well fail (I’d have to look that up)
a - if the VM is a test for a bridge, then create a second VM and let that one have an 192.168.2.x address, then run your ping test from the host. You should not even need to specify the source adapter, as the stack ought to pick that automatically.
b - if the VM is a test for a router: then it needs to be set up properly with IP addresses, forwarding activated, and you’d need a route on the host. And again use a second VM as the actual target, and avoid having an interface on the host within the same subnet.
Either way, the output of “ip addr list; brtcl show; netstat -rn;sysctl -a|grep forwarding” from the VM might help to understand that part of the setup.