Problems when Tor is enabled in 386.13_2

[StR]

In 386.13_2, I have an issue with the Tor connection enabled on the router for a single Mac address. That makes the entire network unusable.
I had used this with the previous versions of Asuswrt-Merlin on this RT-AC86U without a problem.

Here is what happens with 386.13_2:
1. After I enable that Tor routing, the computer in question does have the internet connectivity.
2. Other computers that were already connected to the network (via Wi-Fi) may or may not have connectivity to the WAN (not sure if the connectivity survives for a little while), but will eventually loose it.
3. Devices that were disconnected (e.g. laptop after sleep, etc.) cannot connect via WiFi.
4. Even from that computer that was still connected via Tor, it is impossible to connect to the router's WebUI.

After the restart of the router (using the power button), the devices can connect to the local network, but don't have connectivity outside.
I can connect to the router's WebUI. When I go to the "Tor" tab, I see that the entire LAN is set to be routed through Tor. When I disable Tor, everything becomes normal.

This problem makes the selective Tor-routing option completely unusable.

What is different from the previous versions of the firmware is that before, after the router was powercycled, the Tor connection options (Mac address of the specific computer) were completely lost. (I remember there was a thread some 2-3 years ago with Merlin explaining that it was not preserved.) So, I suspect something has been reworked in the code to change that., but evidently, there is an error.

Does anybody else see this issue?
@RMerlin any thoughts/recommendations?

 

[eibgrad]

Let me preface by saying I don't use Tor. And I'm running 386.14, NOT 386.13_2. So keep that in mind.

I did a quick check of Tor, enabling a fictitious MAC address. And at least visually, I don't see anything out of the ordinary in terms of what the router did wrt the necessary configuration changes. It all looks as expected.

Specifically, the Tor ports have been established.

admin@lab-merlin1:/tmp/home/root# netstat -tupln | grep Tor
tcp        0      0 192.168.1.1:9040        0.0.0.0:*               LISTEN      8830/Tor
tcp        0      0 127.0.0.1:9050          0.0.0.0:*               LISTEN      8830/Tor
udp        0      0 192.168.1.1:9053        0.0.0.0:*                           8830/Tor

And the PREROUTING chain of the nat table has the necessary rules to route the MAC address through the Tor ports.

admin@lab-merlin1:/tmp/home/root# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 20 packets, 4010 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
    0     0 REDIRECT   tcp  --  br0    *       0.0.0.0/0           !192.168.1.0/24       tcpflags: 0x17/0x02 MAC 02:03:04:05:06:07 redir ports 9040
    0     0 REDIRECT   udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:123 MAC 02:03:04:05:06:07 redir ports 123
    0     0 REDIRECT   udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 MAC 02:03:04:05:06:07 redir ports 9053
   70  4200 GAME_VSERVER  all  --  *      *       0.0.0.0/0            192.168.63.102      
   70  4200 VSERVER    all  --  *      *       0.0.0.0/0            192.168.63.102

And the FORWARD chain (as a precaution) is denying routing to the internet for the same MAC address via the WAN.

admin@lab-merlin1:/tmp/home/root# iptables -vnL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
...
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC 02:03:04:05:06:07
…

And there's nothing in the OUTPUT chain to suggest the redirect is getting blocked as it leaves the router.

admin@lab-merlin1:/tmp/home/root# iptables -vnL OUTPUT
Chain OUTPUT (policy ACCEPT 18325 packets, 8123K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 OUTPUT_DNS  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0"
    0     0 OUTPUT_DNS  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0"
18366 8128K OUTPUT_IP  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
admin@lab-merlin1:/tmp/home/root# iptables -vnL OUTPUT_IP
Chain OUTPUT_IP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            193.201.224.0/24    
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            51.15.120.245       
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            45.33.73.134        
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            190.115.18.28       
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            51.159.52.250       
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            190.115.18.86

And when I reboot the router, the Tor configuration remains unchanged. I don't see anything that would suggest wireless clients would be denied connectivity, or the GUI would be inaccessible (the REDIRECT makes an exception for the local IP network, 192.168.1.0/24 in my case).

Again, at least visually, this is pretty much what I would have expected. For the given MAC address, that traffic, as long as it's NOT bound for the LAN, is directed through the Tor network for tcp and dns.

So my first instinct would be to recommend upgrading to 386.14 (which may end up being the last supported upgrade w/ Asuswrt-Merlin anyway).

If problems persist, then perhaps there's some other conflict that's not obvious. It might be prudent to dump your router's internals and see if we can spot the culprit(s).

ifconfig
brctl show
ip route
ip rule
iptables -t mangle -vnL
iptables -t nat -vnL
iptables -vnL
netstat -tupln

Feel free to hide your public IP, but just do so in a consistent and obvious manner.

 

[StR]

Thank you for your response.
Here is what I observe:
1. When I just enable Tor for a single Mac address, everything works as expected for some time: it an be short (30-60 min?), it can be long (several hours). After that variable period of time, some "switch" happens, and I cannot connect to the router at all, neither from that specific computer, nor from any other. SSH to the computer doesn't work (at least through WiFi; for technical reasons I have not tried yet to bring a computer to the router and connect via ethernet, to see if that is alive). The devices that were connected to the WiFi shows being connected (but no packets go through); devices that were sleeping when that "switch" happened cannot connect to WiFi.

At that point I power-cycle the router.
2. When the router boots up and establishes all the connections, everything shows in the state as if I enabled the Tor for entire LAN, including how it shows in GUI:

All the routing tables etc. (the outputs that you suggested) look consistent with this setting.
(I am not posting as it is rather tedious to copy-paste all that and do the obfuscation, and it doesn't look incorrect anyway.)

So, I see 2 problems here:
1. That mysterious "switch" - which is intermittent (One of the previous days, it didn't happen at all -- for at about 12 hours, while I had "Tor" enabled.) and hence hard to debug.
2. The fact that the Tor configuration changes after power-cycling from a single Mac (list of Macs) to the entire network.
I believe this happens because the router looses the Mac addresses, but the setting to "enable" Tor carries over the power-cycling.
I am not 100% sure if it was doing the same with the previous versions, as I just have never encountered the need to power-cycle the router while it had Tor enabled.
(It was loosing the list of Mac addresses, as it does now. - as was discussed in one of the threads.)


This is still with 386.13_2 - as at first, for the first couple days after your posting, this issues was not happening, and I wanted to see what I can see in the routing tables when the "switch happens".