Any reason not to use qvm-connect-tcp for ouside port forwarding?

User Support General
1

Hello Everyone,

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:

qubes.ConnectTCP +443 sys-net @default allow target=work

Now on sys-net do the following (note I’m using Qubes 4.2, so nfttables, not iptables):

sudo su
echo 'qvm-connect-tcp 443:@default:443` >> /rw/config/rc.local
echo 'nft add rule ip qubes input tcp dport 443 accept' >> /rw/config/rc.local
qvm-connect-tcp 443:@default:443
nft add rule ip qubes input tcp dport 443 accept 
exit

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?

2 Likes
2

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.

2 Likes
3

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!

4

@unman Since there is a question about the docs, and a suggestion for simpler instructions, I suppose you may be interested in this thread.

(I am not familiar enough with the topic to emit an opinion on the alternative, but I suppose you would.)

5

Thank you @face for this great tipp! I’m on Qubes 4.2 too and this is so much more convenient than figuring out the involved port forwarding described in the docs.

Performance, which is the disadvantage of this simple method, seems pretty decent for my simple use case of syncing large files with syncthing. I get ~40MB/s on a Gigabit network with the host being a i7-7820HQ serving from a HDD.

1 Like
6

Hi @doublehelix , can you answer me in pm? I have questions about syncthing setup. Thanks.

7

This sounds great. I’m hosting a local webserver that will launch an app for my partner to use. Id need to forward 1194 since it’s over openvpn that the external machine is connecting. Or I could just have external machine connect to my router then restrict by mac and port 443 for his machine once he’s on my network. What do you think is best approach?

8

I’m not the guy you asked, but I’ve just set up syncthing the same way. You can AMA if you still got questions.

If it’s about the port forwarding then this is what worked for me:

# In dom0:
echo "qubes.ConnectTCP +22000 sys-net @default allow target=syncthingqube" | sudo tee -a /etc/qubes/policy.d/30-user-networking.policy

# In sys-net:
nft add rule ip qubes input tcp dport 22000 accept
qvm-connect-tcp 22000:@default:22000
# Persist it:
echo "nft add rule ip qubes input tcp dport 22000 accept" | sudo tee -a /rw/config/rc.local
echo "qvm-connect-tcp 22000:@default:22000" | sudo tee -a /rw/config/rc.local
1 Like
9

To the original question - qvm-connect-tcp approach has also some other disadvantages, specifically number of concurrent connections. AFAIR the limit is about 50 (or maybe 100?), and beyond that it may prevent making other qrexec connections from sys-net. So, if you expect some more concurrent traffic (or if you intend to expose it to the internet without any limits), better to use the firewall forwarding approach.

1 Like