Using corridor, a Tor traffic whitelisting gateway with Whonix KVM

[phabricator-migrator]

Information

ID: 524
PHID: PHID-TASK-pyx5tsjukebk7kwydevq
Author: Patrick
Status at Migration Time: wontfix
Priority at Migration Time: Normal

Description

It’s currently documented for Qubes-Whonix, but not for KVM.

Using corridor, a Tor traffic whitelisting gateway with Whonix ™

It would be good as sanity test that Whonix is leak free today and stays leak free as Whonix developers (future firewall changes T509, IPv6, etc.)

Either as a separate wiki page. Then we could transform many shared contents into wiki templates and re-use them on both pages.

Or on the same wiki page. Then we would work with expand buttons where Qubes, VirtualBox and KVM instructions differ.

Comments

---

HulaHoop

2016-07-20 02:13:26 UTC

Overview of instructions relevant to KVM (feel free to correct me):

• BridgeFirewall instructions and its .d config path
• Should we assume the Whonix repo is enabled and just refer to the already documented steps on enabling it if the user hasn’t done this?
• Is the warning about giving away that someone is a Whonix user valid here? Does this affect non-Qubes Whonix?
• testing/logging/results

When this is tested more it would be great to have by default.

---

Patrick

2016-07-20 04:03:17 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

Overview of instructions relevant to KVM (feel free to correct me):

• BridgeFirewall instructions and its .d config path

Yes.

• Should we assume the Whonix repo is enabled and just refer to the already documented steps on enabling it if the user hasn’t done this?

Since these instructions assume Debian, not Whonix, we cannot assume the
Whonix repo is enabled.

• Is the warning about giving away that someone is a Whonix user valid here?

I did not write that. Connecting to whonix.org [[repository]] would give
away Whonix, most likely.

It is in context of
Hide Tor use from the Internet Service Provider which is
very specific. Would assume someone managed to hide Whonix [and Tor] to
this point by not ideally never visiting Whonix website without Tor
Browser or at least never downloading from whonix.org. Ideally also
hiding Tor. Not sure this is a realistic model at all.

Does this affect non-Qubes Whonix?

No difference between Qubes-Whonix / Non-Qubes-Whonix.

• testing/logging/results

Yes.

When this is tested more it would be great to have by default.

How? Shipping 3 VMs rather than 2 by default?

(This cannot be merged into Whonix-Gateway. It is either,

• corridor-workstation plus corridor-gateway, or
• Whonix-Workstation plus Whonix-Gateway plus corridor-Gateway.)

---

Patrick

2016-07-20 12:53:46 UTC

I think in case of Non-Qubes-Whonix, installing corridor in a VM is not that useful. More useful:

• corridor as a host firewall
• already possible with some configuration
• for Debian hosts [perhaps also any Linux] probably simpler to document and do than creating a new VM and reconfiguring Whonix-Gateway VM to use corridor-gateway VM
• standalone corridor-gateway

---

HulaHoop

2016-07-20 15:52:40 UTC

This cannot be merged into Whonix-Gateway

Oh OK. I hadn’t seen this before posting this question on the forum.

I think in case of Non-Qubes-Whonix, installing corridor in a VM is not that useful. More useful:

+1

corridor as a host firewall

Yes. Maybe make it a dependency of usability (or security-misc)? So its a part of the Whonix host security improvements initiative.

---

Patrick

2016-07-20 16:37:23 UTC

! In T524#9511, @HulaHoop wrote:
corridor as a host firewall

Yes. Maybe make it a dependency of usability (or security-misc)? So its a part of the Whonix host security improvements initiative.

First of all, this very ticket needs to be implemented.

usability-misc dependency, no, since very much out of scope.

security-misc dependency, no, since that would make a non-Tor specific package suddenly result in shipping a firewall that breaks networking for all but Tor connections.

It could be a dependency of a Whonix host package. Perhaps there would be two Whonix host packages. One that permits clearnet traffic and one that does not. Or someone have this configureable. It is speculative, since currently there is no whonix-host package and no Whonix host maintainer. [Besides Qubes OS functioning as a Whonix host.]

