masternode shown as inactive on dashninja

[Pietro Speroni]

Hello,
this is my first post on Dash forum. I am a researcher in eDemocracy and online governance. I recently decided it would be a good thing to set up a masternode also to study the governance of it. So after some work I was able to set it up. Or so I thought so.

I set it up on my computer with a non fixed IP, and then I set up a vps on vultr following tao masternode setup guide for dummies (that's me). Apparently the masternode seem to be running well. On my wallet is is shown as active. And so at dash central. But when I went to dash ninja dot pl and I looked for the ip address (108 61 117 186) of my masternode it says that it is closed. What is going on? Who should I believe?

Many thanks.
Pietro

P.S. I have many questions, but this comes first.

 

[UdjinM6]

dash-cli masternode list full 108.61.117.186
{
  "e949520f22dbee95d41a793dcc4360bfa02892620a49ca95dc559bc4fd86c73f-1": "           ENABLED 70206 XmzcHvFgipBLyWi9ccKtss7bert5Q6zeWk 1493071823   441137          0      0 108.61.117.186:9999"
}

Looks ok-ish from my node, but you probably messed up with port setup in some way - you should have port 9999 open on you vps. I just checked and I indeed can't connect to port <yourip>:9999 - make sure you applied/saved correct firewall rules.

 

[Pietro Speroni]

Thanks @UdjinM6
I tried an ufw status after doing a su and this is what I got:

Status: active

To Action From
-- ------ ----
SSH ALLOW Anywhere
224.0.0.251 mDNS ALLOW Anywhere
22/tcp LIMIT Anywhere
9999/tcp ALLOW Anywhere
SSH (v6) ALLOW Anywhere (v6)
ff02::fb mDNS ALLOW Anywhere (v6)
22/tcp (v6) LIMIT Anywhere (v6)
9999/tcp (v6) ALLOW Anywhere (v6)

To my untrained eye it looks correct, but maybe I am absolutely wrong. Do I need to check something else?

 

[UdjinM6]

Hmm.. that's strange. MN is live (ENABLED) and this IP is definitely live too (I can ping it), so it must be smth else.
Let me ping @chaeplin , maybe he has some idea.

 

[chaeplin]

I have tested, port/9999 is not opened.

coind@raspberrypi2:~ $ telnet 108.61.117.186 9999
Trying 108.61.117.186...
telnet: Unable to connect to remote host: No route to host

following command will show exact status of firewall.

sudo iptables -L -v -n

pi@raspberrypi2:~ $ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination     
 5329  557K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0       
1308K 1039M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    6   384 ACCEPT     tcp  --  *      *       x.x.x.x              0.0.0.0/0            state NEW tcp
    0     0 DROP       tcp  -f  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x3F/0x17
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x03/0x03
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x06
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x3F/0x3F
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x3F/0x00
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:0
    4   232 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:9999
  783 32978 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0       

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination     
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 5329 packets, 557K bytes)
 pkts bytes target     prot opt in     out     source               destination     
1027K  146M ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

 

[Pietro Speroni]

Hello @chaeplin , thanks for the answer.

I tried to run the code and this is what I got is in the included file


There seem to be only one line that refers to port 9999:

    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999

Do I have to do something specific? What happens if I just wait, would it not work?

Many Thanks ,
Pietro

 

[chaeplin]

    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999

is in chain rule of ufw-user-input.

ufw-user-input is a sub rule of ufw-before-input.

ufw-before-input is a sub rule of INPUT.
INPUT chain is the following

