…Ok so I have a vpn qube and I want to control it with qvm-firewall rules so it can only reach the ip of the vpn server and block everything else. I noticed that it wasn’t working so I “qvm-firewall vm_name reset” and removed the single accept rule that the reset makes. Now with the vpn qube off I add one rule to check my sanity “qvm-firewall vm_name add drop”. Then I start the vpn qube and test with a ping to a well known site and it WORKS, I even manage to connect my vpn. PROVING what I did has not blocked everything leaving the vpn qube when it SHOULD (I think?) surely this is worrying as qvm-firewall is suppose to be a low level networking tool that you should be able to rely on…
Hi and welcome to the forum!
Check this thread for configuring firewall for VPN qubes:
As an example, these are my firewall settings of my Qubes VPN allowing only two Proton VPN hosts for two different connections:
NO ACTION HOST PROTOCOL PORT(S) SPECIAL TARGET ICMP TYPE EXPIRE COMMENT
0 accept 79.127.134.55/32 udp 51820 - - - -
1 accept 79.127.141.53/32 udp 51820 - - - -
Hope this helps.
One thing I’d like to add personally: Maybe it’s a generational thing—I’m already over 60—so a “SERIOUS?” in the title of a thread from a user who’s posting for the first time usually puts me off right away. That’s the kind of tone you see on TikTok or Tinde. I recommend using more sober, rational titles in the future, because I suspect quite a few people here feel the same way as I do.
3 Likes
Yes its similar to what you posted. Now specifically I am talking about the qvm-firewall issue and what is happening. qvm-firewall is misbehaving, contrarian to what is in your link, to how it should be properly working.
Ok, that is quite vague. Can you please provide the exact firewall rules and what you think is “similar” to the setting in the link I provided?
What is your network chain? What NetVM is your VPN Qube using?
1 Like
I confirmed reset with “qvm-firewall vm_name reset” deleted the accept rule with “qvm-firewall vm_name del --rule-no 0” confirmed with “qvm-firewall vm_name list” and drop all with “qvm-firewall vm_name add drop”. I’ve been using these commands and am familiar with them for a few years, and besides I can confirm with qvm-firewall vm_name list that the rule has been applied. So don’t worry you can take what I said seriously, there is a issue. This is a vm that was migrated from qubes 4.2. The whole system was upgraded in-place.
Just done a test…a newly created qube and qvm-firewall = no problems, the block all rule worked and when removed network available again.
Sorry if the SERIOUS? looks a bit clickbaity but it could be a serious issue. I really don’t want to be sober so it gets lost in tons of noob questions. May be posting for the first time but I’m a qubes user now for a few years and using linux for 15 years.
- What is your network chain? What NetVM is your VPN Qube using? vpn qube > whonix_gw
Did not test with a qube brought from 4.2, but can confirm that all is normal in fresh 4.3 qube.
Was just looking at this issue:
Not obviously related, but maybe some connection?
Please just provide us with the full firewall rules (qvm-firewall QUBENAME), it’s very difficult to say what exactly you did from the posts.
2 Likes
I think the issue is that you need to add another rule before removing the allow rule, the firewall must have a least a rule.
If you show the rules at each step, the output should be the same before and after the delete. That’s why the VPN guides does a reset, add a allow rule and then remove the first default rule.
2 Likes
deleted
No, it doesnt. Absent any rule the firewall will fail closed.
I cant reproduce @phceac report on 4.3. Running reset and del --rule-no 0,
PING fails with “packet filtered” from sys-firewall.
Note that changes to the Qubes firewall will not affect existing
streams, but this is not specific to Qubes. As we now use nftables it
should, but it does not.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
2 Likes
Apologies, my language was imprecise.
In a fresh fedora42 disp, after reset, the order of adding a drop and del-ing the allow at rule 0 makes no difference to a ping to 8888, giving packet filtered from the gw in both cases This is normal, for me.
Empty qvm-firewall ruleset also gives packet filtered message, as seen by @unman
Reset gives normal ping.
I think that an incomplete conversion sounds possible, as was observed in the issue linked above.
I need to see the qvm-firewall logs unsure how to do that in dom0. Today I tried disabling ipv6 in the vpn qube which is fedora-43-xfce and no change in behavior. I also went back and made sure I added the drop after reset then deleted rule 0 and no effect. The VM must be stuck in default settings firewall mode which allows all out (maybe qvm-firewall is not even applied) why is it like this probably due to the 4.2 to 4.3 migration, I did have unsupported templates during the post install process which was later rectified but wouldn’t have thought it would matter to the appvms, dvm templates etc derived of. So two things I need to know. I want to look at the qvm-firewall logs and secondly can I do post install conversion for a single specfic qube to test.
I think I found the issue. Whonix gateway does not allow qubes-firewall service to control it (qvm-firewall rules are enforced on the net qube of the target of the qvm-firewall command and will therefore require the qubes-firewall service to be enabled) Bridge Firewall - #5 by texasbilly. So my option here is put a firewall qube after the vpn qube and before whonix gateway.
I suggest if possible some feedback in a error message if qvm-firewall cannot implement the rules.
This is a well known deficiency in Whonix. (If you had at any time
said you were using Whonix this could have immediately been put to
bed. That’s why it is important to provide information at the start.)
If you use a firewall between the VPN and Whonix qubes, then make sure
that you do not attach other qubes to that firewall, as it may limit
stream isolation.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
2 Likes
I did mention it was whonix-gw fairly early on, SERIOUS? qvm-firewall bypass? possibly if you do not understand qvm-firewall and qubes-firewall service! - #5 by superduper
At least maybe someone else might become aware of this pitfall because of this thread? Maybe we can get better confirmation of activation of qvm-firewall rules, can qvm-firewall receive success confirmations back from the netvm qube or is this off for security concerns?
Unfortunately you mentioned it in a edit and some people, including unman, interact with discourse using emails and do not receive the edit events.
2 Likes
deleted
Ok guys fine, will remember. Now a question. Will qvm-firewall work with qubes-firewall service when typed into the custom field in services of a disposable (i.e with disp it doesn’t get populated in the drop down of services in settings of the disp)
If you mean can you run the qubes-firewall service in a disposable, you
can. (sys-firewall is a disposable for many users.) Set provides network
true in the disposable template will work across the board
Just to clear my ideas… is it correct to say that:
If qubes-firewall service is not running in the netvm of my qube, then
- Configuration in the Firewall tab of my qube settings, and new configuration made using qvm-firewall command, are silently ignored, both when my qube starts and when I modify those settings.
- Firewalling of my qube now depends only on internal behaviour of the “upstream” netvm qube(s), and anything my qube implements itself?
- There is no test or warning when my qube starts, to verify the service is running, even when my qube has non-default, restrictive firewall settings?
- In particular, my qube is not blocked from starting in this state?
Unfortunately, i cannot test on a live system right now, so I hope this is not stupid questions. It is based only on OP observations, and the Principle of Least Surprise. Hoping I’ve got it all wrong.
I am not sure, but if it is correct then I am thinking:
- documentation of this is not clear
- ability to set inoperative block/deny firewall rules is maybe an issue
- ability to start a qube with inoperative block/deny firewall rules is maybe an issue
Maybe there are performance or architectural reasons why these things cannot be blocked when the qubes firewalling is inactive?