Re: [tor-relays] Snowflakes

2020-10-31 Thread entensaison

Hi Toralf and Gus,
Thanks for your replies!
 
On Wednesday, October 28, 2020 at 4:11 PM, Toralf Förster 
 wrote:

 

On 10/26/20 5:32 PM, entensai...@use.startmail.com wrote:

Hi everybody,
I'm not sure this is the right list to ask, but is it useful to run
snowflake proxies?

I'd say yes.

FWIW I do run it as a ordinary Linux service (git clone + go build)
instead as a plugin in my browser here under Gentoo Linux at my 
desktop.

 So the proxy runs even if I close the browser.

FWIW the plugin tells me :

Number of users your Snowflake has helped circumvent censorship in 
the

last 24 hours: 5

:-)

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


[tor-relays] Snowflakes

2020-10-26 Thread entensaison

Hi everybody,
I'm not sure this is the right list to ask, but is it useful to run 
snowflake

proxies? I only recently realized they can be run by ordinary people.
On the new website I don't see how you would find that out, there 
doesn't

seem to be any link pointing to them.

Metrics only shows a hundred snowflake users.

What is the reason they are not advertised for? (towards humans)

Have a nice day!



 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] "Our IP Address has changed from" log lines

2020-08-14 Thread entensaison

Dear Torix,
 
On Tuesday, August 11, 2020 at 12:10 AM, to...@protonmail.com wrote:
 

Dear list,
 
I get this on just one of my relays -
"Our IP Address has changed from xxx toxxx; rebuilding descriptor 
(source: METHOD=GETHOSTNAME HOSTNAME=xxx).
Aug 11 00:33:54.000 [notice] Your IP address seems to have changed to 
xxx (METHOD=GETHOSTNAME HOSTNAME=xxx). Updating."
This is 99% of my tor log.  What's going on?  Is this normal for a 
middle relay and somewhere I've set the log level to be too 
sensitive?  My torrc log line:
Log notice file /var/log/tor/notices.log # location to log notices, 
warnings, and errors:

But my other relays have the same line.
 
I was looking at this relay because it only seems to connect with the 
bwauths every few days to a week - now not showing at all.  It has 
stayed at 200 connections for the last 6 weeks as a result.  It is 
currently missing completely from the  tor metrics list.  But I have 
no idea if these 2 things are related.  I have run it with and 
without ipv6 with the same results.

 
Any help I would appreciate,
 
--Torix
 
Some ISPs change IPv4 addresses a lot, often combined with short 
periods of disconnection.
So I think the most probable cause for these log lines is that your ISP 
currently has issues providing you with a stable internet connection.
I have also experienced changing IPv4 addresses due to power outages 
that affected the router.

Does your IP address change more than once an hour?

Maybe you can reach out to your ISP to ask what's going on.

There doesn't seem to be anything wrong about the log itself.

 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] trouble with tor relay software on debian

2020-07-20 Thread entensaison

Hi Keifer,
 
On Monday, July 20, 2020 at 7:45 AM, Keifer Bly  
wrote:

 

Hi all,
 
So my middel guard relay at 
 
https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D
 
 
As well as my bridge at  
https://metrics.torproject.org/rs.html#details/EF36AE38C162E96E0645E1DF25EF19522ADBAF90
 
Are not updating, though I had configured them to be updated by 
unattended upgrades they are stuck on tor 4.3.5.

 
When running 
sudo apt update && sudo apt install -y --only-upgrade tor

This is the return, it's a google drive link to the screenshot as
copy pasting the text ended up in a jumbled mess.
https://drive.google.com/file/d/1ULtvt8B28tTwN5DI7oLmfj7mbfBIDh6A/view?usp=sharing
 
It says ip address not found, I wonder why this is as I had imported 
tors keyring before hand.
The picture says you are trying to download packages for Trusty Tahr 
which is from 2014

and was officially supported by Canonical for five years.
It could be that Tor project stopped supporting this version as well.
 

 
 
What's also going on is, I am trying to see how much traffic my relay 
has pushed but am not able to open the log file, when using less 
/var/log/tor/notices.log I am only seeing a black screen with (END) 
and that's it.

 
 
I wonder why this is.
 
Thanks very much,
 
 
--Keifer
 

