If you’re getting a ‘no route to host’, I suspect:
- You are hitting a REJECT iptables rule somewhere
- The backup qube isn’t connected to the firewall qube, or somehow lost connectivity?
- Edit: based on your last reply, I think this is where the issue is
- You’re modifying routing rules on some qubes and undoing the 32-bit subnetting?
- Typo somewhere? Wrong IP address somewhere maybe? Make sure the IPs haven’t changed on you, though that should only happen if you created a new qube.
From the info you’ve posted, what you have should do it. You’ve got:
- Forwarding enabled at the netvm so that qubes can talk to each other
- The backup qube wide open to the client on the INPUT side
I also agree with unman, doing this with qrexec will remove the iptables complexity and the need for your firewall qube.
To understand the qrexec/RPC method, think of it like this: If you have a server qube and client qube, in the client qube you are doing something similar to local port forwarding for SSH, except the transport isn’t SSH; it’s qrexec. qrexec is the Qubes implementation that uses Xen capabilities like vchans for inter-VM communication details.
If you wanted to open up all ports on a server qube to a client qube (which by all means is naturally dangerous, this is only to demonstrate capability), you would do:
- Edit (dom0) /etc/qubes-rpc/policy/qubes.ConnectTCP
- Add a line
clientqubename serverqubename ask,default_target=serverqubename, this will prompt you to confirm allowing making the TCP connection
Any port in serverqubename is now accessible to clientqubename; pretend it’s like clientqubename having localhost access to serverqubename (no annoying firewall rules to worry about, very dangerous!)
-
To ssh into serverqube from clientqube (such that localhost:8022 redirects to serverqube:22):
qvm-connect-tcp 8022:serverqubename:22 ssh -p 8022 localhost
But don’t do that; that’s just to show how simple it is. Create new named Qubes RPC services for each service you want to expose from serverqube.