Chutney tor client connecting to outside authority servers

Question

I am using Chutney to create an internal tor network. I have three authority servers and one exit relay. I am using the templates generated by chutney (networks/basic-min). I have created separate VMs with their own internal IP address and have the three authority servers and exit relays communicating with each other and generating circuits. However, when I try to get the tor client up and running using the chutney client generated template (with some slight modifications) I can't get the client to connect to my tor network. Instead it seems to reach out and get the consensus from the real authority servers and ignores my authority servers. Why won't my tor client connect to my authority servers since I am specifying it in the torrc file?

Here is my notice.log output:

Nov 27 22:40:57.546 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) opening new log file.
Nov 27 22:40:57.522 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1010007f: OpenSSL 1.1.0g  2 Nov 2017; running with 1010100f: OpenSSL 1.1.1  11 Sep 2018).
Nov 27 22:40:57.539 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
Nov 27 22:40:57.540 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 27 22:40:57.540 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Nov 27 22:40:57.540 [notice] Read configuration file "/etc/tor/torrc".
Nov 27 22:40:57.545 [warn] You have used DirAuthority or AlternateDirAuthority to specify alternate directory authorities in your configuration. This is potentially dangerous: it can make you look different from all other Tor users, and hurt your anonymity. Even if you've specified the same authorities as Tor uses by default, the defaults could change in the future. Be sure you know what you're doing.
Nov 27 22:40:57.545 [warn] TestingTorNetwork is set. This will make your node almost unusable in the public Tor network, and is therefore only advised if you are building a testing Tor network!
Nov 27 22:40:57.545 [notice] Scheduler type KIST has been enabled.
Nov 27 22:40:57.546 [notice] Opening Socks listener on 127.0.0.1:9005
Nov 27 22:40:57.546 [notice] Opening Control listener on 127.0.0.1:8005
Nov 27 22:40:57.546 [warn] Your log may contain sensitive information - you disabled SafeLogging, and you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.
Nov 27 22:40:57.546 [notice] Not disabling debugger attaching for unprivileged users.
Nov 27 22:40:57.548 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Nov 27 22:40:57.641 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Nov 27 22:40:57.744 [notice] Bootstrapped 0%: Starting
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'dannenberg' at dannenberg.torauth.de:80 (contact Andreas Lehner; identity 0232AF901C31A04EE9848595AF9BB7620D4C5B2E)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'tor26' at 86.59.21.38:80 (contact Peter Palfrader; identity 14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'longclaw' at 199.58.81.140:80 (contact Riseup Networks <collective at riseup dot net> - 1nNzekuHGGzBYRzyjfjFEfeisNvxkn4RT; identity 23D15D965BC35114467363C165C4F724B64B4F66)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'bastet' at 204.13.164.118:80 (contact stefani <nocat at readthefinemanual dot net> 4096/F4B863AD6642E7EE; identity 27102BC123E7AF1D4741AE047E160C91ADC76B21)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'maatuska' at 171.25.193.9:443 (contact 4096R/1E8BF34923291265 Linus Nordberg <[email protected]>; identity 49015F787433103580E3B66A1707A00E60F2D15B)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'moria1' at 128.31.0.34:9131 (contact 1024D/EB5A896A28988BF5 arma mit edu; identity D586D18309DED4CD6D57C18FDB97EFA96D330566)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'dizum' at 45.66.33.45:80 (contact FD790065EBBD5E7AE6D039620D7F81CD19147711 Alex de Joode <[email protected]>; identity E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'gabelmoo' at 131.188.40.189:80 (contact 4096R/261C5FBE77285F88FB0C343266C8C2D7C5AA446D Sebastian Hahn <[email protected]> - 12NbRAjAG5U3LLWETSF7fSTcdaz32Mu5CN; identity ED03BB616EB2F60BEC80151114BB25CEF515B226)
Nov 27 22:40:57.884 [warn] Consensus includes unrecognized authority 'Faravahar' at 154.35.175.225:80 (contact 0x0B47D56D Sina Rabbani (inf0) <sina redteam net>; identity EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97)
Nov 27 22:40:57.884 [warn] Consensus does not include configured authority 'torauth1' at 192.168.235.143:7000 (identity 659F85E01F83C9E255F88A3CC4AA03CEEC726650)
Nov 27 22:40:57.884 [warn] Consensus does not include configured authority 'torauth2' at 192.168.235.144:7001 (identity 99616D699019CE18F83B8C272077C23F50CD0E0F)
Nov 27 22:40:57.884 [warn] Consensus does not include configured authority 'torauth3' at 192.168.235.145:7002 (identity 5F62E16A29A766A234755AEEEF69F745318F1E14)
Nov 27 22:40:57.884 [warn] A consensus needs 2 good signatures from recognized authorities for us to accept it. This one has 0 (). It has 9 signatures from authorities we don't recognize.
Nov 27 22:40:57.884 [warn] Not enough good signatures on networkstatus consensus
Nov 27 22:40:57.884 [warn] Couldn't load consensus microdesc networkstatus from cache
Nov 27 22:40:57.985 [notice] Starting with guard context "default"
Nov 27 22:40:57.986 [notice] Signaled readiness to systemd
Nov 27 22:40:58.675 [notice] Opening Control listener on /var/run/tor-relay/control
Nov 27 22:40:58.676 [notice] Bootstrapped 5%: Connecting to directory server
Nov 27 22:40:58.676 [notice] Bootstrapped 10%: Finishing handshake with directory server

Answer 1

Ok, after spending some time understanding how chutney works and what I was doing wrong I determined that it was the automatically generated key files that might have been causing this issue. When you run chutney with the 'configure' option, it generates some keys and the torrc file. I was basically copying everything into separate VMs, and this caused the exit relay to behave different. Once I deleted the files in the /var/lib/tor/keys/* directory, the exit relay was able to authenticate with the other authority servers and create a circuit. I did the same thing with the authority servers where I deleted all the keys except for the ones that began with authority_*. This seems to have fixed this issue. I still have problems with the client VM to connect as it fails bootstrapping. But I'm going to create a separate post for this client issue. Thanks Steve!