[icon-envelope-tick-round-orange-animated-no-repeat-v1.gif] 

Virus-free. www.avast.com 

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

2020-07-20 Thread entensaison

Hi list,

First of all, why is email verification not used as an additional 
method for making family settings?
(Additional meaning that operators could choose to either verify their 
mail address or write all their

relays fingerprints in the config.)
Wouldn't it be more convenient to verify the address once and then 
automatically adding every
relay with the same contact to that family. And maybe notify the 
operators so that they can claim
the new relays to be "not theirs" in case somebody else pretended to be 
that operator.



Secondly, how about adding something to the configuration of relays 
with the purpose of showing
inheritance from other configurations in order to make bad relay 
detection easier?


Imagine the guide for running secure relays changed regularly in a way 
that makes the 'version' of
torrc distinguishable by looking at the settings. This could be easily 
achieved by adding a varying

additional field in the settings.
The value of the field is not important, but the name of the field 
should change in an unpredictable
way. Somebody would keep the chronology of old suggested 
configurations.

This way it can be used like non coding DNA for m/paternity testing.

The desired effect:
If a good operator sets up a new relay for the very first time, the 
person reads the guide and
copies this extra line which adds very little extra effort. If the good 
operator sets up many relays
he can automate that and always use the same settings because the good 
operator doesn't need to
hide she is running multiple relays. (This does not replace family 
settings.)
If a bad operator sets up many relays over a long period of time, the 
bad operator cannot automate
this process as the relays would stand out by using outdated 
recommendations that a new operator
would not have found online and that can be related to the other relays 
of the same operator.


The extra information should not de-anonymize relay operators because 
the time when they setup
their relay is usually available through the first seen field and 
family settings are public available too.


The obvious difficulty is, for it to work, the tor relay guide 
containing the altering information should
be so well-written that the majority of new relay operators always 
choose to follow this rather than
other guides that don't change. And it maybe requires different error 
handling.


Anyway this example should only illustrate the basic concept. 
I don't know if that option has been discussed so far.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

2020-07-11 Thread entensaison

Hi,
 
On Sunday, July 5, 2020 at 8:45 PM, Imre Jonk  wrote:
 

Hi nusenu,

On Sun, 2020-07-05 at 18:35 +0200, nusenu wrote:

 

[...]

 

b) require a verified physical address for large operators (>=0.5%
exit or guard probability)
(manual verification, low number of operators).
It is not required that the address is public or stored after it got
verified.
For details see bellow [2].

0.5% exit probability is currently about 500-600 Mbit/s of 
advertised

bandwidth.

That seems reasonable. I currently co-run an exit relay that has just
under 0.1% probability and would be okay with sharing my physical
address with the directory authorities, especially if my probability
would be higher.

This is a great point. Independent of the measures that will be chosen,
they should impact the traffic a relay gets.
Most relay operators want their relays to be useful
and are willing to do put a lot of work into increasing their traffic.
And they should be "rewarded" with flags so that it is obvious
to relay operators that they have an interest in actually
fulfilling the new requirements.
 

[...]
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Unused Relay - could it be because of new guards in the AS?

2020-06-06 Thread entensaison

Hi people,
 
On Saturday, June 6, 2020 at 7:38 AM, petra...@protonmail.ch wrote:
 

Hello all,
my relay is set up to support 42 Mbps, however does not get any real 
traffic routed through it (605EE4375EE4C38215C8949F5808863749FD4F4A). 
I checked anything I could think of but everything looks fine to me. 
Anyone with an idea what could be wrong here? Many thanks!
A few other relays of the same AS as petrarca's relay have become 
guards recently.
Given that tor avoids making circuits with relays from the same AS, how 
much could that impact the traffic a relay gets?

They only provide a small fraction of the whole networks bandwidth.

These are two of them:
https://metrics.torproject.org/rs.html#details/80B8F5AD79F5616EFF8166B4E2128924F90DE8F0
https://metrics.torproject.org/rs.html#details/1690976085F0DD5F08226722DDE01F8606EA7C48

(It would be cool if it was possible to display the traffic history 
aggregated by AS as well.)

 

 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Unused Relay - Why?

2020-06-06 Thread entensaison

Hi friend,
 
On Saturday, June 6, 2020 at 7:38 AM, petra...@protonmail.ch wrote:
 

