Comments (17)
I tested corridor on a Debian host running Whonix KVM guests.
Do I understand it right that you are using corridor as a host firewall?
LAN connections are permitted. Is this intentional?
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
from corridor.
Do I understand it right that you are using corridor as a host firewall?
Yes, this is what @HulaHoopWhonix is doing.
And does LAN then refer to a virtual network between the guests?
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
from corridor.
Do I understand it right that you are using corridor as a host firewall?
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).
from corridor.
I think I can interpret @rustybird's answer as "LAN connections are enabled by default"
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
iptables -I OUTPUT ! -o lo ! -d 127.0.0.0/8 -j CORRIDOR_FILTER
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?
from corridor.
if the remote end is not the ORPort of a Tor relay, then the new connection is rejected.
OK good to know. Makes it easier to know if its working a expected or not.
This is embarrassing. I completely forgot to run
sudo iptables -I OUTPUT -j CORRIDOR
however when I did I get:
iptables v1.6.0: Couldn't load target `CORRIDOR':No such file or directory
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.
from corridor.
iptables v1.6.0: Couldn't load target `CORRIDOR':No such file or directory
It is called CORRIDOR_FILTER now (not CORRIDOR). But again, the original rule was too aggressive anyway, so try the one above.
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.
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.
from corridor.
I get a similar error:
sudo iptables -I OUTPUT ! -o lo ! -d 127.0.0.0/8 -j CORRIDOR_FILTER
iptables v1.6.0: Couldn't load target `CORRIDOR_FILTER':No such file or directory
I'll try testing as much as possible to get this ready for Debian. Do you think ufw is a cause of conflicts here?
from corridor.
HulaHoopWhonix:
Do you think ufw is a cause of conflicts here?
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
from corridor.
Tested version 0.10
- Qubes missing service warning still shows
- with workaround corridor starts
- sudo iptables CORRIDOR_FILTER works with no errors. No changes made to ufw.
- all outgoing connections (including Tor connections) on host and whonix are blocked.
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.
from corridor.
- Qubes missing service warning still shows
?
- all outgoing connections (including Tor connections) on host and whonix are blocked.
Does the corridor_relays ipset get populated? Try sudo ipset list corridor_relays
, there should be >2000 members.
Does corridor default deny all incoming connections?
No, that's out of scope.
from corridor.
Qubes missing service warning still shows
issue: #27 and ce0b65c did not fix it.
from corridor.
Debugged some more:
Before enabling the CORRIDOR_FILTER:
sudo iptables-save-deterministic
*mangle
:PREROUTING ACCEPT [0,0]
:INPUT ACCEPT [0,0]
:FORWARD ACCEPT [0,0]
:OUTPUT ACCEPT [0,0]
:POSTROUTING ACCEPT [0,0]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
*nat
:PREROUTING ACCEPT [0,0]
:INPUT ACCEPT [0,0]
:OUTPUT ACCEPT [0,0]
:POSTROUTING ACCEPT [0,0]
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
*filter
:INPUT DROP [0,0]
:FORWARD DROP [0,0]
:OUTPUT ACCEPT [0,0]
:CORRIDOR_FILTER - [0,0]
:ufw-after-forward - [0,0]
:ufw-after-input - [0,0]
:ufw-after-logging-forward - [0,0]
:ufw-after-logging-input - [0,0]
:ufw-after-logging-output - [0,0]
:ufw-after-output - [0,0]
:ufw-before-forward - [0,0]
:ufw-before-input - [0,0]
:ufw-before-logging-forward - [0,0]
:ufw-before-logging-input - [0,0]
:ufw-before-logging-output - [0,0]
:ufw-before-output - [0,0]
:ufw-logging-allow - [0,0]
:ufw-logging-deny - [0,0]
:ufw-not-local - [0,0]
:ufw-reject-forward - [0,0]
:ufw-reject-input - [0,0]
:ufw-reject-output - [0,0]
:ufw-skip-to-policy-forward - [0,0]
:ufw-skip-to-policy-input - [0,0]
:ufw-skip-to-policy-output - [0,0]
:ufw-track-forward - [0,0]
:ufw-track-input - [0,0]
:ufw-track-output - [0,0]
:ufw-user-forward - [0,0]
:ufw-user-input - [0,0]
:ufw-user-limit - [0,0]
:ufw-user-limit-accept - [0,0]
:ufw-user-logging-forward - [0,0]
:ufw-user-logging-input - [0,0]
:ufw-user-logging-output - [0,0]
:ufw-user-output - [0,0]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j CORRIDOR_FILTER
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -o virbr1 -j ACCEPT
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A CORRIDOR_FILTER -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
-A CORRIDOR_FILTER -m set --match-set corridor_relays dst,dst -j RETURN
-A CORRIDOR_FILTER -m set --match-set corridor_logged src -j LOG --log-prefix "corridor: reject " --log-macdecode
-A CORRIDOR_FILTER -j REJECT --reject-with icmp-host-prohibited
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d /32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d /32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
After enabling the CORRIDOR_FILTER:
sudo iptables-save-deterministic
*mangle
:PREROUTING ACCEPT [0,0]
:INPUT ACCEPT [0,0]
:FORWARD ACCEPT [0,0]
:OUTPUT ACCEPT [0,0]
:POSTROUTING ACCEPT [0,0]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
*nat
:PREROUTING ACCEPT [0,0]
:INPUT ACCEPT [0,0]
:OUTPUT ACCEPT [0,0]
:POSTROUTING ACCEPT [0,0]
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
*filter
:INPUT DROP [0,0]
:FORWARD DROP [0,0]
:OUTPUT ACCEPT [0,0]
:CORRIDOR_FILTER - [0,0]
:ufw-after-forward - [0,0]
:ufw-after-input - [0,0]
:ufw-after-logging-forward - [0,0]
:ufw-after-logging-input - [0,0]
:ufw-after-logging-output - [0,0]
:ufw-after-output - [0,0]
:ufw-before-forward - [0,0]
:ufw-before-input - [0,0]
:ufw-before-logging-forward - [0,0]
:ufw-before-logging-input - [0,0]
:ufw-before-logging-output - [0,0]
:ufw-before-output - [0,0]
:ufw-logging-allow - [0,0]
:ufw-logging-deny - [0,0]
:ufw-not-local - [0,0]
:ufw-reject-forward - [0,0]
:ufw-reject-input - [0,0]
:ufw-reject-output - [0,0]
:ufw-skip-to-policy-forward - [0,0]
:ufw-skip-to-policy-input - [0,0]
:ufw-skip-to-policy-output - [0,0]
:ufw-track-forward - [0,0]
:ufw-track-input - [0,0]
:ufw-track-output - [0,0]
:ufw-user-forward - [0,0]
:ufw-user-input - [0,0]
:ufw-user-limit - [0,0]
:ufw-user-limit-accept - [0,0]
:ufw-user-logging-forward - [0,0]
:ufw-user-logging-input - [0,0]
:ufw-user-logging-output - [0,0]
:ufw-user-output - [0,0]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j CORRIDOR_FILTER
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -o virbr1 -j ACCEPT
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT ! -d 127.0.0.0/8 ! -o lo -j CORRIDOR_FILTER
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A CORRIDOR_FILTER -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
-A CORRIDOR_FILTER -m set --match-set corridor_relays dst,dst -j RETURN
-A CORRIDOR_FILTER -m set --match-set corridor_logged src -j LOG --log-prefix "corridor: reject " --log-macdecode
-A CORRIDOR_FILTER -j REJECT --reject-with icmp-host-prohibited
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d /32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d /32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
Iptables rule diff:
diff a b
23,26c23,26
:FORWARD DROP [0,0]
:OUTPUT ACCEPT [0,0]
:CORRIDOR_FILTER - [0,0]
:ufw-after-forward - [0,0]
:FORWARD DROP [0,0]
:OUTPUT ACCEPT [0,0]
:CORRIDOR_FILTER - [0,0]
:ufw-after-forward - [0,0]
86a87
-A OUTPUT ! -d 127.0.0.0/8 ! -o lo -j CORRIDOR_FILTER
ipset:
sudo ipset list corridor_relays
Name: corridor_relays
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 64 maxelem 65536
Size in memory: 128
References: 1
Members:
from corridor.
Easy to see, that ufw is still hyper active. I recommend to get rid of it. (#26 (comment))
from corridor.
ipset:
sudo ipset list corridor_relays
Name: corridor_relays
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 64 maxelem 65536
Size in memory: 128
References: 1
Members:
So corridor_relays is empty? When using corridor as a host firewall, that probably points to a deadlock which you can solve either
- by explicitly adding an iptables rule that allows traffic for the host's tor daemon, or
- by starting tor once without corridor, waiting for tor to load the consensus, and then starting corridor-data, so that the relay list can be saved to /var/lib/corridor/relays.
from corridor.
So corridor_relays is empty?
Yes.
by explicitly adding an iptables rule that allows traffic for the host's tor daemon
I think that's the way to go. Can you please include this out of the box?
by starting tor once without corridor, waiting for tor to load the consensus, and then starting corridor-data, so that the relay list can be saved to /var/lib/corridor/relays.
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.
from corridor.
by explicitly adding an iptables rule that allows traffic for the host's tor daemon
I think that's the way to go. Can you please include this out of the box?
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.
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.
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.
from corridor.
Just to be sure, I uninstalled ufw and have the same results. ipset comes up empty
Does /var/lib/corridor/relays already exist?
Says it doesn't exist
from corridor.
Related Issues (20)
- please avoid symlinks / breaks Debian packaging HOT 4
- please merge qubes subfolder HOT 2
- Qubes mkdir -p "$RELAYS_STATE" missing HOT 1
- Qubes: systemd corridor-data.service should wait for /rw HOT 2
- Qubes: also process /rw/corridor.d configuration folder HOT 2
- firewall lockdown failure mode HOT 1
- clarify alpha / beta / stable
- clarify compatibility with ufw HOT 2
- systemd broken dependencies, ordering cycle, Unknown lvalue 'Require' in section 'Unit' HOT 11
- start corridor-data.service after tor.service HOT 2
- corridor config in /usr/local [/rw] ignored HOT 2
- corridor systemd services hang during corridor upgrades HOT 1
- corridor-init-forwarding.service use Before=shutdown.target Conflicts=shutdown.target HOT 4
- missing make all target HOT 5
- add IPv6 support / port to nftables or Berkeley Packet Filter (BPF) HOT 1
- corridor causes Tor assertion failure on Qubes-Fedora-26-minimal standalone proxyVM HOT 5
- /etc/torrc.d/ vs bridges grep? HOT 4
- systemd WantedBy=multi-user.target correct - resulting in applications using networking before corridor firewall rules are load? HOT 4
- does not fail systemd unit file if folder inaccessible HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from corridor.