---

HulaHoop

2016-07-20 23:04:45 UTC

I’m thinking about how to make this available for KVM users first so it can be run and tested. Then documented to complete this ticket.

• Shipping 3VMs is a no go. Too much build time, download time …

• The Whonix-Host package doesn’t exist and won’t for a long time. I don’t see the need for it yet.

security-misc dependency, no, since that would make a non-Tor specific package suddenly result in shipping a firewall that breaks networking for all but Tor connections.

• What if its not enabled by default. Just merely installed for the user to enable at will?

---

Patrick

2016-07-21 01:59:12 UTC

HulaHoop (HulaHoop):

• The Whonix-Host package doesn’t exist and won’t for a long time. I don’t see the need for it yet.

I guess it would be useful. Depending on security-misc, providing a
firewall, perhaps allowing/blocking clearnet traffic.

( blocking would be useful to implement:
Tips on Remaining Anonymous.
)

Perhaps also install sdwdate.

security-misc dependency, no, since that would make a non-Tor specific package suddenly result in shipping a firewall that breaks networking for all but Tor connections.

• What if its not enabled by default. Just merely installed for the user to enable at will?

That is not how Debian packages are usually made. Once you install them,
they start providing their functionality. Servers automatically start etc.

The corridor package at the moment works like that. Now, the
security-misc package could have a “feature” to disable the corridor
systemd target by default. Such a “feature” sounds like a bug.

Imagine someone using corridor and then installing security-misc, just
wondering it just broke corridor.

I don’t think a dependency would be right or useful. The corridor
package could be manually installed on its own. And if it should be part
of some kind of meta package, it would be a lot better to create a new
packages such as whonix-host or anon-host-enhancements or something like
that.

Such a anon-host-enhancements package or so could depend on both,
security-misc and corridor. That would be a sane and robust solution.

I’m thinking about how to make this available for KVM users first so
it can be run and tested.

Just install corridor on the host and configure it as a host firewall
(already possible with some
configuration)

---

Patrick

2016-07-21 02:03:07 UTC

The current corridor deb package in Whonix repository should work fine on Debian hosts. It just needs testing, documentation and maintenance.

GitHub - adrelanos/corridor: Tor traffic whitelisting gateway - Debian focussed fork of https://github.com/rustybird/corridor

Tor traffic whitelisting gateway - Debian focussed fork of GitHub - rustybird/corridor: Tor traffic whitelisting gateway

sudo apt-get install corridor from Whonix repository. Installation from Debian repository would be better, but I don’t know if that will happen.

Debian request for package (RFP):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829740

---

HulaHoop

2016-07-21 13:10:21 UTC

That is not how Debian packages are usually made. Once you install them, they start providing their functionality. Servers automatically start etc.

OK.

On second thought not including it in the misc package is better because its a full project and not a minor configuration file change.

The current corridor deb package in Whonix repository should work fine on Debian hosts. It just needs testing, documentation and maintenance.

Sounds good. I’ll test.

If I setup the Whonix repo url with apt-transport-tor I should be ok?

Just install corridor on the host and configure it as a host firewall (already possible with some configuration)

Its as simple as running a single command? Does this conflict with ufw?

To remove these rules I can uninstall and restart. What about temporarily disabling corridor to access local resources, how can I do that? (useful for me to include in the documentation).

---

…Perhaps also install sdwdate.

Can these be technically installed right now stand-alone ? - (but need some testing for leak checks that corridor can now do)

I think creating more packages canbe time consuming and probably not useful unless the host relevant packages start to sprawl.

---

Patrick

2016-07-21 18:22:04 UTC

! In T524#9516, @HulaHoop wrote:

That is not how Debian packages are usually made. Once you install them, they start providing their functionality. Servers automatically start etc.

OK.

On second thought not including it in the misc package is better because its a full project and not a minor configuration file change.

Yes.

The current corridor deb package in Whonix repository should work fine on Debian hosts. It just needs testing, documentation and maintenance.