Hello all,
my relay is set up to support 42 Mbps, however does not get any real 
traffic routed through it (605EE4375EE4C38215C8949F5808863749FD4F4A). 
I checked anything I could think of but everything looks fine to me. 
Anyone with an idea what could be wrong here? Many thanks!


First of all I must admit that I have no idea of what could be causing 
your consensus weight loss.


After all your relay gets used and that is real traffic.
And when you look at other relays you see it is common that the 
advertised bandwidth is only a fraction of the possible bandwidth.
So there should be at least nothing wrong with the advertised 
bandwidth. Or did you observe a decrease of that as well?


I hope you get more helpful replies concerning the consensus weight. 
:-)

What did you already check?

 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] bridge down

2020-05-09 Thread entensaison

Hi,
On Friday, May 8, 2020 at 7:39 PM, Anonforpeace 
 wrote:

 
I have the port forwarded. I've also noticed that the advertised 
bandwidth is only 248 KiB/s on the metrics page. This is a first and 
I'm not sure how to raise the bandwidth. Could this be what's causing 
it to stay offline??
No. The advertised bandwidth tells you how much traffic you were able 
to handle in the last week.
For bridges the advertised bandwidth doesn't influence how much traffic 
you receive.
If you were offline for a week and your relay is still not reachable 
from the outside that's the reason why your advertised bandwidth 
remains low.

Can you share the log lines that show your issue?
Are you able to run a "normal" web service on that computer that is 
accessible from the internet?


 

 Original Message 
On May 8, 2020, 12:35 PM, Paul Geurts wrote:

 
Option: Dynamic internal ip address so the FW rule does point to the 
right internal ip address? 

Machine has been off for a week so the lease could be expired.
 
On Fri, May 8, 2020, 18:19 Anonforpeace  
wrote:
Apologies for the length but detail is important.  My bridge pc's 
internal power supply had to be replaced, and was down for a week.  
After the replacement, I restarted the daemon and the tor service.  
Everything seemed normal except that it's not reachable from 
outside. No configurations have been changed.  The only difference 
I see is a message in the log indicating that the network speed has 
changed/slowed down.  The forwarded port in the router is the same. 
The torrc file has not changed. I can surf the web. Literally the 
only change is the replaced power supply.  Any ideas?

 
Thanks
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] How to Limit Bridge Traffic

2020-03-06 Thread entensaison

Hi,
 
On Thursday, March 5, 2020 at 8:24 PM, Imre Jonk  
wrote:

 

Hi Eddie,

On Wed, 2020-03-04 at 12:34 -0800, Eddie wrote:

Does BandwidthRate apply to bridges.  I can (hopefully) guess that
RelayBandwidth doesn't.
Does the AccountingMax apply.

I am almost certain that all three options apply to bridges as well.
Note that BandwidthRate applies to all TCP data (not the TCP headers 
or

DNS traffic), while RelayBandwidth* applies to the _relayed traffic_
only.
 

I noticed the following in the manual:

If you have bandwidth cost issues, enabling hibernation is 
preferable
to setting a low bandwidth, since it provides users with a 
collection

of fast servers that are up some of the time, which is more useful
than a set of slow servers that are always "available".

Does that advice apply equally to bridges, assuming that the
Accounting options do apply.  Or would it more advantageous for a
bridge to be constantly available, as switching bridges isn't as
seamless as switching relays.

That's an interesting question. Bridges are required to provide at
least 1 Mbit/s bandwidth, but I can't find anything related to uptime
requirements (except for the two hours a day minimum). I'd say that 
the

advice therefore also applies to bridges. The Tor client software can
be configured to use multiple bridges.

I would say the recommendation to use AccountingMax does
not apply for bridges.
It's just a subjective impression but there are often people
complaining that most bridges they get handed out don't
work or stop working after a short time.
Some of these people end up believing that they are unable to
use Tor at all from their location, because their adversary
successfully detected the bridge.
(Which might be true in some cases.)

In order to avoid confusion for people who depend on using bridges
it seems to make more sense to limit the bandwith instead.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] New operator

2019-11-24 Thread entensaison

 
On Thursday, November 21, 2019 at 7:29 PM, Mario Costa 
 wrote:

 

 
Il giorno 21 nov 2019, alle ore 15:49, Matt Traudt 
 ha scritto:


Thanks for running a bridge.

Check Tor's logs to make sure it is actually running and doesn't 
report

issues. Search its hashed fingerprint on
https://metrics.torproject.org/rs.html and make sure it is listed as 
up.
Verify you did *not* set 'PublishServerDescriptor 0'. Verify you can 
use
your bridge from outside your home. I once had a residential ISP 
that

blocked inbound port 80 but not 443.
This actually made me realize that my home router would not properly 
forward ports 80 and 443 from outside. I could connect to my bridge 
from the LAN (even using my external IP) but not from outside. I had 
to change to a non-standard port, unfortunately, because apparently 
80 and 443 are used by the router’s web GUI even if I disabled 
external access to it. That’s a shame because I understand that ports 
80 and 443 are less likely to be blocked by censors.


However, it’s still not clear to me how I can confirm anyone is using 
the bridge.

In the nyx log you see messages like
'In the last X hours we have seen X unique clients' (I don't remember 
the exact wording)

Those are the clients that did use your bridge.
 
When I connect to it, all I see in nyx are OUTBOUND connections and 
not even one inbound connection (maybe that’s by design in order to 
protect connecting users' privacy, I don’t know).

You are probably right.
In the past you could see connecting users in nyx as inbound 
connections without visible IP-address. Now they are not displayed as 
inbound connections any more. The outbound connections that are needed 
for these users are still displayed.

 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Short Research Survey

2019-09-16 Thread entensaison

Hi!
Most online surveys ask the participants to confirm that their replies 
can be used after the last question of the survey. I would recommend 
you to do that, too.
Sometimes people give random answers because they are curious about the 
survey's questions. ;-)

 

Dear Tor relay operators,
 
We are a team of researchers at MIT, and we would like to ask Tor relay 
operators to participate in a short and anonymous survey (no personal 
information or IP address collected). This study is focused on the 
importance of providing anonymity by volunteers in various contexts, 
and will take no more than 5-10 minutes to finish. 

 
You can learn more and take the survey at this link: 
https://mit.co1.qualtrics.com/jfe/form/SV_6W3YXSCnqMVGPs1
 
Your input is very valuable to our study, and we look forward to your 
feedback.

 
Please feel free to email us at anon-resea...@mit.edu if you have any 
questions.

 
(Our survey platform unfortunately uses JavaScript. We apologize for 
being unable to switch it off. We would be grateful for your 
participation if you are comfortable taking the survey.) 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Having Trouble With Speed Of OBFS4 Bridge

2019-01-27 Thread entensaison

Hi Keifer!
 
On Sunday, January 27, 2019 at 8:23 AM, Keifer Bly 
 wrote:

 
Hi, based on the heartbeat log, about 2 clients seem to use the 
bridge every six hours. The log says.


"In the last 6 hours I have seen 2 unique clients. Tor's uptime is 12 
hours, with 0 circuits open."

 

How are you measuring the speed?
On my bridge listing at 
 https://metrics.torproject.org/rs.html#details/148BD64BED9F2C27637D986DE032ECF14E5B9E9A, 
it says "Advertised Bandwidth 59 kb/s"
You could ask a friend to connect to your bridge and download something 
to see if the bandwidth is limited.

 

 

What have you tried to do to change the speed? What happened?
I have double checked there are no firewalls or anti virus which 
would cause the issue, their were not, so nothing should be causing 
speed issues.


As requested, the torrc has been posted with the port numbers removed 
at

paste.debian.net/1062702

Another strange thing is that the ContactInfo string is not showing 
up for some reason, even though when I started tor it said 
"ContactInfo listed more than once, all but the last entry will be 
ignored" or something similar.
It seems like on metrics.torproject.org ContactInfo isn't displayed for 
any bridge. o.O

You can remove the excess lines of ContactInfo.

 

 

-Original Message-
From: tor-relays  On Behalf 
Of teor

Sent: Saturday, January 26, 2019 7:43 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Having Trouble With Speed Of OBFS4 Bridge

 

 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Bridge Relay Internet Speed Much Slower Than Actual Internet Speed

2018-11-13 Thread entensaison

Hi Keifer,

Hello List, my bridge relay at 
https://metrics.torproject.org/rs.html#details/148BD64BED9F2C27637D986DE032ECF14E5B9E9A


Is reporting the relay speed is between 50 kb/s and 60 kb/s, when the 
speed of the internet connection it is running off of is actually 
much faster than this, generally about 50mbps (the relay is running 
on a home internet connection, where the isp is Charter 
Communications / Spectrum). As a result, I have the “fast” flag 
on/off randomly.


I do not want my bridge to suck up a huge amount of my internet 
speed, but why would the  tor software report relay speed that is so 
much slower than the speed of the internet connection it runs off of?


Any thoughts are appreciated, thank you


The advertised bandwidth is not the bandwidth of your
connection but the bandwidth observed.
Your relay probably hasn't been used as a relay so far.
When it's being used the advertised bandwidth will rise.
Are bridges chosen based on their advertised bandwidth?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Question Re: firewall rules for obfs4 bridge relay

2018-10-03 Thread entensaison

Hi Kenneth,
find the answers here: 
https://lists.torproject.org/pipermail/tor-relays/2018-July/015748.html
It would be great to add that to the guide at 
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy 
^^.

 

Hello,

I'm in the process of setting up a couple of obfs4 bridge relays on 
Ubuntu server 18.04. 


I'm endeavoring to apply strict firewall rules to ensure only the 
necessary ports are open.


In accordance with the configuration (below) I've allowed port 9001:

#Bridge config
RunAsDaemon 1
ORPort 9001
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ExtORPort auto

#Set your bridge nickname and contact info
ContactInfo 
Nickname pick-a-nickname

I've also allowed port 9051 to enable me to connect to the obfs4 
server via onionbox.


After starting the Tor service the Tor logs report,

Opening Socks listener on 127.0.0.1:9050

Opening Control listener on 127.0.0.1:9051

Opening OR listener on 0.0.0.0:9001

Extended OR listener listening on port X.

Registered server transport 'obfs4' at '[::]:33919'

All of the ports listed (above) appear to be fixed ports that open 
each time I start/restart Tor. However, the "Extended OR listener 
listening on port X" changes on each start/restart.

 
I can see the configuration (above) instructs ExtORPort auto.
 
I've looked online where there is some advice suggesting the auto 
setting for ExtORPort is important for security reasons, however, if 
I'd like to have strict firewall rules the auto setting becomes 
problematic.

Currently, I've allowed port 9001 & the Tor logs report,

Now checking whether ORPort XXX.XXX.XXX.XX:9001 is reachable...

Self-testing indicates your ORPort is reachable from the outside.

I'd be grateful for some advice on which ports I should keep open, to 
ensure I can provide the very best service & good security practice 
both for the client & the server - thanks :)


