testing on Debian host

[HulaHoopWhonix]

Hi. I tested corridor on a Debian host running Whonix KVM guests.

Results:

• It blocks any new Whonix connections after the corridor service successfully starts while Tor connections on the host still work.
• LAN connections are permitted. Is this intentional? Its safer for this to be restricted unless a user wants otherwise. Imagine subscribing to a wireless carrier or ISP which assigns local addresses. Leaking anything to this non-trusted network is dangerous.

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]

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

[adrelanos]

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]

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]

@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 #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?

[HulaHoopWhonix]

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]

@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]

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]

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]

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.

[rustybird]

• 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]

@HulaHoopWhonix

Qubes missing service warning still shows

issue: #27 and ce0b65c did not fix it.

[HulaHoopWhonix]

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]

Easy to see, that ufw is still hyper active. I recommend to get rid of it. (#26 (comment))

[rustybird]

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.

[HulaHoopWhonix]

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.