testing on Debian host #28
Comments
Do I understand it right that you are using corridor as a host firewall?
And does LAN then refer to a virtual network between the guests? In that case, I'd guess they are connected by a (virtual) switch and the traffic never actually reaches corridor. 43f35cd |
Yes, this is what @HulaHoopWhonix is doing.
No. It was a somewhat separate question. I think I can interpret @rustybird's answer as "LAN connections are enabled by default". For suggesting, "block LAN [as in physically separates machines in the LAN] connections by default or have an option for that", I think it is better to make the case for that in a separate ticket. @HulaHoopWhonix |
Yes. By LAN I refer to the physical network. I guess Corridor's current position (in the Qubes context) between the Workstation VM and the Tor Gateway VM requires that it let through traffic destined for private-use IPs. However for Host firewall purposes that is something that's undesirable. (With workarounds for some exceptions discussed above but that's another topic). |
No, the CORRIDOR_FILTER chain does not distinguish between global and private or even localhost addresses at all - if the remote end is not the ORPort of a Tor relay, then the new connection is rejected. Which explains why the inter-Whonix traffic would be blocked by the rule from #3 (comment), which is too aggressive anyway. @HulaHoopWhonix, you could instead try something like But about the second issue, I don't understand why regular LAN traffic would not be caught in your setup. Where is it originating from, a process on the Debian host itself or a KVM guest? |
OK good to know. Makes it easier to know if its working a expected or not. This is embarrassing. I completely forgot to run
however when I did I get:
Can you please make it so that corridor can run this rule automatically if it detects its outside a VM? We use virt-what to detect that. |
It is called CORRIDOR_FILTER now (not CORRIDOR). But again, the original rule was too aggressive anyway, so try the one above.
Oh, this rule would need a hell of a lot more testing before the host firewall stuff could be considered suitable for general use, even only as a configuration option. For example, I remember -o (output interface) checks being problematic in combination with REDIRECT, e.g. transparent torification. |
|
I get a similar error:
I'll try testing as much as possible to get this ready for Debian. Do you think ufw is a cause of conflicts here? |
|
HulaHoopWhonix:
Yes! Because of the interaction. They both use iptables. See: http://serverfault.com/questions/198398/ubuntu-how-to-add-an-iptables-rule-that-ufw-cant-create |
|
Tested version 0.10
I temporarily disabled ufw to exclude interference and got the same result. Offtopic: Does corridor default deny all incoming connections? If so we can advise users to use it as an alternative. |
?
Does the corridor_relays ipset get populated? Try
No, that's out of scope. |
|
|
Debugged some more: Before enabling the CORRIDOR_FILTER: sudo iptables-save-deterministic After enabling the CORRIDOR_FILTER: sudo iptables-save-deterministic Iptables rule diff: diff a b 23,26c23,26 :ufw-after-forward - [0,0]:FORWARD DROP [0,0] ipset: sudo ipset list corridor_relays |
|
Easy to see, that ufw is still hyper active. I recommend to get rid of it. (#26 (comment)) |
So corridor_relays is empty? When using corridor as a host firewall, that probably points to a deadlock which you can solve either
|
Yes.
I think that's the way to go. Can you please include this out of the box?
I'm not sure how effective this is since enabling corridor on a system running Tor beforehand (meaning its fetched its consensus) still blocks it - meaning corridor didn't make use of the consensus data already present. |
Tricky, because the tor daemon can run under different credentials, depending on the distro. And besides, I still don't think that the host firewall stuff is quite ready for general use yet.
Does /var/lib/corridor/relays already exist? If yes, then you're experiencing some other issue. Maybe #32, which is fixed in corridor >= 0.10.2. |
|
Just to be sure, I uninstalled ufw and have the same results. ipset comes up empty
Says it doesn't exist |
Hi. I tested corridor on a Debian host running Whonix KVM guests.
Results:
Two solutions come to mind: adding a LAN permission option to corridor for manual use. Out of scope of this ticket but an interesting topic that should be discussed: add a barebones captive portal responder on the host under its own user account that is exempted by corridor. This keeps leaks absolutely minimal and reduces attack surface when having to deal with captive portals.
/cc @adrelanos
The text was updated successfully, but these errors were encountered: