Hello!
Ok, now I have another strange problem which has suddenly appeared. After I had some problems with the internet provider here and therefore my internet was temporarily unavailable, I found out after everything was up and running again, that my Tor Node starts on 192.169.2.1 instead of my public IP.
My Tor proxy is still working normally on 192.168.1.1.
The only thing I changed is to install another network card on blue that runs on 192.169.2.1. Nothing more.
Where do I have to configure something so that the Tor Relay gets the WAN IP again and also runs?
Jun 25 16:29:53 Tor[21676]: We compiled with OpenSSL 101010ff: OpenSSL 1.1.1o 3 May 2022 and we are running with OpenSSL 101010ff: 1.1.1o. These two versions should be binary compatible.
Jun 25 16:29:53 – Tor[21676]: Tor 0.4.7.7 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1o, Zlib 1.2.12, Liblzma 5.2.5, Libzstd 1.5.2 and Glibc 2.35 as libc.
Jun 25 16:29:53 – Tor[21676]: Tor can’t help you if you use it wrong! Learn how to be safe at Am I totally anonymous if I use Tor? | Tor Project | Support
Jun 25 16:29:53 – Tor[21676]: Read configuration file “/usr/share/tor/defaults-torrc”.
Jun 25 16:29:53 – Tor[21676]: Read configuration file “/etc/tor/torrc”.
Jun 25 16:29:53 – Tor[21676]: Based on detected system memory, MaxMemInQueues is set to 6267 MB. You can override this by setting MaxMemInQueues by hand.
Jun 25 16:29:53 – Tor[21676]: ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That’s bad! You should upgrade your Tor controller as so>
Jun 25 16:29:53 – Tor[21676]: You specified a public address ‘0.0.0.0:9060’ for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don’t allow this unless you have a good reason.
Jun 25 16:29:53 – Tor[21676]: Opening Socks listener on 0.0.0.0:9060
Jun 25 16:29:53 – Tor[21676]: Opened Socks listener connection (ready) on 0.0.0.0:9060
Jun 25 16:29:53 – Tor[21676]: Opening Control listener on 127.0.0.1:9051
Jun 25 16:29:53 – Tor[21676]: Opened Control listener connection (ready) on 127.0.0.1:9051
Jun 25 16:29:53 – Tor[21676]: Opening OR listener on 0.0.0.0:9001
Jun 25 16:29:53 – Tor[21676]: Opened OR listener connection (ready) on 0.0.0.0:9001
Jun 25 16:29:53 – Tor[21676]: Opening Directory listener on 0.0.0.0:9030
Jun 25 16:29:53 – Tor[21676]: Opened Directory listener connection (ready) on 0.0.0.0:9030
Jun 25 16:29:54 – Tor[21676]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jun 25 16:29:54 – Tor[21676]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jun 25 16:29:54 – Tor[21676]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Jun 25 16:29:54 – Tor[21676]: Your Tor server’s identity key fingerprint is ‘XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX’
Jun 25 16:29:54 – Tor[21676]: Your Tor server’s identity key ed25519 fingerprint is ‘XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX’
Jun 25 16:29:54 – Tor[21676]: Bootstrapped 0% (starting): Starting
Jun 25 16:29:55 – Tor[21676]: Starting with guard context “default”
Jun 25 16:29:59 – Tor[21676]: Bootstrapped 5% (conn): Connecting to a relay
Jun 25 16:29:59 – Tor[21676]: Bootstrapped 10% (conn_done): Connected to a relay
Jun 25 16:29:59 – Tor[21676]: Bootstrapped 14% (handshake): Handshaking with a relay
Jun 25 16:30:00 – Tor[21676]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Jun 25 16:30:00 – Tor[21676]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Jun 25 16:30:00 – Tor[21676]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Jun 25 16:30:00 – Tor[21676]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Jun 25 16:30:03 – Tor[21676]: Bootstrapped 100% (done): Done
Jun 25 16:30:03 – Tor[21676]: Now checking whether IPv4 ORPort 192.169.2.1:9001 is reachable… (this may take up to 20 minutes – look for log messages indicating success)
Edit 2: I have improved my mistake in title and post.
Just out of curiosity: Can you elaborate more detailed on this? Did that issue had something to do with IPFire?
According to the screenshot and the log messages given, it actually tries to use 192.169.2.1 as an external IP address. RFC 1918 defines 192.168.0.0/16 as private IPv4 address space, but anything in 192.169.x.x is not covered by that.
This is odd - for some reason, your Tor instance believes that is your IP address. What ISP are you using? Have they started to assign you non-globally routable IPv4 addresses via DHCP or PPPoE?
Ohh yes sorry, this was may fault, tor gets the IP 192.169.2.1 the same as my blue gateway.
I tested it and change the address range of blue to 192.167.1.1 and also tor gets the same IP.
I did not configure any with blue in firewall or something, only run setup make blue active start DHCP and Proxy on blue, that’s all.
I hope it is enough to say that ipfire was no reason for this, because its a long story about fu… 4 weeks and all what I wanted was a new modem.
My ISP is Vodafone with cable internet over DHCP ipv4 address, i get a host from the modem for the red zone.
No, nothing changed, all the same except twice as fast internet.
I also have a somewhat strange kernel message that also started during this time, I don’t know if it’s related because I can’t explain what it is, but could be a completely different problem.
These messages in the system log under kernel come alternately up to 1600 a day–>.
13:15:30 kernel: ll header: 00000000: ff ff ff ff ff 4c e6 76 61 54 ca 08 00
13:15:30 kernel: IPv4: martian source 169.254.255.255 from 169.254.161.179, on dev green0
13:12:48 kernel: ll header: 00000000: ff ff ff ff ff 4c e6 76 61 54 ca 08 06
13:12:48 kernel: IPv4: martian source 192.168.1.1 from 169.254.161.179, on dev green0
What will you use the Blue Network for?
How many devices will be on the Blue network?
How many devices will be on the Green network?
Where did you get the idea to use 192.167.X.X?
It is my third Wlan AP, I don`t know, but I would like to throw my IoT devices out of my green network, because the other two (2,4Ghz&5,0Ghz) access points are hanging in the green network.
Why I changed the subnet to 255.255.0.0 is interesting here, yes because I wanted to reach my modem at 192.168.100.1 earlier and to be sure it works I extended the address range and did the same for the blue network. The number of devices has nothing to do with it, are about 40 in total, which I would then distribute between green and blue.
The modem I can no longer reach, I think was blocked by the provider.
What is the connection with the Tor Relay which always fetches the blue DHCP server as IP address?
I assume that your RED interface is getting a public IP address.
If you insist on staying with the GREEN netmask of 255.255.0.0 (which with 40 devices is not necessary) I suggest you change the BLUE address to a different private address.
If your GREEN range is 192.168.0.0 -192.168.255.255
Then the IP address ranges for the BLUE network should be 10.0.0.0 -10.255.255.255
or 172.16.0.0 -172.31.255.255
And I think that if there are no other needs and the number of devices in the network is less than 254, it is more practical to use a mask of 255.255.255.0
edit:
I made a quick test on the VM
Below BLUE has IP address 192.167.1.1/255.255.0.0
effect - “Relay external address” has the address 192.167.1.1