Sounds good. I’ll test.

If I setup the Whonix repo url with apt-transport-tor I should be ok?

Yes.

Just install corridor on the host and configure it as a host firewall (already possible with some configuration)

Its as simple as running a single command?

According to rustybird, it is.

Does this conflict with ufw?

Dunno. Asked upstream.

clarify compatibility with ufw
clarify compatibility with ufw · Issue #26 · rustybird/corridor · GitHub

To remove these rules I can uninstall and restart. What about temporarily disabling corridor to access local resources, how can I do that? (useful for me to include in the documentation).

Good question. I think this needs to be tested.

canonical, corridor specific:

• check iptables rules before installing corridor, store them to file a
• install corridor, check iptables rules again, store them to file b
• stop corridor

sudo service corridor-init-forwarding stop
sudo service corridor-init-snat stop

• check iptables rules again, store them to file c
• then look at them with a diff viewer

Very similar to this very chapter which is not very specific to Whonix:
Dev/Firewall Refactoring - Kicksecure

generic, crude, developers only:
Dev/Firewall Unload - Whonix

Not sure what you meant by local resources. Local connections? LAN connections?

---

…Perhaps also install sdwdate.

Can these be technically installed right now stand-alone ?

Theoretically yes, but there is no maintainer, not regularity tested by me.

• (but need some testing for leak checks that corridor can now do)

I think creating more packages canbe time consuming and probably not useful unless the host relevant packages start to sprawl.

---

HulaHoop

2016-07-22 12:58:42 UTC

Not sure what you meant by local resources. Local connections? LAN connections?

Yes LAN connections.

I’ll gamble and test this. I think your service stop instruction will be enough to temporarily disable it.

---

Patrick

2016-07-22 14:55:27 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

Not sure what you meant by local resources. Local connections? LAN connections?

Yes LAN connections.

Try first if LAN connections are blocked at all. I am not sure they are.

And even if these were blocked, it would be better to add an additional
iptables rule to allow these rather than totally disabling the firewall.

---

HulaHoop

2016-07-23 17:21:41 UTC

I was editing the Whonix packages on Debian host page and you added some changes half way through that almost blew my cover.

My instructions are for anonymously adding the Whonix repos. Most of the new stuff added goes against this. Should I make a new section for this?

---

Patrick

2016-07-23 17:43:51 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

I was editing the Whonix packages on Debian host page and you added some changes half way through that almost blew my cover.

Sorry, I just saw an anonymous edit and it reminded me to use wiki
templates so instructions are consistent everywhere.

My instructions are for anonymously adding the Whonix repos. Most of the new stuff added goes against this. Should I make a new section for this?

Use the wiki template.

https://www.whonix.org/wiki/Template:Whonix-APT-Repository-Add

Introductions about options and two sections with expand buttons.

One:
clear http non-annymous apt

Two:
apt-transport-tor and Whonix hidden service for apt

---

HulaHoop

2016-07-23 17:45:46 UTC

II’ll do it after I test corridor.

---

HulaHoop

2016-07-23 18:15:17 UTC

No luck. Seems it depends on qubes processes that don’t exist:

● corridor-init-forwarding.service - corridor’s forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enable
Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d
└─qubes-service.conf, qubes.conf
Active: inactive (dead)
Condition: start condition failed at Sat
ConditionPathExists=/var/run/qubes-service/corridor was not met

---

Patrick

2016-07-23 18:18:15 UTC

Fow now:

sudo touch /var/run/qubes-service/corridor

And restart systemd services.

I think of something to solve this.

---

Patrick

2016-07-23 18:31:24 UTC

Or…

sudo rm /lib/systemd/system/corridor.target.d/qubes-service.conf

…and reboot should also help.

---

Patrick

2016-07-23 18:38:20 UTC

delete qubes/systemd/corridor.target.d/qubes-service.conf
delete qubes/systemd/corridor.target.d/qubes-service.conf by adrelanos · Pull Request #27 · rustybird/corridor · GitHub

---

HulaHoop