Best regards,

Kenneth
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] bridge on the public server - IP reputation

2018-10-01 Thread entensaison

 

HI,

I have a VPS server with fast internet connection.
I would like to configure tor bridge on that machine.

VPS server has configured some services already. If tor bridge 
service

will run on that machine (IP), will it generate any impact for IP
reputation ? I mean blacklisting.

Greetings
Fazii
A bridge's IP is not on a public list. So generally running a bridge 
shouldn't affect your reputation at all.


Average people who don't use tor will not know that you run a bridge on 
that IP and don't care unless you tell them.

Average people who want to use that bridge will appreciate it.
Other service providers will not know about that fact and probably 
don't care either unless you tell them, because it doesn't affect their 
services. Since a bridge is used as a first hop in a tor circuit and 
not as an exit only other tor relays will receive connections from it.
If your ISP doesn't allow you to run a tor relay but doesn't put too 
much effort into monitoring your traffic they'll probably not notice 
that you are running a bridge.
A sensor who tries to block access to the tor network may find out your 
IP and block access to your other services, too.
If you provide a service that is being sensored in some countries then 
people from those countries probably won't be able to connect to your 
bridge either.


 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] bridge not accessible through obfs4 port

2018-07-13 Thread entensaison

 
Today I actually tried to connect to it and it is possible to 
connect to the

bridge using the ORport.
But when I tried to start tor browser with this setting to use 
obfs4:


obfs4 12.345.67.89: (only with the right numbers)

 

it got stuck at "establishing an encrypted network connection".
I checked on canyouseeme.org and both the vanilla ORport and the 
obfs4 port

seem to be accessible from outside.

The obfs4 protocol needs to have not just the IP and port, but also
the shared secret.

For example, a valid obfs4 bridge line looks like:

obfs4 154.35.22.10:15937 8FB9F4319E89E5C6223052AA525A192AFBC85D55 
cert=GGGS1TX4R81m3r0HBl79wKy1OtPPNR2CZUIrHjkRg65Vc2VR8fOyo64f9kmT1UAFG7j0HQ 
iat-mode=0


The other parameters are needed because the client needs to prove
knowledge of the shared secret before the bridge will admit to being 
a

bridge.

That's because one of the steps in the arms race has been "active 
probing"
by China, where they use DPI to notice connections that might be 
obfs4,
and then do their own follow-up connection speaking the obfs4 
protocol,

and if it talks obfs4 back, they know they can block it:
https://www.freehaven.net/anonbib/#foci12-winter
 

My router is set to allow TCP and UDP on the port for obfs4.

obfs4 only needs TCP.

 

 

Thanks for your replies! :)

 
Seems like I followed the instructions on 
https://www.torproject.org/docs/bridges.html.en and replaced obfs3 with 
obfs4 without thinking xD.

 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


[tor-relays] bridge not accessible through obfs4 port

2018-07-13 Thread entensaison

Dear friends,

I am uncuccessfully running a bridge that uses obfs4 as pluggable 
transport. (At least it should.)
Today I actually tried to connect to it and it is possible to connect 
to the bridge using the ORport.

But when I tried to start tor browser with this setting to use obfs4:

obfs4 12.345.67.89: (only with the right numbers)
 

it got stuck at "establishing an encrypted network connection".
I checked on canyouseeme.org and both the vanilla ORport and the obfs4 
port seem to be accessible from outside.


My router is set to allow TCP and UDP on the port for obfs4.

What could be causing the problem?

Cheers,
Lo


 
Am Mittwoch, 11. Juli 2018 um 20:47 schrieb Keifer Bly 
:

 

> In comparison how much bandwidth would a Tor bridge user per month?
 
It would be tough to give an exact answer to that is it depends on 
how many people are connecting through your specific bridge. However 
in general the bandwidth requirements would be much less, as bridges 
are used for mostly areas where the tor network is blocked whereas 
one of the exit relays is used by every client that uses tor at all.

 
You can find more information on this topic here
 
 

https://metrics.torproject.org/stats.html

 
This page contains information about how much traffic different types 
of relays generally send and receive over time, etc.

 
PS, my apologies if this comes through twice for some reason. My 
email client is acting a bit strange at the moment.

 
On Wed, Jul 11, 2018 at 9:04 AM Nathaniel Suchy  
wrote:
Hi. I would like to run a public OBFS4 Tor Bridge. Digitalocean’s 
price changes made running an exit too expensive. In comparison how 
much bandwidth would a Tor bridge use per month?

 
Cheers,
Nathaniel
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


[tor-relays] relay with IPv6 only

2018-04-03 Thread entensaison

Hi people :)

Recently I wanted to setup a relay and realized that I dont have an 
IPv4 address.

(and that's not gonna change for the next two years.)
So do you know if it is going to be possible to run an IPv6-only relay 
soon?
Are there projects I could support already without having an IPv4 
address?


Thanks
Lo
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Publishing bridge contact information

2018-02-12 Thread entensaison

 
Am Montag, 12. Februar 2018 um 12:33 schrieb nusenu 
:

 

If you block the ORPort, won't the reachability check fail?

Fine question. At least this has been the case in the past, though I
know there was discussion and maybe development to overcome this
weakness. But even if it's not possible yet, having bridge contact
information would allow us in the _future_ to reach out to bridge
operators to inform them that they don't have to keep their OR port 
open

anymore, and maybe even shouldn't.
 

https://trac.torproject.org/projects/tor/ticket/7349
https://trac.torproject.org/projects/tor/ticket/17159

Sorry, I'm not sure where to ask this questions
but reading this thread I realizes that I misunderstood this howto:
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy

Is it necessary for the ExtOrPort to be random?
Does the port change automatically?
Is it possible to specify the port?

And how can the wiki pages be changed?

Thanks :)






 

--
https://mastodon.social/@nusenu
twitter: @nusenu_

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays