Hi,
I’m sharing the solution to an issue I encountered with Public Pool on Start9 / StartOS 0.4.0.1, as it may help others running miners and Start9 on separate VLANs.
Setup
-
StartOS: 0.4.0.1
-
Public Pool: 0.2.5:22
-
Miner: NerdAxe++, firmware V1.0.37.2-LTS
-
Router/firewall: Ubiquiti UDM-Pro
-
UniFi Network: 10.5.67
-
UniFi OS: 5.1.26
-
Start9 on one VLAN, for example:
192.168.10.0/24 -
Miners on another VLAN, for example:
192.168.20.0/24
Public Pool exposes:
3333 = Stratum V1 over plain TCP
4333 = Stratum V1 over TLS using the Start9 CA
I already had Bitaxe miners working correctly with:
Start9_IP:4333
TLS enabled
Start9 CA certificate installed on the Bitaxe
However, the NerdAxe++ could not connect to:
stratum+tcp://Start9_IP:3333
Symptoms
The NerdAxe logs showed:
Connecting (TCP) to Start9_IP:3333
Connection reset by peer
errno=104
From a Mac located on the same VLAN as the miners:
nc -vz Start9_IP 3333
returned:
Connection refused
while:
nc -vz Start9_IP 4333
returned:
succeeded
Diagnosis
The Public Pool Stratum server itself was working correctly.
From the Start9 host:
bash -c 'exec 3<>/dev/tcp/10.0.x.x/3333' && echo "OPEN" || echo "FAILED"
returned:
OPEN
Port 3333 on the Start9 LAN address was also reachable from the Start9 host itself.
The key finding came from inspecting the nftables rules:
sudo nft -a list ruleset
The rule generated by StartOS for port 3333 looked similar to:
ip saddr 192.168.10.0/24
ip daddr 192.168.10.x
tcp dport 3333
dnat to 10.0.x.x:3333
So in my setup, the DNAT rule forwarding port 3333 to Public Pool only matched clients whose source IP was on the same subnet as the Start9 server.
My miners were on a different VLAN:
Start9 : 192.168.10.x
Miners : 192.168.20.x
Therefore their traffic did not match that nftables rule.
This explains why port 3333 worked locally on the Start9 network but was refused when accessed from the miners’ VLAN.
Workaround / solution
I did not modify nftables directly on StartOS.
Instead, I created a very targeted Masquerade/SNAT rule on the UDM-Pro:
Source:
NerdAxe IP
Destination:
Start9 IP
Protocol:
TCP
Destination port:
3333
Outgoing interface:
Start9 VLAN
Action:
Masquerade
The purpose is to make StartOS see this specific connection as coming from an address on its own VLAN.
I recommend limiting the rule to the affected miner:
NerdAxe_IP → Start9_IP:3333/TCP
rather than masquerading the entire miners VLAN.
Verification
Before the Masquerade rule:
nc -vz Start9_IP 3333
returned:
Connection refused
After enabling the Masquerade rule:
Connection to Start9_IP port 3333 succeeded!
The NerdAxe then connected immediately to the local Public Pool.
Its logs now show successful share submissions:
"method": "mining.submit"
followed by:
{"error":null,"result":true}
message result accepted
The miner is now running normally at around 4.8 TH/s.
Conclusion
In my case, the issue was not caused by:
-
the NerdAxe++;
-
its firmware;
-
Public Pool itself;
-
Stratum V1;
-
or general inter-VLAN routing.
The issue was that the nftables DNAT rule generated by StartOS for TCP port 3333 was restricted to source addresses on the Start9 local subnet.
A targeted Masquerade/SNAT rule on the router between the miners VLAN and the Start9 VLAN solved the issue without modifying StartOS itself.