Tor Relay acts as an Exit with reject *:* [closed]

Question

You can find the solution in the end of this post.

My Tor relay is working as an Exit, but it is configured with ExitPolicy reject *:*.

Hanswurst is the name of my relay.

Arm is giving me the warning, that the torrc differs from what tor's using.

When I perform a SIGHUP to reload the torrc, my relay isn't an exit any longer.

Can i trust the arm connection list?

I use an RaspberryPi to route all wireless connections through the Tor network. Acting as an Tor client only works really well.

Log notice file /var/log/tor/notices.log
#DataDirectory /var/tor
VirtualAddrNetwork 10.192.0.0/10
AutomapHostsSuffixes .onion,.exit
AutomapHostsOnResolve 1
Exitpolicy reject *:*
StrictNodes 1
ExitNodes $E0C2C5223F6C219C5D41F57FFDF65661A36BCDA6, ...
TransPort 9040                      <--------------- Line 23
TransListenAddress 192.168.42.1
AvoidDiskWrites 1
DNSPort 53
DNSListenAddress 192.168.42.1
ControlPort 9051
ControlListenAddress 127.0.0.1:9051
HashedControlPassword 16:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
DisableDebuggerAttachment 0

##Relaystuff
ORPort 9000
Nickname Hanswurst
RelayBandwidthRate 512 KB
RelayBandwidthBurst 1024 KB
ContactInfo sauerbraten[a t]privatdemail{dot]net

I added the ExitPolicy parameter in the default config too, but it made no difference. Every time i start the Tor service, my relay works as an exit. When i reload the config it isn't an exit any longer..

Is my torrc causing that behavior?

Edit: I added the option DisableDebuggerAttachement 0 and got that list. The connections look kinda scary for being a relay..

Edit2: Following the notices.log. I can`t see anything suspicious..

Mar 22 11:45:12.000 [notice] Your Tor server's identity key fingerprint is 'Hanswurst 52211EFD644E7555E849A48D87D1D63A289BB42A'
Mar 22 11:45:22.000 [notice] Reloaded microdescriptor cache.  Found 17310 descriptors.
Mar 22 11:45:34.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.
Mar 22 11:45:35.000 [notice] Guessed our IP address as 46.128.228.XXX (source: 193.23.244.244).
Mar 22 11:45:35.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.
Mar 22 11:45:35.000 [notice] Bootstrapped 5%: Connecting to directory server.
Mar 22 11:45:36.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 1 circuits open. I've sent 2 kB and received 5 kB.
Mar 22 11:45:36.000 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Mar 22 11:45:36.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
Mar 22 11:45:36.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
Mar 22 11:45:36.000 [notice] Bootstrapped 25%: Loading networkstatus consensus.
Mar 22 11:45:40.000 [notice] Bootstrapped 45%: Asking for relay descriptors.
Mar 22 11:45:40.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 0/5310 usable descriptors.
Mar 22 11:45:42.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish.
Mar 22 11:45:43.000 [notice] Bootstrapped 50%: Loading relay descriptors.
Mar 22 11:45:44.000 [notice] Bootstrapped 52%: Loading relay descriptors.
Mar 22 11:45:44.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 96/5310 usable descriptors.
Mar 22 11:45:45.000 [notice] Bootstrapped 54%: Loading relay descriptors.
Mar 22 11:45:45.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 192/5310 usable descriptors.

........

Mar 22 11:46:16.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 3976/5310 usable descriptors.
Mar 22 11:46:17.000 [notice] We now have enough directory information to build circuits.
Mar 22 11:46:17.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
Mar 22 11:46:18.000 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Mar 22 11:46:19.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Mar 22 11:46:20.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Mar 22 11:46:20.000 [notice] Bootstrapped 100%: Done.
Mar 22 11:46:20.000 [notice] Now checking whether ORPort 46.128.228.XXX:9000 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Mar 22 11:46:25.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

EDIT:

Hey I wanted to close that issue. The main problem was that I confused the EXIT of the internal circuit with the EXIT of the Tor network. 2 tickets exist to clarify that UX problem in ARM. 6430 and 12956.

I think for non-general-purpose circuits, we should call that third hop something else. I'm open to suggestions -- one option would be to just call the last hop on a non-exit circuit "Middle" also. Another option would be to call it "Internal".

There exist one more stackexchange question too.

In conclusion, what I have seen is that TOR made internal circuits and called me the EXIT of them. That is not really a problem because I am not an EXIT of the Tor network itself.