• transparent proxy for .onion connections

    From Oli@21:1/151 to All on Wed Nov 20 11:35:54 2019
    I found this basic recipe for Linux:
    https://gist.github.com/DrWhax/7871636

    I believe it's possible to do the same with opnsense.


    How does it work?

    - binkp client asks your own local nameserver (:53) to resolve the .onion address
    - nameserver forwards the request to your local Tor daemon (:9053)
    - client gets a locally mapped IP address (like 127.192.24.32)
    - client opens a connection to that IP
    - firewall redirects the connection to the Tor daemon (:9040)
    - Tor daemon establishes a connection to the remote binkp server (hidden service)



    If you use BinkD there is a much simpler solution:
    - BinkD client uses the Tor socks5 proxy for .onion addresses (:9050)
    - Tor daemon establishes a connection to the remote binkp server (hidden service)


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: ِŸŒˆ (21:1/151)
  • From alterego@21:3/100 to Oli on Wed Nov 20 23:26:44 2019
    Re: transparent proxy for .onion connections
    By: Oli to All on Wed Nov 20 2019 11:35 am

    I found this basic recipe for Linux: https://gist.github.com/DrWhax/7871636
    I believe it's possible to do the same with opnsense.

    I'm stuck at the resolving stage :(

    I have configured torcc and unbound as described, however, any resolution of a .onion address yields NXDOMAIN :(

    a tcpdump doesnt show any query going to tor on port 9053.

    Any ideas?

    ...deon
    --- SBBSecho 3.10-Win32
    * Origin: ANSITEX-DEV: Testing InterBBS Videotex! (21:3/100)
  • From Oli@21:1/151 to alterego on Wed Nov 20 13:55:07 2019
    I found this basic recipe for Linux:
    https://gist.github.com/DrWhax/7871636
    I believe it's possible to do the same with opnsense.

    I'm stuck at the resolving stage :(

    I have configured torcc and unbound as described, however, any
    resolution of a .onion address yields NXDOMAIN :(

    a tcpdump doesnt show any query going to tor on port 9053.

    Any ideas?

    Not really, I never used unbound or the Tor nameserver.

    Do you get the same error with dig?

    dig unnp7cod2ek7teu4.onion @127.0.0.1
    ^^^^^^^^^

    (I guess you have to use the IP address of the unbound machine instead of 127.0.0.1)


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: ِŸŒˆ (21:1/151)
  • From alterego@21:3/100 to Oli on Thu Nov 21 07:26:59 2019
    Re: transparent proxy for .onion connections
    By: Oli to alterego on Wed Nov 20 2019 01:55 pm

    Not really, I never used unbound or the Tor nameserver.
    Do you get the same error with dig?
    (I guess you have to use the IP address of the unbound machine instead of 127.0.0.1)

    I did - no answers.

    DIG shows me the soa, but it returns NS records of "localhost", when I think it
    should have them as the router.

    If I do this on the router, it still doesnt work.

    Its like unbound is not forwarding the requests ...
    --- SBBSecho 3.10-Win32
    * Origin: ANSITEX-DEV: Testing InterBBS Videotex! (21:3/100)
  • From Oli@21:1/151 to alterego on Thu Nov 21 11:34:20 2019
    21 Nov 19 07:26, you wrote to me:

    Do you get the same error with dig?
    (I guess you have to use the IP address of the unbound machine
    instead of 127.0.0.1)

    I did - no answers.

    DIG shows me the soa, but it returns NS records of "localhost", when I think it should have them as the router.

    If I do this on the router, it still doesnt work.

    Its like unbound is not forwarding the requests ...

    I have to test it for myself and see if I'm running into the same problems. Often I cannot reach your Taurus mailer over Tor. Could it be releated the unbound forwarding problem? Or is it just an configuration issue in unbound? You could also try dnsmasq.

    I have to admit this is not the simplest approach to binkp over Tor.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: ِŸŒˆ (21:1/151)
  • From Alterego@21:2/116 to Oli on Thu Nov 21 21:57:02 2019
    Re: transparent proxy for .onion connections
    By: Oli to alterego on Thu Nov 21 2019 11:34 am

    problems. Often I cannot reach your Taurus mailer over Tor. Could it be releated the unbound forwarding problem? Or is it just an configuration issue in unbound? You could also try dnsmasq.

    Not sure why you cannot connect - the tor status page (from opnsense) does look
    unusual. When it first starts, it shows lots of circuits - but I just checked again now and it only shows one. One of the circuites shows lots of nulls.

    I dont think it's related to unbound, since I have IP addresses forwarding to binkd.

    Are there commands to check its status?
    ...ًَمك

    ... When I die, I'm leaving my body to science fiction.
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Oli@21:1/151 to Alterego on Thu Nov 21 12:48:45 2019
    problems. Often I cannot reach your Taurus mailer over Tor. Could
    it be releated the unbound forwarding problem? Or is it just an
    configuration issue in unbound? You could also try dnsmasq.

    Not sure why you cannot connect - the tor status page (from opnsense)
    does look unusual. When it first starts, it shows lots of circuits -
    but I just checked again now and it only shows one. One of the
    circuites shows lots of nulls.

    I just enabled the ControlPort (9051) and installed nyx to see how it looks on my system. I see 63 circuits in nyx (I didn't expect so many connections). On my other machine that does not any onion service, I see 5 to 8 circuits. I don't see any circuit with a lots of nulls.

    I dont think it's related to unbound, since I have IP addresses
    forwarding to binkd.

    Are there commands to check its status?

    Tor's status? I don't know a specific command. To check connectivity I use ncat:

    ncat --proxy=127.0.0.1:9050 --proxy-type=socks5 <myaddress>.onion 24554


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: ِŸŒˆ (21:1/151)
  • From Oli@21:1/151 to Alterego on Thu Nov 21 14:09:42 2019
    problems. Often I cannot reach your Taurus mailer over Tor. Could
    it be releated the unbound forwarding problem? Or is it just an
    configuration issue in unbound? You could also try dnsmasq.

    Not sure why you cannot connect

    Today it works fine. I cannot rule out that the problems were on my side.

    It's just an experiment. If it doesn't work well, we can try other options for transport encryption or go back to unencrypted connections.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: ِŸŒˆ (21:1/151)
  • From Alterego@21:2/116 to Oli on Fri Nov 22 06:51:42 2019
    Re: transparent proxy for .onion connections
    By: Oli to Alterego on Thu Nov 21 2019 02:09 pm

    It's just an experiment. If it doesn't work well, we can try other options for transport encryption or go back to unencrypted connections.

    Give ZT a try. I set it up months ago, and use it on another network with hubs,
    and it just works. I dont even check it anymore.

    For a focused use case such as this (transfering mail between specific endpoints), it does the job nicely.
    ...ًَمك

    ... I like long walks, especially when they are taken by people who annoy me. --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Alterego@21:2/116 to Oli on Fri Nov 22 07:05:47 2019
    Re: transparent proxy for .onion connections
    By: Oli to Alterego on Thu Nov 21 2019 12:48 pm

    Tor's status? I don't know a specific command. To check connectivity I use ncat:

    Ahh, this worked...

    The bsd version is:
    nc -x 127.0.0.1:9050 -X 5 <address>.onion 24554

    That'll help at least to confirm if my tor is working...

    I'll check it every now and again.
    ...ًَمك

    ... Hey! Who took the cork off my lunch??!
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Oli@21:1/151 to Alterego on Fri Nov 22 09:38:11 2019
    "Alterego -> Oli" <0@116.2.21> wrote:

    Tor's status? I don't know a specific command. To check
    connectivity I use ncat:

    Ahh, this worked...

    The bsd version is:
    nc -x 127.0.0.1:9050 -X 5 <address>.onion 24554

    The BSD version runs also on Linux (like the many other OpenBSD programs). In Debian there are 2 different netcat packages: netcat-traditional and netcat-openbsd. netcat-traditional, which is installed by the netcat package, does not support socks.

    I'm used to ncat, because it also supports TLS.

    ---
    * Origin: (21:1/151)
  • From Vk3jed@21:1/109 to Alterego on Fri Nov 22 20:35:00 2019
    On 11-22-19 06:51, Alterego wrote to Oli <=-

    Give ZT a try. I set it up months ago, and use it on another network
    with hubs,
    and it just works. I dont even check it anymore.

    I'm also a fan of ZT. I use it on the other network mentioned, as well as a separate virtual LAN for my own use.

    For a focused use case such as this (transfering mail between specific endpoints), it does the job nicely.

    Sure does.


    ... I strive for perfection, what I get is reality.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Oli@21:1/151 to Alterego on Fri Nov 22 11:02:39 2019
    "Alterego -> Oli" <0@116.2.21> wrote:

    It's just an experiment. If it doesn't work well, we can try
    other options for transport encryption or go back to
    unencrypted connections.

    Give ZT a try. I set it up months ago, and use it on another network
    with hubs, and it just works. I dont even check it anymore.

    I'm running zerotier on my Pi, my PC and on a VPS for a while. I haven't used it very much, but it seems to work okay. It eats a little bit too much CPU time
    for doing nothing and doesn't exit properly on shutdown. There is also no package for Alpine Linux which I run on another VPS. I'm thinking about switching to tinc or wireguard.

    For a focused use case such as this (transfering mail between specific endpoints), it does the job nicely.

    I agree, but I'm more interested in solutions that enables all nodes and points
    to use encryption. With you zerotier you would have to setup many small VPNs or create a global VPN for the FTN which would be another centralized administrative structure.

    I don't think there is anything wrong with using VPNs for FTNs, but it's not the solution to the encryption, authentication or connectivity (no public IP) problem. With solution I mean something that can be standardized by the FTSC and included in every mailer (e.g. TLS, which is one of the low-hanging fruits).

    ---
    * Origin: (21:1/151)
  • From Alterego@21:2/116 to Oli on Fri Nov 22 22:13:44 2019
    Re: transparent proxy for .onion connections
    By: Oli to Alterego on Fri Nov 22 2019 11:02 am

    I agree, but I'm more interested in solutions that enables all nodes and points
    to use encryption. With you zerotier you would have to setup many small VPNs or create a global VPN for the FTN which would be another centralized administrative structure.

    Actually it wouldnt - but yes, the implmentation I have setup does.

    The reason I did it this way, is it enables each "FTN network" to admininister who can join and exchange mail on the network. Just like you need to apply for a node number, as part of that application, you setup and join the respective FTN ZT network and provide your ZT id. The ZC can then accept or reject your application and in doing so either authorises you on the network and provides a
    node number, or advises you of your rejection.

    In the same topic, if you are ejected from the network, then the ZC can turn you off, which I imagine a few wont like, but I think it could be a useful control point.

    In this sense it probably doesnt scale well - if your intention is to join multiple FTN networks. (But in the same context, I'd like to see the day that you can interact with any FTN zone from any FTN zone - then it wouldnt be an issue.)

    But it doesnt need to be that way - ZT supports "public networks", which you can join and automatically be assigned an address and connect with something on
    the network.

    As an example, if you join ff5fea5fea000000 that will enable two systems to communicate over TCP port 24554 (and only that port).
    ...ًَمك

    ... Scratch a lover and find a foe.
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Oli@21:1/151 to Alterego on Sun Nov 24 18:28:34 2019
    "Alterego -> Oli" <0@116.2.21> wrote:

    I agree, but I'm more interested in solutions that enables all
    nodes and points
    to use encryption. With you zerotier you would have to setup
    many small VPNs or create a global VPN for the FTN which would
    be another centralized administrative structure.

    In the same topic, if you are ejected from the network, then the ZC
    can turn you off, which I imagine a few wont like, but I think it
    could be a useful control point.

    useful or abuseful ...

    In this sense it probably doesnt scale well - if your intention is to
    join multiple FTN networks. (But in the same context, I'd like to see
    the day that you can interact with any FTN zone from any FTN zone -
    then it wouldnt be an issue.)

    We have mailers that are fully 5D and a message base format that can store 5D addresses, but no tossers and no standard pkt and message format that supports it.

    But it doesnt need to be that way - ZT supports "public networks",
    which you can join and automatically be assigned an address and
    connect with something on the network.

    As an example, if you join ff5fea5fea000000 that will enable two
    systems to communicate over TCP port 24554 (and only that port).

    So it's a public overlay network, but is there a way to put the node's zeronet address in the nodelist? Like a .onion or .i2p address? I found this project which uses ztaddr and nwid directly to connect to nodes:

    https://nanomsg.github.io/nng/man/tip/nng_zerotier.7#_uri_format

    ---
    * Origin: (21:1/151)
  • From Alterego@21:2/116 to Oli on Mon Nov 25 11:18:19 2019
    Re: transparent proxy for .onion connections
    By: Oli to Alterego on Sun Nov 24 2019 06:28 pm

    useful or abuseful ...

    Well, I think useful - and I'm taking the glass half full approach.

    If the "operator" was abuseful, would you still want to be part of the network?

    I dont think it is any different to somebody twitlisting you out, or even more,
    firewalling you out.

    This is not a public service, its a hobby with hobbiests. If the main hunchperson has morals that you dont agree with, then I'd figure you wouldnt want to be part of the group anyway...

    Anyway, the glass half full approach, to me it means it becomes a network of known (trusted?) individuals (you apply, your application is accepted, you are authorised to connect to the network), and by definition "strangers" are out. (Strangers being script kiddies who take fun out of denial of sevices and other
    activities to bring down a service.)

    So it's a public overlay network, but is there a way to put the node's zeronet address in the nodelist? Like a .onion or .i2p address? I found

    It becomes a regular resolvable IP address - except the network "would" (should) be made up of non routable addresses - it would just need a resolver (ideally in the network, but doesnt have to be), that resolves endpoints.

    In TQWnet, Meatlotion has a sub domain zt.erb.pw - where all the ZT nodes are in the zt.erb.pw domain. The nodelist then has their fully qualified zt.erb.pw hostname - and we are using IPv6 addresses (fd00:..).

    this project which uses ztaddr and nwid directly to connect to nodes: https://nanomsg.github.io/nng/man/tip/nng_zerotier.7#_uri_format

    Now this looks interesting - it looks like coms outside of the IP stack. I wouldnt mind having a play with this - but it'll be a while before I can think about looking at this - and I'd have some learning to do.
    ...ًَمك

    ... Die, my dear doctor? That's the last thing I shall do.
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Vk3jed@21:1/109 to Oli on Wed Nov 27 11:52:00 2019
    On 11-24-19 18:28, Oli wrote to Alterego <=-

    So it's a public overlay network, but is there a way to put the node's zeronet address in the nodelist? Like a .onion or .i2p address? I found this project which uses ztaddr and nwid directly to connect to nodes:

    Yes, either its (private) IP address or DNS hostname will work. I have hostnames like freeway.zt.vkradio.com that are only reachable via ZeroTier. :)


    ... It compiled? The first screen came up? Ship it! -- Bill Gates
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Oli@21:1/151 to Alterego on Wed Nov 27 12:34:37 2019
    On Mon, 25 Nov 2019 11:18:19 +1100
    "Alterego -> Oli" <0@116.2.21> wrote:

    useful or abuseful ...

    Well, I think useful - and I'm taking the glass half full approach.

    If the "operator" was abuseful, would you still want to be part of
    the network?

    I'm always thinking 90s Fidonet scale, ten thousands of nodes/points. And yes, people wanted to be part of it even if there were a lot of coordinators that were abusing their power.

    I dont think it is any different to somebody twitlisting you out, or
    even more, firewalling you out.

    Somebody blocking me is different than getting kicked out of the VPN.

    This is not a public service, its a hobby with hobbiests. If the main hunchperson has morals that you dont agree with, then I'd figure you wouldnt want to be part of the group anyway...

    Again I'm not thinking benevolent dictator style (e.g. fsxnet), but networks that were meant to be decentralized (e.g. Fidonet). I know many disagree, but in my understanding Fidonet is a public network, like the networks around SMTP,
    XMPP, HTTP are not controlled by anyone and the public part of does not depend
    on VPNs for encryption or access.

    Anyway, the glass half full approach, to me it means it becomes a
    network of known (trusted?) individuals (you apply, your application
    is accepted, you are authorised to connect to the network), and by definition "strangers" are out. (Strangers being script kiddies who
    take fun out of denial of sevices and other activities to bring down
    a service.)

    I'm not saying that you never should do that, but it shouldn't be part of Fidonet technology. If you want to participate in a closed network that is fine
    and it has it's advantages, but this model is not a solution for encryption in
    an open FTN.

    this project which uses ztaddr and nwid directly to connect to
    nodes:
    https://nanomsg.github.io/nng/man/tip/nng_zerotier.7#_uri_format

    Now this looks interesting - it looks like coms outside of the IP
    stack. I wouldnt mind having a play with this - but it'll be a while
    before I can think about looking at this - and I'd have some learning
    to do.

    AFAIK it uses some modified libzerotiercore and it's nothing we could use directly. IN theory it looks like it would be possible to use these zerotier addresses directly, but somebody would have to write code for binkp or a socks5
    proxy.

    ---
    * Origin: (21:1/151)