Documentation to expose a port externally is unreliable

[ben-grande]

Qubes OS release

For Qubes documentation, I'm on R4.2.3

Brief summary

Qubes doesn't have a good way to expose a port from a qube down the chain to the external interface of sys-net using only firewall rules (NFTables).

Issues with the current method:

• only works with qubes that have a netvm
• unreliable in case of internal qubes ip change, netvm only knows clients by vif, not by name, happens when renaming a qube as it is a clone method
• unreliable in case any netvm is disposable, writing rules to the disposable template instead of loading and updating on runtime is not flexible to change the rules
• unreliable in case a netvm does not provide a shell such as unikernels

Wouldn't it be better if opening a single tcp port to other qube was documented as the preferred way of exposing a port?

Sure, pure nftables avoids Qrexec and socat or systemd sockets, but it seems like provided nftables rules as the preferred way to expose a port to the external interface a hackers note of the possibilities rather than being actually a good implementation.

Could be argued that qubes without Qrexec but network connected will not work using this method.

Without native qubes implementation with qube features and network-hooks in the Qubes codebase, wouldn't it be better if the documentation warned about the problems of the current implementation and suggested using Qrexec when available until Qubes supports exposing a port natively?

The situation is that everybody tries to script it:

• [Contribution] qvm-expose-port #4028

But it is still not reliable for most of the error cases, it can only update to the new internal IP on demand (manual or Qubes Events possibly), but the rest of the issues are not solved.

Steps to reproduce

• Follow doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world.
• Do it completely
• And do one of the following...
  • Rename (clone op) a qube in the network chain
  • Modify the internal qube IP
  • Use a Unikernel netvm
  • Use a disposable netvm
  • Use a disposable for the service qube

Expected behavior

Connection keeps working.

Actual behavior

Connection stops working, firewall rules are not present or outdated.

---

@DemiMarie has commented on Matrix:

A big problem with using qrexec is that it really isn't safe for anything exposed to the public Internet. There are no protections against denial of service attacks.

I replied:

There still the possibility of sys-net firewall and rate limiting, although I see your point that the initial design of Qrexec didn't consider the network, maybe some part of the development of Qubes Air will fix this.