I just wanted to say, that I needed who create 3 qubes (A, B and C) that can speak between them, for some testing that I am doing.
I followed:
And I was able to ping B from A.
Then of course I had to copy+paste the command to generate the remaining combinations. This may get you a bit dizzy (happened to me) but it is probably safer than most drugs and alcohol.
I just tested the 6 possible pings and all work perfectly.
I’m glad you got I got it to work, users are often confused when doing this. Do you think this could be improved?
We can’t really say that the thread is a community guide though? 
I think that we could create a community guide that includes all of the commands that I used. That is the most confusing part.
Hi!
I managed to shorten the combinations by running this on the network qube:
sudo nft add rule ip qubes custom-forward ct state new,established,related counter accept
That will allow communication between any qube connected to that networking qube (I treat mine as a NAT without access to internet)
Then, in your Linux qubes:
sudo nft add rule qubes custom-input ct state new,established,related counter accept
This allows inbound traffic to any port on your qube from any other qube connected to the same networking qube
In windows you would need to go to the firewall and disable it.
I used this to setup my local hacking lab.
Sounds good if you are using a custom networking qube. In my case, my 3 qubes are using sys-firewall, so I prefer to just allow communication between them.
Well, it worked when I did it, yes. But now, after a few days, I just tested it and the VMs won’t ping each other. So it worked was it was not persistent. I.m.h.o. most use cases would need persistence. So this may be one of the things that confuse people.
Would any of the bright minds here be so kind as to explain to this fool how to make this kind of routing persistent?
The easiest method is to add the command lines you had to run in each qube in their respective /rw/config/rc.local file, although it’s trickier if sys-firewall is involved as it’s a disposable so you can’t modify it directly.
In this case, you need to start sys-firewall disposable template (default-dvm by default) and edit /rw/config/rc.local and run the command only under the condition that the qube’s name is sys-firewall, something like this:
if [ "$(qubesdb-read /name)" = "sys-firewall" ]; then
nft rule ......
fi
This is required because it’s in default-dvm which is also used as a disposable template by sys-usb and other qubes maybe, you don’t want this command to be running everywhere.
Really thank you. I will try it. But as you can probably see, i.m.h.o. the “Official Guide” is not enough as it is now. Again i.m.h.o. it should include this as a second part, inside the same document.
Because as far as i can see, most of the times you will want persistent routing and not a one night routing affair.
I understand the need for this, however in practice this is actually difficult to document every situation and user need.
For instance, we explain how to make it work but it’s already up to the user to figure IPs of each qubes. Then, we don’t explain how to undo the setting.
If we added explanations how to make persistent, this would also require adding how to remove that persistance, what happens when you change the netvm of a qube you modified, how to be sure you didn’t create security issues.
This joins to the discussion started here Defining our target audience for community guides, accessibility for new users
I just put a comment in the target audience discussion. I don’t think that we can document every situation and user need. But even so, documenting a nice number of situations and user needs is i.m.h.o. something very good.