Sending lightning payment between TOR lighning nodes, any specific setup required? I have two c-lightning nodes in different VMs in Qubes OS, both routed through TOR VM.
They both can connect to other public nodes and establish channels with them but when I try sending satoshis between them the sending node gives &quot;Could not find a route&quot; code 205 right away, like it's not even trying.
At the same time in the terminal where lightningd is running I get:
20-07-01T12:46:17.482Z DEBUG gossipd: REPLY WIRE_GOSSIP_GETCHANNELS_REPLY with 0 fds
2020-07-01T12:46:17.484Z DEBUG gossipd: Trying to find a route from (me) to 0xxx_ID_EDITEDOUT_XXX for 40000000msat
2020-07-01T12:46:17.484Z DEBUG gossipd: REPLY WIRE_GOSSIP_GETROUTE_REPLY with 0 fds

Is it possible the problem for that to be related to TOR, considering that I can connect to and open channels with public nodes just fine?
I haven't opened direct channel between the nodes, since I want to play with routing.
But each of those nodes has established channel with some of the most well connected nodes, so route exist for sure.
Is it possible the problem for that to be related to TOR, considering that I can connect to and open channels with public nodes just fine?

No, that's very unlikely. (and contradictory)
Are the channels you created announced ?
Are your two nodes connected to the network ? For a node to find a route it needs to be connected to the peer-to-peer network to trade gossip and build its view of the current state of the network (opened channels and whether they are active).
Without this information there is nothing for it to search routes in.
You can verify that your channels are announced with listpeers (the channels array), or by running listchannels &lt;scid&gt; on your first node (with scid the short channel id of a channel of your second node).
If listchannels returns an empty array you need to connect to some public nodes and wait for your node to sync gossip with the rest of the network.
Finally, as it'll surely be your next concern: be sure to have incoming capacity in at least one of your second node's channel :-).