Chain INPUT (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination

  89M   12G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

29820 1789K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0

89929 5180K INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0

89929 5180K INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0

89929 5180K INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0

 3317  138K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID

47251 2698K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

    0     0 ufw-before-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0

    0     0 ufw-before-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0

    0     0 ufw-after-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0

    0     0 ufw-after-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0

    0     0 ufw-reject-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0

    0     0 ufw-track-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0

ufw-before-input is a rule after the following rule(reject all)

47251 2698K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

So packet to port/9999 is never reached.

pkts and bytes is zero.

 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999

I control iptables using iptables-save and iptables-restore without sub chain.
Following is a sample and recommede to mitigate ddos packet.
https://gist.github.com/chaeplin/5dabcef736f599f3bc64bdce7b62b817

 

[Pietro Speroni]

Thank you very much @chaeplin . I shall now work on it, and report here .
Thanks again,
P

 

[Pietro Speroni]

LATE EDIT:
I figured out finally (see next message). I leave this message here as a feedback of the kind of problems n00b might incur.

Thanks to all

END LATE EDIT;

Ok, I am trying to understand @chaeplin .
Unfortunately it seems you are not using ufw but iptables. Which I gather is a different system (??).
But the instructions I have from @TaoOfSatoshi cover ufw. Unfortunately on those instructions it says to

ufw allow ssh/tcp
ufw limit ssh/tcp ---this command limits SSH connections to 6 every 30 seconds for greater security---
ufw allow 9999/tcp
ufw logging on
ufw enable
ufw status

So I tried to reset all and give those instructions again. Then I tried from this page:
https://askubuntu.com/questions/541675/ufw-is-blocking-all-even-when-i-set-rules-to-allow/541687

to add the deny to close the other doors:

   ufw deny 1:21
   ufw deny 1:21/tcp
   ufw deny 1:21/udp
   ufw deny 23:9998/tcp
   ufw deny 23:9998/udp
   ufw limit ssh
   ufw allow in 9999/tcp
   ufw logging on
   ufw enable
   ufw status
   iptables -L -v -n

But when I run

iptables -L -v -n

I still get the chain INPUT:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
  91M   12G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
30546 1833K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0          
92198 5314K INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0          
92198 5314K INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0          
92198 5314K INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0          
 3417  142K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
48268 2759K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

So apparently the chain INPUT (which I did not know existed until 1 hour ago, have patience please) cannot be controlled from ufw. How can I disable it?

I checked your instructions but they are much too difficult for my level. In particular:

when I run

iptables-restore < /etc/iptables

I get:

bash: /etc/iptables: No such file or directory

While the rc.local inside has:

#!/bin/bash
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.

touch /var/lock/subsys/local

Is there no simple way to delete the INPUT chain and just use the ufw?

Thanks,
Pietro

 

[Pietro Speroni]

Ok, got it:

new iptables of my node:

Chain INPUT (policy ACCEPT 4 packets, 659 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  468  128K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
 102K 9641K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 DROP       tcp  -f  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x3F/0x17
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x03/0x03
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x06
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x3F/0x3F
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x3F/0x00
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:0
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9998
    0     0 DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:9999
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 flags:0x17/0x02 #conn src/24 > 8
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 flags:0x17/0x02 #conn src/32 > 2
   15   884            tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 ctstate NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 ctstate NEW recent: UPDATE seconds: 30 hit_count: 3 name: DEFAULT side: source mask: 255.255.255.255
   78  4640            tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW recent: UPDATE seconds: 30 hit_count: 3 name: DEFAULT side: source mask: 255.255.255.255
   28  1404 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999
  104  5748 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 468 packets, 128K bytes)
 pkts bytes target     prot opt in     out     source               destination         
99196 9590K ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

wow, maybe I might pull request some additional explanations on github for us n00b.

 

[chaeplin]

ufw)
I think this one helps https://www.digitalocean.com/commun...with-ufw-on-an-ubuntu-and-debian-cloud-server


manual config)
copy the following rule tp /etc/iptables
https://gist.githubusercontent.com/...6acbb99948fca39295acd65739a46c3679cf/iptables
edit following line and remove #

#-A INPUT -m state --state NEW -m tcp -p tcp -s white_ip_or_my_ip -j ACCEPT

add the following line to rc.local like

# that this script will be executed during boot.

/sbin/iptables-restore < /etc/iptables

touch /var/lock/subsys/local

 

[Pietro Speroni]

ufw)
I think this one helps https://www.digitalocean.com/commun...with-ufw-on-an-ubuntu-and-debian-cloud-server


manual config)
copy the following rule tp /etc/iptables
https://gist.githubusercontent.com/...6acbb99948fca39295acd65739a46c3679cf/iptables
edit following line and remove #

#-A INPUT -m state --state NEW -m tcp -p tcp -s white_ip_or_my_ip -j ACCEPT

Thanks @chaeplin , if I had a fixed IP I would not be doing all this in the first place ;-).


second edit:
Ooops, did I locked myself out of my own server?

Third Edit:
no, apparently not

add the following line to rc.local like

# that this script will be executed during boot.

/sbin/iptables-restore < /etc/iptables

touch /var/lock/subsys/local

Yes, I did it. It all changed when I realised the last file in the link you sent me was the key to everything