2016-07-23 18:46:45 UTC

I will make them into a template.

One: clear http non-annymous apt

Keeping in line with our safe defaults policy, what is the benefit of adding this? The number of people connecting directly to Whonix repos is so small that it would be very noticed.

I guess if you want to consider server admin needs it would make sense not to rely on TBB but the answer for that is to download the key using gpg from a HS keyserver:

[Announce] GnuPG 2.1.10 released

dirmngr: New option --use-tor. For full support this requires libassuan version 2.4.2 and a patched version of libadns (e.g. adns-1.4-g10-7 as used by the standard Windows installer).

(Needs to be confirmed if dependencies met in Debian for this to happen safely)

EDIT:

Or we can tell them to use Whonix to download the key.

I like that more because less effort.

---

Patrick

2016-07-23 18:59:00 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

I will make them into a template.

One: clear http non-anonymous apt

Keeping in line with our safe defaults policy, what is the benefit of
adding this? The number of people connecting directly to Whonix repos
is so small that it would be very noticed.

Usability. Clear http non-anonymous apt is a lot simpler to set up.

And if Hide Tor use from the Internet Service Provider
does not apply, not really needed.

And if one wanted to go for Hide_Tor_and_Whonix_from_your_ISP, then this
would be difficult since the Debian Tor package automatically connects
to the public Tor network. They would have to configure bridges [or
else] before installing Tor from Debian.

As for security, just using Whonix onion apt may have no benefits if not
using onion apt for everything. (Related to: T399)

I guess if you want to consider server admin needs

No server admin needs. Not sure what you mean by that.

it would make
sense not to rely on TBB but the answer for that is to download the
key using gpg from a HS keyserver:

[Announce] GnuPG 2.1.10 released

dirmngr: New option --use-tor. For full support this requires
libassuan version 2.4.2 and a patched version of libadns (e.g.
adns-1.4-g10-7 as used by the standard Windows installer).

(Needs to be confirmed if dependencies met in Debian for this to
happen safely)

Yes, hiding all, including the signing key download through Tor is
difficult, but worthwhile.

---

HulaHoop

2016-07-23 22:04:10 UTC

      Or...

sudo rm /lib/systemd/system/corridor.target.d/qubes-service.conf

…and reboot should also help.

Unfortunately nothing good:

● corridor-init-forwarding.service - corridor’s forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d
└─qubes-service.conf, qubes.conf
Active: failed (Result: exit-code) since Sat

Main PID: 1810 (code=exited, status=1/FAILURE)

Jul 23 17:23:08 debian systemd[1]: Starting corridor’s forwarding…
Jul 23 17:23:08 debian corridor-init-forwarding[1810]: ipset v6.29: Cannot open session to kernel.
Jul 23 17:23:11 debian systemd[1]: corridor-init-forwarding.service: Main process exited, code=exited, status=1/FAILURE
Jul 23 17:23:11 debian systemd[1]: Failed to start corridor’s forwarding.
Jul 23 17:23:11 debian systemd[1]: corridor-init-forwarding.service: Unit entered failed state.
Jul 23 17:23:11 debian systemd[1]: corridor-init-forwarding.service: Failed with result ‘exit-code’.
Warning: corridor-init-forwarding.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.

---

Patrick

2016-07-23 22:16:20 UTC

HulaHoop (HulaHoop):

Jul 23 17:23:08 debian corridor-init-forwarding[1810]: ipset v6.29: Cannot open session to kernel.

Using Debian jessie?

Can you fix ipset on your system?

Somehow ipset is broken on your system. Debian
Debian -- Error ships 6.23-2. Version 6.29
perhaps comes from Debian stretch? I guess this is a case where mixing
Debian suites (here jessie and stretch) causes issues. Try to avoid
mixing. Use backports if possible, they should not be affected by such
issues.

---

HulaHoop

2016-07-23 22:28:57 UTC

Besides the other solution I tried earlier today

sudo touch /var/run/qubes-service/corridor

And restart systemd services.

gives:

touch: cannot touch ‘/var/run/qubes-service/corridor’: No such file or directory

