How to use port forwarding with mirage?

[100111001]

Sorry to ask here a question as an issue, but I couldn't find another "place" to do so.

I started using mirage as my default firewall on qubes and I'm very thrilled about it and the tiny memory footprint.
The setup was quite convenient using this script

For portforwarding I've used this script which is based on iptables.

Unfortunately, this is not working with mirage out of the box and I have to use the heavy-weight linux firewall for some AppVMs.

Can you give me a hint how to create port forwarding for incoming connections with mirage in a qubes setup?

The messages I get, while running the port forwading script are:

Unknown command "QUBESRPC qubes.VMShell dom0" [while processing "QUBESRPC qubes.VMShell dom0"]
TIMESTAMP qrexec-client[19561]: process_io.c:36:handle_vchan_error: Error while vchan send(handle_input stdout), exiting

[palainp]

Hi @100111001 thanks for your report!

Indeed shell commands are not correctly taken into account (see https://github.com/mirage/qubes-mirage-firewall/blob/main/command.ml) and the provided port forwarding script will require a shell compatible with iptables and pipes invocations, which will induce a lot of complexity in the current qubes-mirage-fw.

It sounds plausible (although I didn't looked into it ;) ) to include some sort of command parsing to allow port forwarding from dom0 (this issue may be an enhancement request), but I unfortunately think it will be too complex to reuse the classic script properly :(

[100111001]

Is the summary that with mirage it's currently not possible to setup port forwarding?
If there's a way can, you point me in the right direction?

[palainp]

Yes unfortunately the script will not work with mirage because it runs the netvms chain from the target machine to sys-net and we will not be able to run shell commands when our turn comes.

It will takes a bit of coding work to add something that can handle port forwarding (here and in the port-forwarding script) and I currently don't have the time to do it, but if you want to, you are welcome to add it :)

[clinkist]

Yes unfortunately the script will not work with mirage

I understand that the aforementioned script isn't compatible with qubes-mirage-firewall. But what about port forwarding without any script, manually? How should I approach it?

[palainp]

Thank you for your questions. I think it's possible to parse/understand qvm-run commands (see command.ml) but that would introduce possible runtime issues if parsing fails. Another approach can be adding new kernel parameters, parsed at bootime. To me the first solution is better (and be reviewed carefully to avoid potential security issues) but need to be run at each startup.

[clinkist]

What I meant is more like manually modifying the source code to forward specific ports and recompile the kernel — not pretty, but usable, if the network environment doesn't fluctuate much. Do you have any pointers for that? The blog post which described this approach is quite outdated now.

[palainp]

Oh, it looks like you just want to add a few lines to the NAT table. I've never tried doing that, but I'll have a look and tell you how that can be done. Unfortunately, you'll have to maintain your own fork with these mappings and I'm unsure that solves the initial issue :(

[100111001]

I found another way to use port forwarding in this post:
https://forum.qubes-os.org/t/localsend/23774/16

By using qvm-connect-tcp you can continue using mirage and open ports without the need to use a shell.

[clinkist]

I know about qvm-connect-tcp, but it appears to work only between qubes — which, even though is handy too, doesn't help with opening a port to an outside world. And it works with TCP only, and I also need to manage UDP traffic.

[100111001]

Using the script above, it's possible to open a tcp port to outside world.

[Atrate]

Good to know there's a workaround. Actual port forwarding would still be welcome, though, as in my testing, qvm-connect-tcp suffers from performance issues and causes high resource consumption in dom0 with lots of diverse traffic.

[clinkist]

Oh, it looks like you just want to add a few lines to the NAT table. I've never tried doing that, but I'll have a look and tell you how that can be done. Unfortunately, you'll have to maintain your own fork with these mappings and I'm unsure that solves the initial issue :(

Sorry to pester you with that, but any chance of an update? I would be absolutely fine with maintaining my own fork, since the changes will be probably quite small. But your guidance will be essential to me.