Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:41:01Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30299Switch network interface2020-06-13T15:41:01ZTracSwitch network interfaceI have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set t...I have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set to redirect DNS packets to IP:
127.0.0.1
After following the standard OpenVPN configuration, I make a connection to the VPN server with:
openvpn --config /etc/openvpn/servers-conf/01.example.tcp.ovpn
The problem is Tor receives the DNS UDP packets, converts them to TCP packets and then attempts to send them through my main "naked" network interface to Tor relays, instead of using the secure tun0 interface. OpenVPN sees the TCP packet leaving the "naked" interface and thinks this is not safe and blocks them, which means I'm not able to resolve domain names as Tor's DNS TCP packets can't leave the system.
In order to fix this, I have to restart Tor using:
systemctl restart tor
This then updates Tor to connect to tun0 and everything works fine again however, it would make sense to have Tor update automatically or to have an option to specify a network interface order for Tor to connect to. Example:
InterfacePref: tun0, tun1, eth0
Similar to a bootloader selecting what to boot first, this means Tor would always try to connect to tun0 if available, if not it will try tun1 and else eth0. If at any time a better interface comes up Tor should switch to it automatically. A default value would still connect to the default interface as it does today.
**Trac**:
**Username**: enriquejr99Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28772DNS resolver at DNSPort stops working after some time, while tor is working. ...2020-06-13T15:35:20ZTracDNS resolver at DNSPort stops working after some time, while tor is working. Only restart helps.Hello. I am tor user more than 6 years. And always this problem existed. Now I am totally tired and decided to fill a bug. I am using always latest versions, now at 0.3.5.5 and on android the same, latest 0.3.* version.
I use DNSPort o...Hello. I am tor user more than 6 years. And always this problem existed. Now I am totally tired and decided to fill a bug. I am using always latest versions, now at 0.3.5.5 and on android the same, latest 0.3.* version.
I use DNSPort option and route all my DNS traffic to it. After tor is connected, it is working well, but after some time (2-5-10 hours), it stop to work and return no IP address to any DNS request, while the tor itself continue working, log don't show anything relevant. DNS requests resolve only internally through socks port.
This happens many years to me, and only restarting tor helps to get my DNS back.
I even tried to open multiple DNSresolvers, like
DNSPort 127.0.0.2:53
DNSPort 127.0.0.3:53
DNSPort 127.0.0.4:53
and put them all to /etc/resolv.conf, and it helped to keep it running more long, but anyway after some time they all stops resolving.
On android I have the same issue. I rerouted all DNS traffic to it, and after some hours only restarting to service works. I even thought to write some script, if domain fails to resolve, restart to service...
Please help! DNSPort resolver must recreate it's circuits if they fails. and don't wait for hard reset.
Thank you!
**Trac**:
**Username**: toruser787Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18710dnsserv.c asserts when no supported questions are requested2020-06-13T14:55:59ZTracdnsserv.c asserts when no supported questions are requestedThe patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questio...The patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questions[i];" to the for loop ensures that "q" is always set to the first question, even if it's unsupported. In which case, the "if (!q)" check for NOTIMPL is dead code. Ultimately, you will eventually hit the "tor_assert" that was added to the "else" branch. Additionally, the "switch" block switches on "req->questions[i]->type", but the assignment to "supported_q" is "q" (which is always the first question) instead of "req->questions[i]", so it doesn't actually pick the first supported question -- it always picks the first question.
**Trac**:
**Username**: geekmugTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/12509Setting an option clears addressmappings, automapped addresses2020-06-13T14:37:11ZTracSetting an option clears addressmappings, automapped addressesstarting tor with:
tor --DNSPort 9053 --Log "notice syslog" --CookieAuthentication 1
then running:
echo -e 'Authenticate '$(cat /var/tor/control_auth_cookie | xxd -p | tr -d '\n')'\n''SetConf Log="notice syslog"' | ncat 127.0.0.1 ...starting tor with:
tor --DNSPort 9053 --Log "notice syslog" --CookieAuthentication 1
then running:
echo -e 'Authenticate '$(cat /var/tor/control_auth_cookie | xxd -p | tr -d '\n')'\n''SetConf Log="notice syslog"' | ncat 127.0.0.1 9051
clears all addressmappings and makes queries to DNSPort stop responding with automapped addresses.
**Trac**:
**Username**: epochTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/10268tor's dnsserv returns NOTIMPL for queries of type ALL and MX2020-06-13T14:55:59ZTractor's dnsserv returns NOTIMPL for queries of type ALL and MXWhile trying to get qmail working over tor I found that it will work if ALL and MX records don't return NOTIMPL. In the attached patch I have ALL records doing whatever A and AAAA records do and MX just returning NXDOMAIN. (Which should ...While trying to get qmail working over tor I found that it will work if ALL and MX records don't return NOTIMPL. In the attached patch I have ALL records doing whatever A and AAAA records do and MX just returning NXDOMAIN. (Which should be fine since MX records aren't required and MTAs should fall back to A records if they don't exist, right?)
**Trac**:
**Username**: epochTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/2765Wrong source port for dns replies when query is sent to an alias interface2020-06-13T14:09:32ZTracWrong source port for dns replies when query is sent to an alias interfaceI just found a bug with the internal tor dns server. It seems to be present in 0.2.2.22-alpha (on openwrt) as well as on 0.2.1.29 (debian squeeze).
PC A - this is where tor runs with a minimal default config:
SocksPort 9050
SocksList...I just found a bug with the internal tor dns server. It seems to be present in 0.2.2.22-alpha (on openwrt) as well as on 0.2.1.29 (debian squeeze).
PC A - this is where tor runs with a minimal default config:
SocksPort 9050
SocksListenAddress 127.0.0.1
DNSPort 9053
DNSListenAddress 0.0.0.0
There are two ips setup on eth0
eth0:
inet 192.168.0.135/24 brd 192.168.0.255 scope global eth0
inet 192.168.22.1/24 scope global eth0
And port 53 is redirected to 9053:
iptables -t nat -I PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 9053
PC B - The client, has also two IPs assigned.
br0:
inet 192.168.0.30/24 brd 192.168.0.255 scope global br0
inet 192.168.22.2/24 scope global br0
from the client i did nslookups on the PC1 to the two different IPs:
$ nslookup heise.de 192.168.0.135
Server: 192.168.0.135
Address: 192.168.0.135#53
Non-authoritative answer:
Name: heise.de
Address: 193.99.144.80
$ nslookup heise.de 192.168.22.1
;; reply from unexpected source: 192.168.22.1#9053, expected 192.168.22.1#53
So its quite clear, tor sends from the wrong source port when i ask for dns-lookup on the alias ip, which can also be seen in the tcpdump output:
05:16:30.689341 IP 192.168.0.30.51175 > 192.168.0.135.53: 39142+ A? heise.de. (26)
05:16:30.689874 IP 192.168.0.135.53 > 192.168.0.30.51175: 39142 1/0/0 A 193.99.144.80 (42)
05:16:45.430093 IP 192.168.22.2.51321 > 192.168.22.1.53: 16078+ A? heise.de. (26)
05:16:45.430513 IP 192.168.22.1.9053 > 192.168.22.2.51321: UDP, length 42
**Trac**:
**Username**: somaTor: 0.2.2.x-final