---

HulaHoop

2016-07-23 22:32:59 UTC

Using Debian jessie?

No on Stretch. I forgot to mention that…

Can you fix ipset on your system?

Somehow ipset is broken on your system. Debian Debian -- Error ships 6.23-2. Version 6.29 perhaps comes from Debian stretch? I guess this is a case where mixing Debian suites (here jessie and stretch) causes issues. Try to avoid mixing. Use backports if possible, they should not be affected by such issues.

What can I do to avoid this besides downgrading which is a huge hassle?

---

HulaHoop

2016-07-23 22:52:37 UTC

---

HulaHoop

2016-07-23 22:52:22 UTC

---

HulaHoop

2016-07-23 23:00:32 UTC

I think I know how to fix it.

---

Patrick

2016-07-23 23:23:23 UTC

touch: cannot touch ‘/var/run/qubes-service/corridor’: No such file or directory

Beforehand:

sudo mkdir /var/run/qubes-service

---

Patrick

2016-07-23 23:26:23 UTC

HulaHoop (HulaHoop):

Why not set the ipset dependency to >=6.23-2 ?

There is no versioned dependency. Upstream assumes “ipset just works”.
Debian packaging declared “ipset any version”.

I think ipset is broken on your system without corridor being involved
at all.

Ok so manually installed ipset from jessie should fix it?

No. Mixing stretch with jessie packages would create a bigger mess.
Don’t. The ipset version you have has to be made to work.

What can I do to avoid this besides downgrading which is a huge hassle?

Fix ipset. Must be a configuration issue or Debian bug etc.

---

HulaHoop

2016-07-24 01:25:29 UTC

● corridor-init-forwarding.service - corridor’s forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d
└─qubes-service.conf, qubes.conf
Active: active (exited) since Sun
Process: 3570 ExecStart=/bin/rm -f /var/run/qubes-service/qubes-firewall (code=exited, status=0/SUCCESS)
Process: 3541 ExecStart=/usr/sbin/corridor-init-forwarding (code=exited, status=0/SUCCESS)
Main PID: 3570 (code=exited, status=0/SUCCESS)

Jul 24 00:10:20 debian systemd[1]: Starting corridor’s forwarding…
Jul 24 00:10:20 debian corridor-init-forwarding[3541]: net.ipv4.ip_forward = 1
Jul 24 00:10:20 debian corridor-init-forwarding[3541]: net.ipv6.conf.all.forwarding = 0
Jul 24 00:10:20 debian systemd[1]: Started corridor’s forwarding.

Corridor testing:

Good news:

Got it working with the workarounds.

Bad news:

• 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? Please ask rustybird. 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.

---

Patrick

2016-07-24 01:42:34 UTC

I don’t know why that is happening. Please take all of this to upstream.

---

Patrick

2016-07-28 15:56:59 UTC

Update of corridor v0.10.0 uploaded to Whonix repository just now. Please update.

