Relays not getting the Guard flag?

Good afternoon everyone :slightly_smiling_face:

I have 2 relays :

https://metrics.torproject.org/rs.html#details/CDEB3DEFF99F41233BAE982143365BF4FDE31708
https://metrics.torproject.org/rs.html#details/1417DDCB6819F2D0A885313F5F9D8F6313E134F2

that aren’t getting the Guard flag, although they measure close to 12 days uptime.
And from the logs i dont see them getting DDoS hit.

A third -and my first ever- relay on the same pc,same uptime :

https://metrics.torproject.org/rs.html#details/BCD6F192B49F8E24958FF5E60A1BDF8CEA7D1B51

has the Guard flag.
(It lost the HSDir flag that one, a couple of days back, i guess because it was getting DDoS’ed somewhat, tightened my iptables and hardware firewall at the CPE and now things are quiet.)

Is something wrong, i have exactly the same settings -minus the ports- in all of them, or is it like that, one Guard relay per physical hardware?

Also, on another note, all of my relays cant seem to ramp up consensus, even before i had a DDoS incident.
Is there something i can do/something im doing wrong?

Thanks in advance for your time. :slightly_smiling_face:

Maybe because of The lifecycle of a new relay?

1 Like

That could be the case, but these relays are more than 3 weeks old, and their last uptime measured close to 12 days.
I had previous observed in my other relays, that they were getting the Guard flag much sooner than that. :thinking:

Anyhow,i restarted them now. Fumbled up something in Linux last night (im still learning :sweat_smile:) and had to Timeshift.

Why do you run 4 relay instances on one IP address? What’s the intent?

Probably to better utilize the CPU and provide more bandwidth for the network…

Reasons and context:

This is questionable, because raising the amount of processes also raises the amount of overhead. Has somebody ever done a benchmark test related to it?
And how raising the amount of instances can improve the bandwidth?

I also operate 2 relays per IP address, but the question is whether it is reasonable to have more.

exactly what @atari said,to contribute more since i can.

Περίληψη

(in fact , i can spare bandwith for 8, but alas, i dont have the hardware for that, my -very- old Lynnfield system that i use for the job, wouldn’t possibly cope.
i have 3 on that and 1 on an old Ivy bridge laptop, will migrate that too to the Lynnfield, it can muscle 4,but that’s it.)

https://nothingtohide.nl/blog/2023-07/

@Arte hej, your guard relay lost its guard flag.
https://metrics.torproject.org/rs.html#details/BCD6F192B49F8E24958FF5E60A1BDF8CEA7D1B51

do you remember, what was changed on your site? might be an indicator, why the others did not get it yet…

had to reboot, that’s why. :wink:

long answer :smile: : figured, since a Pi3 can muscle 3-4 relays, hell even an old spare Lynnfield like the one i have for running relays, should be able to do something more than that. so i went for a max 8 relays, and i’ll see how it goes…

But because Enkidu’s script , as great as it is, can be a bit finicky IF you dont know a bit more Linux than the average Windows refugee like me :sweat_smile:,when it is alrdy previously deployed, and then you start adding and changing stuff, i rebooted to clear my iptables.

speaking of iptables, this how i have them 3 days now, dont know if i’s good like that, so if anyone has a suggestion i’m all ears :

it’s Enkidu’s script + the Authorities and Snowflake servers.
It seems to be working fine, at least as DoS defense goes, my relays couldnt be happier.

Your firewall is misconfigured.

It allows any incoming traffic not handled by some rule :joy:
Also the ACCEPT rules are redundant, since they are already included in the default policy.

So switch the default policy to DROP to block any incoming traffic by default:

iptables -P INPUT DROP

Then remove all ACCEPT rules and add the following instead:

iptables -A INPUT -p tcp -d 192.168.1.11 -m multiport --dports 9000,9001,9002,9003,9004,9005,9006,9007 -j ACCEPT

to make only the ORPorts reachable from everywhere.
If you have DirPorts specified, these also have to be reachable from outside.
You can use the same rule for them separately or append the DirPorts to this rule.

Looks fine now :slight_smile:
https://metrics.torproject.org/rs.html#search/family:CDEB3DEFF99F41233BAE982143365BF4FDE31708

Yeah, it has been like that for a few days now! :grin:

My previous fw rules werent working properly, after applying @Enkidu-6 's script (big respect to this guy :saluting_face: :+1: ) + given time , everything is sailing smooth.

1 Like

Well, here’s the thing, all i do on this machine is run my relays + the forum here and other sites of the Project , and reading stuff about Linux mostly over at mint’s forum.
So i dont see the need for any complicated work in the firewall.

As for the relays ports specifically, those are more than well guarded by enkidu’s firewall rules :


This is the most i’ve seen in one relay after 17 days:

The auths accept rules now those are redundant indeed. Thought about removing them, but i like having the counters :sweat_smile:

Your default policy is ACCEPT everywhere. This is the reason, why you have a giant security hole. If you don’t understand it, then good luck.

You don’t need to reboot to clear your iptables rules. All the rules in the script are applied to the mangle table and they are applied PREROUTING to make sure they don’t interfere with your existing rules if any.

To clear them type:

iptables -t mangle -F
ip6tables -t mangle -F
ipset destroy

They will clear all the rules applied by the script and delete your ipset. You can then run multi.sh again

1 Like

Hmm, ok i get it now, i will rectify it. :slightly_smiling_face:

ah, ok thanks! :+1: