ORPort NoAdvertise & NoListen Not Working
Hi! I'm having issues when implementing the NoAdvertise & NoListen options of the ORPort directive and am hoping someone here might be able to point me in the right direction. I can get Tor to successfully work as a relay without using the NoAdvertise & NoListen options of the ORPort directive, but for certain reasons I need to configure Tor on a Private Address. ### ORPort WITHOUT NoAdvertise & NoListen (SUCCEEDS) ### Note: Successful Self-testing logs WITHOUT NoAdvertise & NoListen Aug 13 00:26:42.000 [notice] Self-testing indicates your ORPort 198.91.60.78:443 is reachable from the outside. Excellent. Publishing server descriptor. Aug 13 00:27:49.000 [notice] Performing bandwidth self-test...done. Note: Successful Self-testing torrc WITHOUT NoAdvertise & NoListen # cat /tmp/torrc Nickname ASUSWRTMerlinRelay ORPort 198.91.60.78:443 SocksPort 9050 SocksPort 192.168.0.1:9050 ControlPort 9051 ExitRelay 0 DirCache 0 MaxMemInQueues 192 MB GeoIPFile /opt/share/tor/geoip Log notice file /tmp/torlog VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 192.168.0.1:9040 DNSPort 192.168.0.1:9053 RunAsDaemon 1 DataDirectory /tmp/tor/torrc.d/.tordb AvoidDiskWrites 1 User tor ContactInfo tor-operator@your-emailaddress-domain Note: Nyx shows Tor build the initial 5 measurement circuits and then successfully continues to build new circuits # nyx nyx - gnutech-wap01 (Linux 2.6.36.4b...) Tor 0.4.5.7 (recommended) ASUSWRTMerlinRelay - 198.91.60.78:443, Control Port (open): 9051 cpu: 30.4% tor, 62.1% nyx mem: 53 MB (21.4%) pid: 14372 uptime: 05:18 fingerprint: 02DD61E41B3739C629C5CF8CEBA6000290BC3E7B flags: Fast, Running, Valid page 2 / 5 - m: menu, p: pause, h: page help, q: quit Connections (807 outbound, 9 circuit, 1 control): Note: Openssl s_client is successfully CONNECTED to the Public Address # openssl s_client -connect 198.91.60.78:443 CONNECTED(00000003) depth=0 CN = www.uy24fd6wkrzss.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = www.uy24fd6wkrzss.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=www.uy24fd6wkrzss.net i:/CN=www.bu5cm42gttwqzick.com --- Server certificate -----BEGIN CERTIFICATE----- MIICQzCCAaygAwIBAgIJAOPPF6uxLfr8MA0GCSqGSIb3DQEBCwUAMCMxITAfBgNV BAMMGHd3dy5idTVjbTQyZ3R0d3F6aWNrLmNvbTAeFw0yMTAzMDEwMDAwMDBaFw0y MTA5MjUwMDAwMDBaMCAxHjAcBgNVBAMMFXd3dy51eTI0ZmQ2d2tyenNzLm5ldDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM/1zzI/PdYXIm6p1ZshOzIf AnUfauCPovIutPWBBNi9Q6um6EWYzb7DIKhmiTwijl691ktfylwVIMT8JnGO+1t1 +SooiSp4V1oSkMvoA0Whvhh3jonblvq7cD0FGz9xLVxJEs4I5LPxxDFDcfs5AHV9 wQ1rH+CnGOlBGD2X3jjOVJb1Vp9PZPj5sG4mCyBIfJdbuC1MYkXoOfmi8kY0MkV8 mB/XAODk4GmDTPG76gxAv3Da+10vcABqMNpSwraFZwcBcGOhUnmpKxRmm2dZdz7r tTLcZaaeAYJlNH4fxoG6PdmcPidLnlT4ILX44cXAf+OL4WJgWrRUUexTpI75pW0C AwEAATANBgkqhkiG9w0BAQsFAAOBgQCB9fjVciHTD0YlckPoSTzZJXHkDaBpmBVa 9/GpVLQMA9bK03AkDllycxEbSgB0bd8RjZKd1+3T7ck2FsOOzgIZP0v5U8A0uxA7 58w2yJWmomn9DaKXqwD9HHux905znq3elKzd1M5ZSbQhZdqNmsw8wZUo2ZaPCDHW wBCd2m6Ueg== -----END CERTIFICATE----- subject=/CN=www.uy24fd6wkrzss.net issuer=/CN=www.bu5cm42gttwqzick.com --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1058 bytes and written 428 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: BC7B6CA79A1466768EAE37C7D591FB57F2D351E75B4C43AB16C8B8CBCBEB8E4BA4EDE2FEED8D4036D045F42F3F029585 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1628842910 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- However, Tor fails to work as a relay using the NoAdvertise & NoListen options of the ORPort directive; even though, Openssl s_client is successfully CONNECTED to the Public Address. ### ORPort WITH NoAdvertise & NoListen (FAILS) ### Note: Failed Self-testing logs WITH NoAdvertise & NoListen Aug 13 01:01:46.000 [notice] Now checking whether IPv4 ORPort 198.91.60.78:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Aug 13 01:21:45.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at 198.91.60.78:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Note: Failed Self-testing torrc WITH NoAdvertise & NoListen # cat /tmp/torrc Nickname ASUSWRTMerlinRelay ORPort 198.91.60.78:443 NoListen ORPort 192.168.0.1:9001 NoAdvertise SocksPort 9050 SocksPort 192.168.0.1:9050 ControlPort 9051 ExitRelay 0 DirCache 0 MaxMemInQueues 192 MB GeoIPFile /opt/share/tor/geoip Log notice file /tmp/torlog VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 192.168.0.1:9040 DNSPort 192.168.0.1:9053 RunAsDaemon 1 DataDirectory /tmp/tor/torrc.d/.tordb AvoidDiskWrites 1 User tor ContactInfo tor-operator@your-emailaddress-domain Note: Confirmed that the necessary PortForward between the Public & Private Addresses is in place # iptables -t nat -S | grep :9001 -A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.0.1:9001 Note: Nyx shows Tor build the initial 5 measurement circuits, but after some time fails and only shows the outbound & control connections. # nyx nyx - 192.168.0.1 (Linux 2.6.36.4b...) Tor 0.4.5.7 (recommended) ASUSWRTMerlinRelay - 192.168.0.1:9001, Control Port (open): 9051 cpu: 10.6% tor, 3.2% nyx mem: 55 MB (22.2%) pid: 5374 uptime: 56:32 fingerprint: 02DD61E41B3739C629C5CF8CEBA6000290BC3E7B flags: Fast, Running, Valid page 2 / 5 - m: menu, p: pause, h: page help, q: quit Connections (2289 outbound, 1 control): Note: Openssl s_client is successfully CONNECTED to the Public Address # openssl s_client -connect 198.91.60.78:443 CONNECTED(00000003) depth=0 CN = www.uy24fd6wkrzss.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = www.uy24fd6wkrzss.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=www.uy24fd6wkrzss.net i:/CN=www.bu5cm42gttwqzick.com --- Server certificate -----BEGIN CERTIFICATE----- MIICQzCCAaygAwIBAgIJAOPPF6uxLfr8MA0GCSqGSIb3DQEBCwUAMCMxITAfBgNV BAMMGHd3dy5idTVjbTQyZ3R0d3F6aWNrLmNvbTAeFw0yMTAzMDEwMDAwMDBaFw0y MTA5MjUwMDAwMDBaMCAxHjAcBgNVBAMMFXd3dy51eTI0ZmQ2d2tyenNzLm5ldDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM/1zzI/PdYXIm6p1ZshOzIf AnUfauCPovIutPWBBNi9Q6um6EWYzb7DIKhmiTwijl691ktfylwVIMT8JnGO+1t1 +SooiSp4V1oSkMvoA0Whvhh3jonblvq7cD0FGz9xLVxJEs4I5LPxxDFDcfs5AHV9 wQ1rH+CnGOlBGD2X3jjOVJb1Vp9PZPj5sG4mCyBIfJdbuC1MYkXoOfmi8kY0MkV8 mB/XAODk4GmDTPG76gxAv3Da+10vcABqMNpSwraFZwcBcGOhUnmpKxRmm2dZdz7r tTLcZaaeAYJlNH4fxoG6PdmcPidLnlT4ILX44cXAf+OL4WJgWrRUUexTpI75pW0C AwEAATANBgkqhkiG9w0BAQsFAAOBgQCB9fjVciHTD0YlckPoSTzZJXHkDaBpmBVa 9/GpVLQMA9bK03AkDllycxEbSgB0bd8RjZKd1+3T7ck2FsOOzgIZP0v5U8A0uxA7 58w2yJWmomn9DaKXqwD9HHux905znq3elKzd1M5ZSbQhZdqNmsw8wZUo2ZaPCDHW wBCd2m6Ueg== -----END CERTIFICATE----- subject=/CN=www.uy24fd6wkrzss.net issuer=/CN=www.bu5cm42gttwqzick.com --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1058 bytes and written 428 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: BC7B6CA79A1466768EAE37C7D591FB57F2D351E75B4C43AB16C8B8CBCBEB8E4BA4EDE2FEED8D4036D045F42F3F029585 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1628842910 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- What am I missing? Am I implementing the NoAdvertise & NoListen options of the ORPort directive incorrectly? Thank you for your assistance. Respectfully, Gary
David, The ISP has port 9001 blocked to the Public Address. Do the ports have to be the same, when using NoAdvertise & NoListen with the ORPort directive? Thanks! Gary On Saturday, August 14, 2021, 12:20:36 AM MDT, David Figuera <dfb@mm.st> wrote:
ORPort 198.91.60.78:443 NoListen ORPort 192.168.0.1:9001 NoAdvertise
Why two different ports? _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
All: After reviewing several packet-traces of Tor bound directly to the Public Address:Port vs Tor bound to the Private Address:Port and Advertising the Public Address:Port, I believe I may have found the the issue. It appears that when Tor is bound directly to the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.2 or TLSv1.3 successfully passing self-test. However, when Tor is bound to the Private Address:Port and Advertising the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.0. Tor does not like the TLSv1.0 connections and Resets the them; thus, failing the self-test. The question is... Why are the initial measurement connections initiated from External Tor Nodes via High-Ports with the Private Address:Port binding and Public Advertised Address:Port combination over TLSv1.0? Has anyone successfully implemented the Private Address:Port binding and Public Advertised Address:Port combination that successfully passes self-test whom would be kind enough to share their configuration? Is there a way to force the External Tor Nodes that initiate the measurement connections to use TLSv1.2 or TLSv1.3 with the Private Address:Port binding and Public Advertised Address:Port combination? Thanks, again, for your assistance. Respectfully, Gary On Saturday, August 14, 2021, 2:47:01 AM PDT, Gary C. New <garycnew@yahoo.com> wrote: David, The ISP has port 9001 blocked to the Public Address. Do the ports have to be the same, when using NoAdvertise & NoListen with the ORPort directive? Thanks! Gary On Saturday, August 14, 2021, 12:20:36 AM MDT, David Figuera <dfb@mm.st> wrote:
ORPort 198.91.60.78:443 NoListen ORPort 192.168.0.1:9001 NoAdvertise
Why two different ports? _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Gary C. New wrote:
All:
After reviewing several packet-traces of Tor bound directly to the Public Address:Port vs Tor bound to the Private Address:Port and Advertising the Public Address:Port, I believe I may have found the the issue.
It appears that when Tor is bound directly to the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.2 or TLSv1.3 successfully passing self-test. However, when Tor is bound to the Private Address:Port and Advertising the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.0. Tor does not like the TLSv1.0 connections and Resets the them; thus, failing the self-test.
The question is... Why are the initial measurement connections initiated from External Tor Nodes via High-Ports with the Private Address:Port binding and Public Advertised Address:Port combination over TLSv1.0?
Has anyone successfully implemented the Private Address:Port binding and Public Advertised Address:Port combination that successfully passes self-test whom would be kind enough to share their configuration?
Is there a way to force the External Tor Nodes that initiate the measurement connections to use TLSv1.2 or TLSv1.3 with the Private Address:Port binding and Public Advertised Address:Port combination?
Thanks, again, for your assistance.
Respectfully,
Gary
Thanks for running a relay Gary. Your problem does not make much sense for me, I need more information about your setup. I am using the Public IP NoListen and Private IP NoAdvertise configuration fine, the self test passes. Where is the Public IP in your setup assigned to? A router in your home/enterprise ? Or something upstream at your ISP? What kind of connection do you have from your ISP? I saw in previous posts to this thread that you are using this setup because your ISP blocks port 9001 (Tor relay) -- are you sure they just blindly block the PROTOCOL:PORT configurations (such as TCP:9001) or are they doing some deep packet inspections on all ports in order to block Tor more efficiently? Tor (when runs as a relay) is not designed to protect or hide the fact that it's running Tor from your ISP / upstream provider or network administrator. Which is why, they could inspect, detect and terminate Tor traffic regardless your put in on port 443. They can see you are listening on port 443 but it's not a HTTPS daemon there. They can see this if they look for it in the first place, that is why I am asking if you are 100% sure they only block the PROTOCOL:PORT combination or are they doing any advanced filtering for Tor?
All: It turns out that this issue was related to PortForwarding to the Private Gateway Address (192.168.0.1:9001). The solution was to include an iptables ACCEPT Rule in the INPUT Chain to the PortForward destination (the Private Gateway Address - 192.168.0.1:9001). # iptables -I INPUT -p tcp --dport 9001 -j ACCEPT # iptables -A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.0.1:9001 Now, the Tor Self-Test is returning successfully. However, now, there is an issue with the written/read bytes per second graph, on the metrics.torproject.org site, dropping to zero. Any idea why PortForwarding would cause the written/read bytes per second graph to drop to zero? Respectfully, Gary On Tuesday, August 17, 2021, 7:43:22 AM MDT, Gary C. New <garycnew@yahoo.com> wrote: All: After reviewing several packet-traces of Tor bound directly to the Public Address:Port vs Tor bound to the Private Address:Port and Advertising the Public Address:Port, I believe I may have found the the issue. It appears that when Tor is bound directly to the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.2 or TLSv1.3 successfully passing self-test. However, when Tor is bound to the Private Address:Port and Advertising the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.0. Tor does not like the TLSv1.0 connections and Resets the them; thus, failing the self-test. The question is... Why are the initial measurement connections initiated from External Tor Nodes via High-Ports with the Private Address:Port binding and Public Advertised Address:Port combination over TLSv1.0? Has anyone successfully implemented the Private Address:Port binding and Public Advertised Address:Port combination that successfully passes self-test whom would be kind enough to share their configuration? Is there a way to force the External Tor Nodes that initiate the measurement connections to use TLSv1.2 or TLSv1.3 with the Private Address:Port binding and Public Advertised Address:Port combination? Thanks, again, for your assistance. Respectfully, Gary On Saturday, August 14, 2021, 2:47:01 AM PDT, Gary C. New <garycnew@yahoo.com> wrote: David, The ISP has port 9001 blocked to the Public Address. Do the ports have to be the same, when using NoAdvertise & NoListen with the ORPort directive? Thanks! Gary On Saturday, August 14, 2021, 12:20:36 AM MDT, David Figuera <dfb@mm.st> wrote:
ORPort 198.91.60.78:443 NoListen ORPort 192.168.0.1:9001 NoAdvertise
Why two different ports? _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
All: Nevermind... After roughly 48 hours, the written/read bytes per second graph, on the metrics.torproject.org site, began showing normal activity, again. Please consider this thread resolved. Respectfully, Gary On Monday, August 23, 2021, 2:15:07 AM MDT, Gary C. New <garycnew@yahoo.com> wrote: All: It turns out that this issue was related to PortForwarding to the Private Gateway Address (192.168.0.1:9001). The solution was to include an iptables ACCEPT Rule in the INPUT Chain to the PortForward destination (the Private Gateway Address - 192.168.0.1:9001). # iptables -I INPUT -p tcp --dport 9001 -j ACCEPT # iptables -A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.0.1:9001 Now, the Tor Self-Test is returning successfully. However, now, there is an issue with the written/read bytes per second graph, on the metrics.torproject.org site, dropping to zero. Any idea why PortForwarding would cause the written/read bytes per second graph to drop to zero? Respectfully, Gary On Tuesday, August 17, 2021, 7:43:22 AM MDT, Gary C. New <garycnew@yahoo.com> wrote: All: After reviewing several packet-traces of Tor bound directly to the Public Address:Port vs Tor bound to the Private Address:Port and Advertising the Public Address:Port, I believe I may have found the the issue. It appears that when Tor is bound directly to the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.2 or TLSv1.3 successfully passing self-test. However, when Tor is bound to the Private Address:Port and Advertising the Public Address:Port, the initial measurement connections are initiated from External Tor Nodes via High-Ports to the Public Address:Port over TLSv1.0. Tor does not like the TLSv1.0 connections and Resets the them; thus, failing the self-test. The question is... Why are the initial measurement connections initiated from External Tor Nodes via High-Ports with the Private Address:Port binding and Public Advertised Address:Port combination over TLSv1.0? Has anyone successfully implemented the Private Address:Port binding and Public Advertised Address:Port combination that successfully passes self-test whom would be kind enough to share their configuration? Is there a way to force the External Tor Nodes that initiate the measurement connections to use TLSv1.2 or TLSv1.3 with the Private Address:Port binding and Public Advertised Address:Port combination? Thanks, again, for your assistance. Respectfully, Gary On Saturday, August 14, 2021, 2:47:01 AM PDT, Gary C. New <garycnew@yahoo.com> wrote: David, The ISP has port 9001 blocked to the Public Address. Do the ports have to be the same, when using NoAdvertise & NoListen with the ORPort directive? Thanks! Gary On Saturday, August 14, 2021, 12:20:36 AM MDT, David Figuera <dfb@mm.st> wrote:
ORPort 198.91.60.78:443 NoListen ORPort 192.168.0.1:9001 NoAdvertise
Why two different ports? _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (3)
-
David Figuera -
Gary C. New -
s7r