The instructions for port forwarding from the outside world to a qube are, involved: Firewall | Qubes OS
They are so involved, many people have written scripts to help facilitate (lol anyone have one for qubes 4.2 nfttables yet?)
However, right above the instructions in the same documentation, is a much simpler solution, qube to qube tunneling built into qubes-os. Why not use it? For example, lets say I want to forward port 443 from the qube work to the outside world:
In dom0/etc/qubes/policy.d/30-user-networking-policy:
I tried this and it works. It’s much simpler, add a single line policy on dom0 and two lines to a rc.local on sys.net. Any reason to do the manual configuration on sys-net, sys-firewall, and work as documented by qubes-os?
Well, after using this tunnel I think I can answer my own question.
I think this is fine and much simpler to configure.
Pros:
Easy to Configure
Cons:
qvm-connect-tcp run’s socat under the hood to facilitate a tunnel. Configuring all the firewall rules on all three qubes is more efficient as there is no process facilitating a tunnel.
For my use case, personally accessing services I’m developing to test from my LAN, the extra resources are negligible.
Since you’re giving not only detailed instructions to reproduce your use of qvm-connect-tcp, but also a summary of the trade-off involved, I think it’s more than fair to mark your second post as the solution of the thread @face!
I’m not sure you can mark your own post as a solution, so I did it to make easier for folks with the same question to see there in an answer to it. Feel free to correct if needed as you see fit! (I’m pretty sure you can do that.)
Thank you for taking the time to document the solution you found!