Hi ares,
[email protected]:
> After a snapshot update on the 26th for amd64 I have lost the ability to
> connect to hidden services. I have pf rules to transparently proxy all
> connections taken from the wiki @ https://trac.torproject.org/projects/
> tor/wiki/doc/TransparentProxy#BSDPF. With the exception of using
> divert-to rules istead of the rdr-to rules everything else is exactly
> the same. It all worked fine up to the recent update. After a few days
> and a few snapshot versions I can't seem to troubleshoot what's changed
> or where it's failing. No errors or blocks in syslog or pflog repectively.
> Clearnet works fine and is all routed through tor and using tor-resolve
> on hidden services resolves the address just fine but trying to connect
> through irc or web browser to hidden services fails after timeout. Any
> help would be greatly appreciated. Attached a ktrace of lynx trying to
> connect to the duckduckgo hidden service. Thanks in advance guys!
> P.S. Triple checked pf rules and entire tor config, system time, and
> virtual address allocation
I've encountered recently that system time jumps repeatedly thus
breaking all curcuits and even more time-sensitive Onion Services as
well. This is a problem that I'm now investigating.
As you said, you're using snapshot version. But this problem also
present in 5.9 release branch and started around the same time. Then it
should not have roots in the recent code.
At the moment the problem narrows down to `ntpd.conf` in the default
install. According to this [1] commit, `ntpd` is enabled by default and
uses contraints over TLS from `www.google.com` (do we trust Google
now??). Same NTP peers work fine on another non-OpenBSD machines so my
best guess at the moment that time taken from `www.google.com` is wrong
(or the fetching method). Maybe Google changed their time logic.
Another hint is that these OpenBSD machines do DNS over Tor ('DNSPort'
option) and thus get different Google IP each time (Google tries to
resolve IP addresses that are nearby). Then ntpd takes average of these
clocks (different IPs) according to the manpage.
As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
[3] to fetch time over TLS. It works fine for me for several days by now.
[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/ntpd.conf.diff?r1=1.12&r2=1.13
[2] /etc/rc.d/ntpd stop
rcctl disable ntpd
[3] https://github.com/ioerror/tlsdate
--
Ivan Markin