• Contains supposed fix for the the /var/run/qubes-service/corridor issue by rustybird. Untested by me.
• Maybe fixes the “Couldn’t load target `CORRIDOR_FILTER’” issue. I have not checked in which version the chain was renamed. Perhaps you talked past each other since you were not using the latest version of corridor because it was not in Whonix repository.

Please also install the usability-misc package from Whonix repository since it provides the iptables-save-deterministic command or get it from elsewhere.

Look how the chains are named in your local iptables rules. Compare with those from corridor iptables commands from corridor source code.

sudo iptables-save-deterministic

---

HulaHoop

2016-07-29 23:20:13 UTC

OK reinstalled new version from scratch.

Got the qubes service error still:

● corridor-init-forwarding.service - corridor’s forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; ve
Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d
└─qubes-service.conf, qubes.conf
Active: inactive (dead)
Condition: start condition failed
ConditionPathExists=/var/run/qubes-service/corridor was not met

I’ll apply the workaround and see what else changed.

---

Patrick

2016-07-30 15:19:16 UTC

ConditionPathExists=/var/run/qubes-service/corridor was not met

Reported this here now:
delete qubes/systemd/corridor.target.d/qubes-service.conf by adrelanos · Pull Request #27 · rustybird/corridor · GitHub

---

It might help to attach the output of iptables-save-deterministic to testing on Debian host · Issue #28 · rustybird/corridor · GitHub. I attach mine below. Yours should look similar. Slight differences may happen due to Qubes vs Debian configuration.

sudo iptables-save-deterministic

*nat
:PREROUTING ACCEPT [0,0]
:INPUT ACCEPT [0,0]
:OUTPUT ACCEPT [0,0]
:POSTROUTING ACCEPT [0,0]
:CORRIDOR_SNAT - [0,0]
-A POSTROUTING -j CORRIDOR_SNAT
-A CORRIDOR_SNAT -s 10.137.0.0/16 ! -d 10.137.0.0/16 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0,0]
:FORWARD ACCEPT [0,0]
:OUTPUT ACCEPT [0,0]
:CORRIDOR_FILTER - [0,0]
-A FORWARD -j CORRIDOR_FILTER
-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
COMMIT

---

HulaHoop

2016-07-31 11:51:33 UTC

Tried doing a clean install of 0.10.0-2. The installation process hangs indefinitely after the last step. I am not able to remove the package because dpkg insists that its still installing:

Setting up corridor (0.10.0-2) …
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-logged.service → /lib/systemd/system/corridor-init-logged.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-snat.service → /lib/systemd/system/corridor-init-snat.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-data.service → /lib/systemd/system/corridor-data.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
Created symlink /etc/systemd/system/systemd-networkd.service.requires/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor.target → /lib/systemd/system/corridor.target.

---

Patrick

2016-07-31 13:57:42 UTC

What hangs? Check processes / process trees.

ps aux

Would be good to know.

Also check the “sudo service … status” of all corridor services.
(Documented on corridor wiki page.) Or perhaps journalctl -u … for all
of them.

Does reboot help? Perhaps it’s just related to the
/var/run/qubes-service/corridor bug fix update.

Also standard Debian ways for removal of broken Debian packages “dpkg
force all” would work.

Enabling verbosity of the maintainer scripts at least the postinst
script might help. For the latter create a file:
/usr/lib/pre.bsh

contents:

set -x

Then during installation we should have more debug output.

---

HulaHoop

2016-07-31 21:35:58 UTC

Postinst verbose:

Preparing to unpack …/corridor_0%3a10.0.0-3_all.deb …
Unpacking corridor (10.0.0-3) …
Processing triggers for man-db (2.7.5-1) …
Setting up corridor (10.0.0-3) …

• set -e
• true ’
  #####################################################################

INFO: BEGIN: corridor postinst configure’ ’

#####################################################################
’

• case “$1” in
• mkdir --parents /var/lib/corridor
• true ‘INFO: debhelper beginning here.’
• deb-systemd-helper unmask corridor-init-logged.service
• deb-systemd-helper --quiet was-enabled corridor-init-logged.service
• deb-systemd-helper enable corridor-init-logged.service
  Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-logged.service → /lib/systemd/system/corridor-init-logged.service.
• deb-systemd-helper unmask corridor-init-snat.service
• deb-systemd-helper --quiet was-enabled corridor-init-snat.service
• deb-systemd-helper enable corridor-init-snat.service
  Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-snat.service → /lib/systemd/system/corridor-init-snat.service.
• deb-systemd-helper unmask corridor-data.service
• deb-systemd-helper --quiet was-enabled corridor-data.service
• deb-systemd-helper enable corridor-data.service
  Created symlink /etc/systemd/system/multi-user.target.wants/corridor-data.service → /lib/systemd/system/corridor-data.service.
• deb-systemd-helper unmask corridor-init-forwarding.service
• deb-systemd-helper --quiet was-enabled corridor-init-forwarding.service
• deb-systemd-helper enable corridor-init-forwarding.service
  Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
  Created symlink /etc/systemd/system/systemd-networkd.service.requires/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
• deb-systemd-helper unmask corridor.target
• deb-systemd-helper --quiet was-enabled corridor.target
• deb-systemd-helper enable corridor.target
  Created symlink /etc/systemd/system/multi-user.target.wants/corridor.target → /lib/systemd/system/corridor.target.
• ‘[’ -d /run/systemd/system ‘]’
• systemctl --system daemon-reload
• deb-systemd-invoke start corridor-init-logged.service corridor-init-snat.service corridor-data.service corridor-init-forwarding.service corridor.target

sudo journalctl -u corridor*

– Logs begin at
25 debian systemd[1]: Started corridor’s relay list.
25 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
25 debian corridor-data[1917]: :25 socat[1923] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
26 debian systemd[1]: Starting corridor’s forwarding…
26 debian systemd[1]: Starting corridor’s logging…
26 debian systemd[1]: Starting corridor’s source NAT…
27 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
27 debian corridor-data[1917]: :27 socat[1949] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
27 debian systemd[1]: Started corridor’s source NAT.
28 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
28 debian corridor-data[1917]: :28 socat[1993] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
28 debian corridor-init-forwarding[1936]: net.ipv4.ip_forward = 1
28 debian corridor-init-forwarding[1936]: net.ipv6.conf.all.forwarding = 0
28 debian systemd[1]: Started corridor’s forwarding.
29 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
29 debian corridor-data[1917]: :29 socat[2032] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
30 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
30 debian corridor-data[1917]: :30 socat[2057] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
31 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
31 debian corridor-data[1917]: :31 socat[2068] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
32 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
32 debian corridor-data[1917]: :32 socat[2093] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
33 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
33 debian corridor-data[1917]: :33 socat[2195] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
34 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
34 debian corridor-data[1917]: :34 socat[2212] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
35 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
35 debian corridor-data[1917]: :35 socat[2228] E connect(5, AF=1 “/var/run/tor/control”, 22): No such file or directory
36 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
52 debian corridor-data[1917]: 515 Authentication failed: Wrong length on authentication cookie.
53 debian corridor-data[1917]: :53 socat[3031] E write(1, 0x2551aa0, 7963): Broken pipe
55 debian corridor-data[1917]: :55 socat[3072] E write(1, 0x853aa0, 7963): Broken pipe
56 debian corridor-data[1917]: :56 socat[3101] E write(1, 0x1235aa0, 7963): Broken pipe
57 debian corridor-data[1917]: :57 socat[3119] E write(1, 0x1de4aa0, 7963): Broken pipe
59 debian corridor-data[1917]: :59 socat[3127] E write(1, 0x10daaa0, 7963): Broken pipe
00 debian corridor-data[1917]: :00 socat[3138] E write(1, 0x14eeaa0, 7963): Broken pipe
01 debian corridor-data[1917]: :01 socat[3148] E write(1, 0x2668aa0, 7963): Broken pipe
03 debian corridor-data[1917]: :03 socat[3161] E write(1, 0xee1aa0, 7963): Broken pipe
04 debian corridor-data[1917]: :04 socat[3189] E write(1, 0x80daa0, 7963): Broken pipe
05 debian corridor-data[1917]: :05 socat[3206] E write(1, 0x1b9caa0, 7963): Broken pipe
07 debian corridor-data[1917]: :07 socat[3218] E write(1, 0xecfaa0, 7963): Broken pipe
08 debian corridor-data[1917]: :08 socat[3245] E write(1, 0x2072aa0, 7963): Broken pipe
09 debian corridor-data[1917]: :09 socat[3272] E write(1, 0x1e36aa0, 7963): Broken pipe
11 debian corridor-data[1917]: :11 socat[3298] E write(1, 0x9f0aa0, 7963): Broken pipe
12 debian corridor-data[1917]: :12 socat[3315] E write(1, 0xfb3aa0, 7963): Broken pipe
13 debian corridor-data[1917]: :13 socat[3338] E write(1, 0x1845aa0, 7963): Broken pipe
15 debian corridor-data[1917]: :15 socat[3359] E write(1, 0x705aa0, 7963): Broken pipe
16 debian corridor-data[1917]: :16 socat[3370] E write(1, 0xe9eaa0, 7963): Broken pipe
17 debian corridor-data[1917]: :17 socat[3377] E write(1, 0xf7daa0, 7963): Broken pipe
19 debian corridor-data[1917]: :19 socat[3394] E write(1, 0x1d6eaa0, 7963): Broken pipe
20 debian corridor-data[1917]: :20 socat[3413] E write(1, 0x1dd6aa0, 7963): Broken pipe
22 debian corridor-data[1917]: :22 socat[3422] E write(1, 0x2034aa0, 7963): Broken pipe
lines 1-53

sudo systemctl status corridor*

● corridor-init-logged.service - corridor’s logging
Loaded: loaded (/lib/systemd/system/corridor-init-logged.service; enabled; vendor
Drop-In: /lib/systemd/system/corridor-init-logged.service.d
└─qubes-service.conf, qubes.conf
Active: activating (start) since
Main PID: 5776 (corridor-init-l)
CGroup: /system.slice/corridor-init-logged.service
├─5776 /bin/sh -e /usr/sbin/corridor-init-logged
└─8636 sleep 1

debian systemd[1]: Starting corridor’s logging…

---

Patrick

2016-07-31 22:21:18 UTC

Probably two things here.

• 1. corridor not being robust if Tor has issues
• 2. your Tor having issues

---

1) I reported some bugs upstream that might fix this.

• start corridor-data.service after tor.service · Issue #30 · rustybird/corridor · GitHub
• corridor systemd services hang during corridor upgrades · Issue #32 · rustybird/corridor · GitHub

---

2)

Do you have Tor running?

sudo service tor status

sudo service tor@default status

Did Tor create the required files?

sudo ls -la /var/run/tor/control

sudo ls -la /var/run/tor/control.authcookie

These are owned by user/group debian-tor?

---

On Debian the Tor control socket should already be set up by default.

cat /usr/share/tor/tor-service-defaults-torrc

DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
RunAsDaemon 1
User debian-tor

ControlSocket /var/run/tor/control
ControlSocketsGroupWritable 1

CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/run/tor/control.authcookie

Log notice file /var/log/tor/log

---

If it hangs at deb-systemd-invoke, as a workaround you should be able to just kill that process.

sudo killall deb-systemd-invoke

Or search the pid with ps aux or some other process manager and sigterm/sigkill it as root. Verify it was really terminated. Then the postinst and package installation should successfully continue. That should be good enough for reboot and test how it works.

---

HulaHoop

2016-08-01 14:58:54 UTC

Results: Tor is running properly the auth cookie exists and the torrc file looks sane.

I think its the order of service initialization that rusty talks about that is causing this. I’ll wait for the newer version by rusty to be uploaded before I test again.

---

Patrick

2016-08-01 15:10:27 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

Results: Tor is running properly the auth cookie exists and the torrc file looks sane.

Good.

I think its the order of service initialization that rusty talks about that is causing this. I’ll wait for the newer version by rusty to be uploaded before I test again.

That new version will only have cosmetic advantages. Better looking logs.

Will likely not solve any other issues you are having. Most likely will
not solve any issues you could not solve by manually restarting corridor
systemd services after the system finished booting.

---

Patrick

2016-08-01 15:11:18 UTC

Therefore, no need to wait for that reason. Testing, debugging, upstream
bug reporting now is as good as later.

---

HulaHoop

2016-08-01 23:54:54 UTC

OK posted:

testing on Debian host · Issue #28 · rustybird/corridor · GitHub

---

Patrick

2016-11-30 22:32:23 UTC

I somehow doubt rustybird is going to move this forward because rustybird is a Qubes host, not Debian host user. Without third party contributions to corridor, probably not going to happen. (Meanwhile other Qubes specific software was released, split-browser for Qubes.)

---

HulaHoop

2016-12-14 21:09:51 UTC

Agreed. This is good as dead. Feel free to close.