I am reaching out to discuss one of the main challenges I am currently facing while setting up Nym nodes which is the lack of access to a static IP address
The region where I operate has reliable high speed internet and low electricity costs making it suitable for running multiple nodes efficiently However the local internet provider does not offer static IPs to individual users The only way to obtain one is through registering a company which involves a lengthy and complicated legal process
I have reviewed the Nym documentation and community discussions and found one post from a person who mentioned the same issue about running nodes with dynamic IPs Unfortunately that post received no responses or suggested solutions
To move forward I am exploring potential alternatives that could allow nodes to remain connected even if the public IP changes Some of the approaches I am considering include
1 Dynamic DNS DDNS using a dynamic domain that automatically updates when the IP address changes
2 Zero Trust Network linking local devices securely through an internal network while using a VPS with a static IP as a stable external gateway Although this method could temporarily solve the issue I do not consider it an ideal option because it affects the decentralization aspect of node operation
3 Overlay Networking or Peer Discovery employing a self managed overlay layer that enables nodes to reconnect automatically when IP changes occur
My main questions to the community are
Has anyone successfully implemented a reliable setup for running Nym nodes without a static IP
Are there official guidelines scripts or community tested configurations to automate reconnection when the IP changes
Would using a single VPS as a stable routing endpoint for multiple local nodes be acceptable in terms of performance reliability and reward distribution
Any feedback experiences or technical suggestions from operators who have faced similar conditions would be greatly appreciated
Thank you to everyone willing to share insights or potential solutions to this persistent issue
I faced the same issue and that’s the main reason I decided to wait until a proper solution is found I haven’t tried running nodes with dynamic IPs myself but another operator told me that when the IP address changes rewards may be lost and the collateral might be deducted from the wallet as the node is treated as if it has been disconnected from the network
Hey there.
It’s a good idea to move this to the forum. Currently nodes are run in a fashion where 1 node is on 1 machine (VM on a server or VPS), binded to 1 IPv4 and 1 IPv6 to which A and AAAA records are redirected for a hostname.
Those IPs require to be static ones as they are also recorded in nodes config.toml file.
I am going to discuss your options with the team today and come back to you.
I really hope a solution can be found for this issue I previously started a discussion focusing on this specific point but unfortunately there has not been much progress so far
Coming back to this topic. On Nym side the overall rule is that it’s not on the roadmap of development to make a nym-node working without a static IP by default.
1 node:
- 1IPv4 static
- 1IPv6 static
- 1 Nyx account
- 1 ID number
- 1 server/VM
Static IP Logic
Mixnet: A static IP of a Mixnode is encoded in a sphinx header packet. The topology of the Mixnet need to count on the values which were announced to the clients in the time of generating the topology. If IP would change then sphinx packets would be dropping resulting in network poor performance.
Wireguard: A static IP is used for the inbound connection.
Alternative Solutions
Operators can always experiment and find work arounds. Technical solutions like Cloudflare Tunnel, Load balancer or ngrok as well as different reverse proxy solutions can be a way to go.
The problem is with increasing complexity, maintenance and especially cost for the operator.
I’ll try using an alternative to the suggested method by employing a technique similar to ngrok, but with options that allow direct connections between nodes through a mesh network, bypassing the need to route traffic through the central server managing the network.
In this setup, the VPS service will act as the external gateway used for communication between external nodes, while the nodes located behind the VPS will connect to each other using a Zero Trust service responsible for linking the nodes and assigning them static internal IP addresses.
All nodes will be configured to route their external traffic through the VPS, ensuring secure and stable communication across the entire network. This approach should be more practical. I’ll test the method, and if it works successfully, I’ll share it with you.
