In addition, I’m having trouble reaching ports. My miners can’t connect to port 23334 for Datum (local), and the public pool on port 3333 has the same issue.
Also, my iOS widget for block height is no longer able to connect to port 8333 (I assume I need to use 54857 here?).
I’m not sure where else to look. The network firewall shouldn’t be the problem, since the rules were already in place and the IP of the Start9 hasn’t changed.
There is no Jam on v040, nor is the a Public Pool service – at least not yet. Considering they don’t work, it’s little wonder nothing is listening on ports.
Datum has been migrated to v040 and has been tested.
What is accessible on what ports is available under Service Interfaces of that service.
I took another look at everything today, and I just can’t get it to work.
How exactly is the network structure set up in the OS? I have a feeling that my home network might somehow be interfering. I also saw IP address ranges like 10.0.3.0 somewhere.
All my networks at home are in the 10.0.0.0/16 range. Could that cause problems?
I just ran some additional tests and also found a workaround.
To recap my setup:
Start9 is running at IP 10.0.0.21 in VLAN 1.
The miners are in the 10.0.109.0/24 network in VLAN 109.
If I put the miners in the same network, DATUM and the public pool work without any issues. As soon as they’re in different VLANs, the miners don’t connect and show “DEAD POOL”.
For clarity:
This exact same setup worked before with version 0.3.5.1. Back then, I only had a service running on Start9 that exposed the required port.
As a workaround, I’ve now set up a “forwarder” in the same network as Start9, which the miners connect to.
Still, I’d like to understand where the issue actually is. Does the new network design of Start9 not handle different subnets properly? The routing is handled by my firewall, just like before.
Regarding the Bitcoin widget on the iPhone, I’m seeing similar behavior.
In the widget, I can freely choose the port, but port 54857 didn’t work.
Here as well, I’m using the forwarder listening on port 8333 and forwarding to port 54857 on Start9.
Is there something that needs to be adjusted in the network design, or is this simply not changeable and I have to stick with the forwarder?
Also, would you like me to open an issue so someone can take a closer look at this behavior?
I’ve run into this exact same issue. Was pulling my hair out trying to figure out the problem on my network, but it appears to be on the StartOS side and my VLAN setup between miners and pools.
Okay, that’s at least a good sign that the issue can be reproduced.
We might not be running a standard setup either, but I think it needs to be fixed/improved on their end.
I also wasn’t able to reach the Datum Gateway through the WireGuard interface of Start9.
Here as well, I used a WireGuard forwarder that then communicates with my VPS.
Yeah the easiest thing I’m probably going to do for now is to just relocate the miners onto the same VLAN, but not an optimal long-term solution and agree there might be some issues happening in the background blocking this traffic.
From what I can tell, connecting remotely via Wireguard I’m unable to access anything now on StartOS in 0.4. Assuming it’s all related given the isolated VLAN that the server is on, but was never an issue before.
Watching the firewall, I can see the traffic flowing freely to and from the server, but not sure what’s happening once it hits the server as I can’t see anything in any of the logs indicating a conflict.
My firewall also has a WireGuard server. When I’m on the go, I can access my Start9 that way.
I only use the internal WireGuard to expose Core Lightning (CLN) on port 9735 via a VPS (like Tunnelsats). That’s the only thing that works out of the box.
(The VPS forwards directly to the Start9 port via WireGuard.)
Datum Gateway doesn’t work through this method, as mentioned.
Direct access via VPN works for me through the firewall WireGuard.
Overall, my current setup feels more “hacky” than it did with manually exposing ports per service in version 0.3.5.1.
Don’t get me wrong — the fact that all of this is possible with the different gateways is great. It just needs to work reliably in every environment.
Am I correct in understanding that the request is…
”I want all my devices on different VLANs to be able to talk to each other”. Because the opposite of that is super important for some of the various other more general use cases that have also been considered.
Essentially, I’m wondering if this should be an issue posted on GitHub rather than a support request on the forum.