I confirm, it doesn’t seem very open. Could you check with sudo iptables -nvL if ufw committed the requested rule ? ufw is a kind of front-end for Netfilter and iptables the basic low-level tool to interact with Netfilter.
the output of iptable
Then it’s safe to say that the firewall blocking port 6000 is not on this host, as you have absolutely no rule. It’s a problem for later but if you want to harden your conf you could use a DROP policy and explicitely allow only what you need.
Yes but i don’t know where it block.
From my producer , i cannot connect to any relay but from relay i can connect to producer.
Yes i will allow only what i need, i didnt put some rules in order to be sure that everything is ok in my conf before DROP policy.
Keep only the IOHK relays till the nodes will be synced . If the nodes are not synced will not allow connections from another nodes
For the connection any other suggestion? that’s really weird. 
The question is 167.172.35.8 is a host you have control on or not ? Is it just a relay in your conf ? IOHK nodes run the same code as others.
How so ? A node should be able to synchronize to one other without the need for any central entity, no ? That’s the point of decentralization and P2P architecture.
I’m using the IOHK relays in my relay 1 and 2. like that.
` {
"Producers": [
{
"addr": "producers IP",
"port": 6000,
"valency": 1
},
{
"addr": "relays-new.cardano-mainnet.iohk.io",
"port": 3001,
"valency": 2
}
]
}`
great, keep the IOHK nodes also on Producer, till your relays will be 100% synced, otherwise they will refuse the Producer connection and the Producer will can’t sync
Even if IOHK nodes were more “up to date” than others (which I don’t believe since blocks are now produced by stake pools) that still wouldn’t explain why port 25 and 11211 are filtered on this particular host. Moreover the provided producer logs clearly show a connection attempt, failed but attempted nonetheless. You might be right about the synchronization condition but that doesn’t mean it’s the only issue. To know that for sure we would need to check fw rules on both hosts.
@fuldev It appears port 6000/tcp on IP 167.172.35.8 is now officially open.
$ nc -v 167.172.35.8 6000
Connection to 167.172.35.8 6000 port [tcp/x11] succeeded!
x11 being the service name attributed to port 6000/tcp in /etc/services. By the way you now have
PORT STATE SERVICE
25/tcp open smtp
2289/tcp open dict-lookup
6000/tcp open X11
11211/tcp filtered memcache
I would urgently advise you to filter port 25/tcp if you don’t want your host be used for sending spam.
Hi @raph_cardano ,
Yes its filtered now. Could you check again and let discuss inbox please for other action.
And my nodes are also pretty syncing. thanks @Alexd1985
Hi. Sent you a PM. As for the relay nodes in your conf and for further reference, you can use pretty much any node of topology.json file. Not only IOHK nodes don’t have any super-power, but also the more users rely on IOHK nodes only, the weaker the network. Think of it from an attacker point of view. This makes IOHK nodes more likely to be targeted. And load balancers are good for DDoS mitigation but no ultimate solution.