rustybird / corridor

Tor traffic whitelisting gateway
ISC License
68 stars 6 forks source link

testing on Debian host #28

Open HulaHoopWhonix opened 8 years ago

HulaHoopWhonix commented 8 years ago

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

rustybird commented 8 years ago

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. https://github.com/rustybird/corridor/commit/43f35cdcc9d85658e22ee997cb7f1f5da5a385f3

adrelanos commented 8 years ago

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

HulaHoopWhonix commented 8 years ago

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).

rustybird commented 8 years ago

@adrelanos:

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 https://github.com/rustybird/corridor/issues/3#issuecomment-51514456, 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?

HulaHoopWhonix commented 8 years ago

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.

rustybird commented 8 years ago

@HulaHoopWhonix:

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.

HulaHoopWhonix commented 7 years ago

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?

adrelanos commented 7 years ago

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

HulaHoopWhonix commented 7 years ago

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.

rustybird commented 7 years ago
  • 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.

adrelanos commented 7 years ago

@HulaHoopWhonix

Qubes missing service warning still shows

issue: https://github.com/rustybird/corridor/pull/27 and https://github.com/rustybird/corridor/commit/ce0b65cf4863184487b360361b1f40767e603e0b did not fix it.

HulaHoopWhonix commented 7 years ago

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:

adrelanos commented 7 years ago

Easy to see, that ufw is still hyper active. I recommend to get rid of it. (https://github.com/rustybird/corridor/issues/26#issuecomment-236370163)

rustybird commented 7 years ago

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

HulaHoopWhonix commented 7 years ago

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.

rustybird commented 7 years ago

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.

HulaHoopWhonix commented 7 years ago

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