Ping VM from TrueNAS - unreachable

Apps and Virtualization
1

Hi,

I just noticed that a VM running on my TrueNAS (Scale) can’t contact the TN host nor vice versa. When I ping the VM from the TN shell, I’m getting “Destination Host Unreachable”.

Both machines (TN and the VM) are pingable fine from the network side.

A complication may be that the TN machine is using two NICs in two networks. Both can ping (and be pinged from) the network:

TN: 10.1.1.11, 10.6.1.11
VM: 10.1.1.4 (assigned the NIC with 10.1.1.11)
Gateway: *.254 (both nets)

on TN:
ping 10.1.1.11 → ok
ping 10.6.1.11 → ok
ping 10.1.1.254 → ok
ping 10.6.1.254 → ok

ping 10.1.1.4 → unreachable

on VM:
ping 10.1.1.254 → ok
ping 10.6.1.254 → ok

ping 10.1.1.11 → unreachable
ping 10.6.1.11 → unreachable

I performed the upgrade TN 24.04 to 24.10 just yesterday, but couldn’t say if this worked before or not.

Am I missing something here?

Regards

2

You need to configure a bridge

3

I don’t quite understand: If TN and the VM are the same net over the same NIC, why do they need a bridge to communicate?

Edit:

Ok, I think I’m starting to get it: Currently, both the VM and TN access the interface directly. Would the correct way to create a bridge, connect the interface to it, and have both TN and VM access that bridge instead of the interface?

4

Yes

Note that the iunterface IP address must be on the bridge and not on the interface

5

A wild cpt stux tutorial appears

2 Likes
6
7

It’s working fine now. Thanks for the hints!

Setting this up proved more challenging as I had expected though: I was unable to configure everything at once and then hit “apply” once, but had to go in steps, otherwise it wouldn’t save. Not only did those steps have to be in the perfect order to avoid messing up the control connection, I also had to insert reboots at the exact right spots to get the new interface(s) to activate.

8

That’s kind of weird, i’ve done my bridge setup in one step and without a reboot…

9

I got to the point where I had the bridge set up and had connected the interface to it.

But the bridge wouldn’t activate (turn from grey icon to blue, pulsing one) and it didn’t get an IP by DHCP either. All it got was an IPv6 link-local if I enabled IPv6 auto-config, but this IP wasn’t ping-able either.

Rebooted once and boom, there it was.

10

Well i wasn’t using dhcp but a static ip, so maybe that’s the difference.

11

No, I tried that, too: I could assign a static IP, but it still just wouldn’t communicate on it.

After the reboot - no problem.

This seems to be necessary on my system each time you activate a new interface: Once it is “active”, whatever this may mean, you can manage it fully, configure it, take it up/down at will. But a new interface (and, apparently, even virtual interfaces like the bridge) has to see a reboot first, else it stays in “deactivated” state.

Maybe it’s a quirk of the mainboard. It’s not the most current hardware in the world.

12

The order of operations is quite specific, this is one of the reasons I developed the approach in my video.