Jami-daemon on LAN still leaks its public IP

Security and Privacy
1

How does a fresh install of jami-daemon running on a LAN with an account configured with bootstrap node on the LAN, name server on LAN, STUN and TURN on LAN, even NTP on LAN, is still logging the public IP of the LAN gateway as his “Store DHT public IPv4 address”?

I was expecting not a single packet leaving the LAN…

2

I’m by far not an expert on this, but currently also investigating how things play together to also build a private infrastructure.

Three questions coming into mind:

Did you omit specifying a bootstrap-node for the local dht node running as bootstrap node (opendht parameter -b)?

Did you specify a custom network id for the local dht node running as bootstrap node (opendht parameter -n)?

Did you set you local bootstrap node to be the proxy for the jami-dameon you just installed?

Otherwise from what I understand your bootstrap node will share connected clients with the public network and your new jami-daemon will register with the public network when not using a proxy.

3 
 
jami-daemon-1 ---LAN1--- DHT-node-1 ---LAN2--- DHT-node-2 ---LAN3--- jami-daemon-2
      |  
      |
      |
   gateway
      |   
      |
      |
   internet

DHT nodes cannot talk to the internet. Logs only display private addresses.

No TURN, no proxy, no RingNS (localhost), bootstrap on LAN1;
the account on the jami-clients are created with an explicit d-bus call to addAccount(details) where details are manually set to use only LAN addresses. Communication between clients is very good using only private addresses and direct links between peers. But still jami-daemon-1 log the public IP of the gateway as his public IP…

I will block outgoing traffic on the gateway and dump the traffic coming from the client to investigate deeper.

I would like to use another network id but I do not find how to specify that parameter in the account’s details with jami-daemon. If you know how to I’m very interested? (I know for the regular DHT node, not for an account with jami-daemon)

4

That point I just discussed in a long session with AI. According to that it is not possible as the ID 0 (the public DHT) is hard coded into the JAMI client. I would suspect this is the same for the jami-daemon. For the openDHT “dhtnode” it could be specified by parameter “-n” however from what I understand now it would render the DHT not to be usable with JAMI clients if specifying a different ID that 0.

I also discussed how it would be possible to setup a true and complete private/isolated DHT network with Jami clients. The conclusion was that it is not entirely possible by configuration, as DHT is a distributed network. You can try to come near to it by using isolated bootstrap + proxy and block their traffic to the internet and also omit the bootstrap server setting for your local bootstrap node, however clients are able to learn other DHT nodes by different ways. To archive true isolation it would also be necessary to block nearly all UDP traffic from all clients to the internet which is not desirable in many setups.

To your question why your local DHT nodes have registered the public IP of your gateway and not the private IP of your clients, I suspect the answer is again, that DHT is a global distributed network, so from this perspective only the public IP of your gateway makes your clients addressable globally. The following is what I found from the Jami docs:

DHT Bootstrap Process: When Jami starts, it connects to a bootstrap node (default is bootstrap.jami.net) to enter the network. Once connected, the node that receives the initial request identifies the incoming public IP address and associates it with the user’s account in the DHT.

5

I tried to browse jami-daemon source code to find where this network id is hadcoded but I’m not fluent in c++ and I do not really know where to look and the code base is huge for a newcomer illiterate in c++