Can't detect valid external address - unable to start MN

[Curacao]

Hi Udjin,

So I think there are some DNAT issues here to blame, apparently packets aren't recognized by the MN host, probably because the source IP is itself:
MN --> Router [DNAT Back to MN] --> MN

I've implemented a quick and dirty fix by adding our external IP to the host as a virtual additional IP:
inet 190.4.184.180/31 brd 255.255.255.255

This appears to be working as of now.

 

[UdjinM6]

Hi Udjin,

So I think there are some DNAT issues here to blame, apparently packets aren't recognized by the MN host, probably because the source IP is itself:
MN --> Router [DNAT Back to MN] --> MN

I've implemented a quick and dirty fix by adding our external IP to the host as a virtual additional IP:
inet 190.4.184.180/31 brd 255.255.255.255

This appears to be working as of now.

Thank you for the provided solution!

 

[Curacao]

Hi Devs,

I've given this some thought:
I have some concerns as to how dashcore currently checks it's external IP and availability through this address at the moment. This works fine for (master)nodes directly on the internet (say VPS'es), however for nodes behind routers (with NAT) this is an issue according to my findings. I can't think of an fix other than the dirty fix I mentioned above.
If Dash truly wants to be decentralized people should be able to run nodes in their SOHO environment, thus the software should be able to recognize it's external IP and somehow (if necessary) check it's availability through that externaliport. I believe my set-up isn't common at this time, but I think the software should be able to run in such set-ups as mine.

Feedback appreciated.

 

[UdjinM6]

Hi Devs,

I've given this some thought:
I have some concerns as to how dashcore currently checks it's external IP and availability through this address at the moment. This works fine for (master)nodes directly on the internet (say VPS'es), however for nodes behind routers (with NAT) this is an issue according to my findings. I can't think of an fix other than the dirty fix I mentioned above.
If Dash truly wants to be decentralized people should be able to run nodes in their SOHO environment, thus the software should be able to recognize it's external IP and somehow (if necessary) check it's availability through that externaliport. I believe my set-up isn't common at this time, but I think the software should be able to run in such set-ups as mine.

Feedback appreciated.

Well, it's already able to recognize its external IP from other peers or from settings, that is not a problem. The problem is connectivity - it no longer connects to whatever self address is, it connects to exact external (and only external) IP now. Given the fact that it's possible to setup a mn with the fix you provided, I think it's actually ok. This kind of initial connectivity check is not a perfect indicator of masternode capability to provide services anyway, we are going to move to a much more sophisticated model in Evolution which will account actual service requests served by each mn and determine its status based on that (or at least that is how we try to design it now). Consider this current low level verifications as a band-aid until we have a better model in place (the one I just described).

 

[Newar]

After looking at several "things", I got a feeling that I have the exact same issue.

Could you please elaborate a bit on:

[...]
I've implemented a quick and dirty fix by adding our external IP to the host as a virtual additional IP:
inet 190.4.184.180/31 brd 255.255.255.255
[...]

How do you do that?

 

[Newar]

Searching for inet 190.4.184.180/31 brd 255.255.255.255, Google revealed this thread: https://arstechnica.com/civis/viewtopic.php?t=149666 . If I understood it correctly, it recommends against this method. However, another method was offered:

iptables -t nat -A OUTPUT -s XXX.XXX.XXX.XXX -d YYY.YYY.YYY.YYY -j DNAT --to-destination 127.0.0.1

where XXX is the internal IP of the PC and YYY is the external IP. This worked for me.