I'm still having trouble connecting to my obfsproxy bridge; Any pointers would be appreciated. External scanning indicates that the correct ports are open except for port 443 but it's definitely open on the firewall.
lee@li388-156:~$ nmap -p 22,443,9001,40872,52176 173.255.119.202 Starting Nmap 5.21 ( http://nmap.org ) at 2013-08-21 16:44 EDT Nmap scan report for 202.119.255.173.bc.googleusercontent.com (173.255.119.202) Host is up (0.16s latency). PORT STATE SERVICE 22/tcp open ssh 443/tcp closed https 9001/tcp open tor-orport 40872/tcp open unknown 52176/tcp open unknown lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443 connect: Connection refused connect:errno=111 maybe this? https://trac.torproject.org/projects/tor/ticket/5104 Confirming that 443 is accessible: lee@tor-bootstrap:~$ sudo python -m SimpleHTTPServer 443 Serving HTTP on 0.0.0.0 port 443 ... 106.187.45.156 - - [21/Aug/2013 22:39:16] code 400, message Bad request syntax ('\x16\x03\x01\x00\xdc\x01\x00\x00\xd8\x03\x02R\x15A\x94\xc5\xfc\xc1(\x04O\xe0\xee@\x92d\x17.\xd9N\xa1Q\xb3$_\xa6H\xc6adp\xa11\x00\x00f\xc0\x14\xc0') 106.187.45.156 - - [21/Aug/2013 22:39:16] "��RA����(O��@�d.�N�Q�$_�H�adp�1f��" 400 - lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443 CONNECTED(00000003) 140181545842336:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:749: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 225 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- On Thu, Aug 15, 2013 at 10:14 AM, lee colleton <[email protected]> wrote: > -tor-relay > +tor-relays > > > On Thu, Aug 15, 2013 at 10:13 AM, lee colleton <[email protected]> wrote: > >> All of the ports respond on the external IP except for 443 but I can >> connect via SSL on 9001. I don't understand how ORListenAddress is >> supposed to work: my bridge times out on 443 but when I comment out the >> ORListenAddress >> line it doesn't connect via obfsproxy at all. >> >> Please advise. >> >> >> On Thu, Aug 15, 2013 at 1:47 AM, lee colleton <[email protected]> wrote: >> >>> With the ORListenAddress line uncommented, a slightly different failure >>> results: >>> >>> Orbot is starting… >>> Orbot is starting… >>> got tor proc id: 28490 >>> Tor process id=28490 >>> >>> Connecting to control port: 9051 >>> SUCCESS connected to control port >>> SUCCESS authenticated to control port >>> Starting Tor client… complete. >>> adding control port event handler >>> SUCCESS added control port event handler >>> Starting privoxy process >>> /data/data/org.torproject.android/app_bin/privoxy >>> /data/data/org.torproject.android/app_bin/privoxy.config & >>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. >>> I've sent 0 kB and received 0 kB. >>> Privoxy is running on port:8118 >>> Privoxy process id=28508 >>> >>> Network connectivity is good. Waking Tor up... >>> Circuit (1) LAUNCHED: >>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>> orConnStatus (173.255.119.202:443): LAUNCHED >>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443. >>> Giving up. (waiting for circuit) >>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> >>> On Aug 15, 2013 1:41 AM, "lee colleton" <[email protected]> wrote: >>> >>>> When I attempt to connect to this bridge, I see a failure in >>>> handshaking: >>>> >>>> Orbot is starting… >>>> Orbot is starting… >>>> got tor proc id: 27365 >>>> Tor process id=27365 >>>> Connecting to control port: 9051 >>>> SUCCESS connected to control port >>>> SUCCESS authenticated to control port >>>> Starting Tor client… complete. >>>> adding control port event handler >>>> SUCCESS added control port event handler >>>> Starting privoxy process >>>> /data/data/org.torproject.android/app_bin/privoxy >>>> /data/data/org.torproject.android/app_bin/privoxy.config & >>>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. >>>> I've sent 0 kB and received 0 kB. >>>> Privoxy is running on port:8118 >>>> Privoxy process id=27393 >>>> Network connectivity is good. Waking Tor up... >>>> Circuit (1) LAUNCHED: >>>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>>> orConnStatus (173.255.119.202:443): LAUNCHED >>>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>>> NOTICE: We weren't able to find support for all of the TLS ciphersuites >>>> that we wanted to advertise. This won't hurt security, but it might make >>>> your Tor (if run as a client) more easy for censors to block. >>>> NOTICE: To correct this, use a more recent OpenSSL, built without >>>> disabling any secure ciphers or features. >>>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>>> orConnStatus (173.255.119.202:443): FAILED >>>> WARN: Problem bootstrapping. Stuck at 10%: Finishing handshake with >>>> directory server. (DONE; DONE; count 1; recommendation warn) >>>> WARN: 1 connections have failed: >>>> WARN: 1 connections died in state handshaking (TLS) with SSL state >>>> SSLv2/v3 read server hello A in HANDSHAKE >>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>>> take care of the DNS resolution itself if necessary. This is good. >>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>>> take care of the DNS resolution itself if necessary. This is good. >>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>>> take care of the DNS resolution itself if necessary. This is good. >>>> On Aug 15, 2013 12:31 AM, "lee colleton" <[email protected]> wrote: >>>> >>>>> When I comment out the ORListenAddress line things look OK. >>>>> >>>>> # Listen on a port other than the one advertised in ORPort (that is, >>>>> # advertise 443 but bind to 9001). >>>>> #ORListenAddress 0.0.0.0:9001 >>>>> >>>>> Aug 15 06:52:50.000 [notice] Tor 0.2.4.16-rc (git-dcf6b6d7dda9ffbd) >>>>> opening log file. >>>>> Aug 15 06:52:50.000 [notice] We were built to run on a 64-bit CPU, with >>>>> OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently >>>>> lacks accelerated support for the NIST P-224 and P-256 groups. Building >>>>> openssl with such support (using the enable-ec_nistp_64_gcc_128 option >>>>> when configuring it) would make ECDH much faster. >>>>> Aug 15 06:52:50.000 [notice] Your Tor server's identity key fingerprint >>>>> is 'gcedemo 08C752E8E86EB5916574A8625030B0EC204EABB8' >>>>> Aug 15 06:52:50.000 [notice] Configured hibernation. This interval began >>>>> at 2013-08-15 00:00:00; the scheduled wake-up time was 2013-08-15 >>>>> 00:00:00; we expect to exhaust our quota for this interval around >>>>> 2013-08-16 00:00:00; the next interval begins at 2013-08-16 00:00:00 (all >>>>> times local) >>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. >>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv6 file >>>>> /usr/share/tor/geoip6. >>>>> Aug 15 06:52:50.000 [notice] Configured to measure statistics. Look for >>>>> the *-stats files that will first be written to the data directory in 24 >>>>> hours from now. >>>>> Aug 15 06:52:51.000 [notice] We now have enough directory information to >>>>> build circuits. >>>>> Aug 15 06:52:51.000 [notice] Bootstrapped 80%: Connecting to the Tor >>>>> network. >>>>> Aug 15 06:52:52.000 [notice] Bootstrapped 85%: Finishing handshake with >>>>> first hop. >>>>> Aug 15 06:52:53.000 [notice] Guessed our IP address as 173.255.119.202 >>>>> (source: 38.229.70.33). >>>>> Aug 15 06:52:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. >>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs3' at >>>>> '0.0.0.0:40872' >>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs2' at >>>>> '0.0.0.0:52176' >>>>> Aug 15 06:52:55.000 [notice] Tor has successfully opened a circuit. Looks >>>>> like client functionality is working. >>>>> Aug 15 06:52:55.000 [notice] Bootstrapped 100%: Done. >>>>> Aug 15 06:52:55.000 [notice] Now checking whether ORPort >>>>> 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- >>>>> look for log messages indicating success) >>>>> Aug 15 06:53:04.000 [notice] New control connection opened. >>>>> Aug 15 07:10:11.000 [notice] Self-testing indicates your ORPort is >>>>> reachable from the outside. Excellent. Publishing server descriptor. >>>>> >>>>> >>>>> >>>>> On Wed, Aug 14, 2013 at 9:53 PM, lee colleton <[email protected]>wrote: >>>>> >>>>>> Yes, I've opened the ports in the Google Compute Engine (see below). >>>>>> I'll follow up on their forum to make sure I've altered the firewall >>>>>> properly. >>>>>> >>>>>> --lee >>>>>> >>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" >>>>>> --project="colleton.net:tor-cloud" listfirewalls >>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>> | name | description | >>>>>> network | source-ips | source-tags | target-tags | >>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>> | default-allow-internal | Internal traffic from default allowed | >>>>>> default | 10.0.0.0/8 | | | >>>>>> | default-ssh | SSH allowed from anywhere | >>>>>> default | 0.0.0.0/0 | | | >>>>>> | tor-obfsproxy | | >>>>>> default | 0.0.0.0/0 | | obfsproxy | >>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" >>>>>> --project="colleton.net:tor-cloud" getfirewall tor-obfsproxy >>>>>> +---------------+-------------------------------+ >>>>>> | property | value | >>>>>> +---------------+-------------------------------+ >>>>>> | name | tor-obfsproxy | >>>>>> | description | | >>>>>> | creation-time | 2013-08-07T18:37:35.986-07:00 | >>>>>> | network | default | >>>>>> | source-ips | 0.0.0.0/0 | >>>>>> | source-tags | | >>>>>> | target-tags | obfsproxy | >>>>>> | allowed | tcp: 443, 9001, 40872, 52176 | >>>>>> +---------------+-------------------------------+ >>>>>> lee@li388-156:~$ >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 14, 2013 at 9:19 PM, Roger Dingledine <[email protected]>wrote: >>>>>> >>>>>>> On Wed, Aug 14, 2013 at 09:08:03AM -0700, lee colleton wrote: >>>>>>> > There's a more serious issue in that my server doesn't appear to be >>>>>>> > reachable. I've opened tcp:443,9001 along with the two >>>>>>> specifiedobfsproxy >>>>>>> > ports >>>>>>> > >>>>>>> > Aug 14 15:26:58.000 [notice] Bootstrapped 100%: Done. >>>>>>> > Aug 14 15:26:58.000 [notice] Now checking whether ORPort >>>>>>> > 173.255.119.202:443 is reachable... (this may take up to 20 >>>>>>> minutes -- >>>>>>> > look for log messages indicating success) >>>>>>> > Aug 14 15:28:00.000 [notice] New control connection opened. >>>>>>> > Aug 14 15:46:56.000 [warn] Your server (173.255.119.202:443) has >>>>>>> not >>>>>>> > managed to confirm that its ORPort is reachable. Please check your >>>>>>> > firewalls, ports, address, /etc/hosts file, etc. >>>>>>> >>>>>>> Well, that's because it's unreachable. (I just tried.) >>>>>>> >>>>>>> Can you try following the suggestion in the log message? >>>>>>> >>>>>>> --Roger >>>>>>> >>>>>>> -- >>>>>>> tor-talk mailing list - [email protected] >>>>>>> To unsusbscribe or change other settings go to >>>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>>>>> >>>>>> >>>>>> >>>>> >> > -- tor-talk mailing list - [email protected] To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
