search

lightningnetwork / lnd

Lightning Network Daemon ⚡️
MIT License
7.64k stars 2.08k forks source link

NAT=true not working #2008

Closed frennkie closed 5 years ago

frennkie commented 5 years ago

Background

I just configured nat=true in my lnd.conf and started lnd. I receive the following error message and lnd stops:

2018-10-04 20:58:52.188 [INF] SRVR: Scanning local network for a UPnP enabled device
2018-10-04 20:59:02.194 [ERR] SRVR: Unable to discover a UPnP enabled device on the local network: context canceled
2018-10-04 20:59:02.194 [INF] SRVR: Scanning local network for a NAT-PMP enabled device
2018-10-04 20:59:02.221 [ERR] SRVR: Unable to discover a NAT-PMP enabled device on the local network: fork/exec /usr/bin/ip: no such file or directory
2018-10-04 20:59:02.221 [ERR] SRVR: unable to create server: Unable to discover a NAT-PMP enabled device on the local network: fork/exec /usr/bin/ip: no such file or directory

On my Raspbian 9 the ip binary is located at /sbin/ip.

I created a symlink from /usr/bin/ip to /sbin/ip which only me brings me one step further until it crashes:

2018-10-04 21:08:11.119 [ERR] SRVR: Unable to discover a UPnP enabled device on the local network: context canceled
2018-10-04 21:08:11.119 [INF] SRVR: Scanning local network for a NAT-PMP enabled device
2018-10-04 21:08:11.147 [ERR] SRVR: Unable to discover a NAT-PMP enabled device on the local network: unexpected result size 2, expected 12
2018-10-04 21:08:11.147 [ERR] SRVR: unable to create server: Unable to discover a NAT-PMP enabled device on the local network: unexpected result size 2, expected 12

What can I do to help debug and fix this issue?

Your environment

wpaulino commented 5 years ago

This seems to be an issue with the dependency itself (https://github.com/jackpal/go-nat-pmp) being used to support NAT traversal. I would suggest opening an issue there as there's not much we can do from our end.

frennkie commented 5 years ago

@wpaulino well, I guess my router does not support NAT-PMP.. as far as I see it there are (at least) these technologies that are related to clients talking to network gateways:

NAT-PMP (->Apple) is the oldest and PCP (which doesn't seem to provide the external IP) the newest. Currently lnd ~only~ uses https://github.com/jackpal/go-nat-pmp which only implements NAT-PMP. I guess my router only supports UPnP and not NAT-PMP.

I just looked around and found: https://github.com/NebulousLabs/go-upnp which works like a charm with this simple code:

package main

import (
        "fmt"
        "log"
        "github.com/NebulousLabs/go-upnp"
)

func main() {
    // connect to router
    d, err := upnp.Discover()
    if err != nil {
        log.Fatal(err)
    }

    // discover external IP
    ip, err := d.ExternalIP()
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("Your external IP is:", ip)
}

running it:

$ go run src/nat/nat.go
Your external IP is: 87.xxx.yyy.zzz
frennkie commented 5 years ago

Hm.. just noticed that lnd already uses github.com/NebulousLabs/go-upnp in nat/upnp.go.

wpaulino commented 5 years ago

Yeah, you can see how the gateway discovery in the server is being done here.

The UPnP discovery code is very similar. The only difference is that we'll restrict the discovery attempt up to 10 seconds to prevent it from halting server startup for too long.

frennkie commented 5 years ago

@wpaulino I have also been looking trough the code a bit. Also: The error I experienced yesterday has disappeared.. so this might have been a network glitch.

Anyway I think I still have an issue, but this might be due to a misunderstanding on my side, so let's start over:

Background

I have lnd running behind a NAT device. The NAT device re-connects to the internet every 24 hours and gets a different external IP assigned. All IPs on the the local network (192.168.178.0/24) stay the same. I have configured a static port forwarding on the NAT device for the external port 9735 to my host running lnd (also to port 9735).

Scenario 1)

When I start lnd and run lncli getinfo I get the following:

[...]
    "uris": [
        "03730a3b06d33d...07969d9a@1.2.3.4:9735"
    ],
[...]

Scenario 2)

When I then start lnd and run lncli getinfo I get the following:

[...]
    "uris": [
    ],
[...]

Expected behaviour

The uris section of getinfo should show a valid connection string in both cases.

Actual behaviour

The uris section of getinfo does not have any entry when I use nat=true.

I enabled SRVR=debug and get the following:

2018-10-05 23:00:14.470 [INF] SRVR: Scanning local network for a UPnP enabled device
2018-10-05 23:00:18.717 [DBG] SRVR: Unable to forward port 9735: goupnp: SOAP request got HTTP 500 Internal Server Error: <?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>403</errorCode>
<errorDescription>Not available Action</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
2018-10-05 23:00:18.719 [INF] SRVR: Automatically set up port forwarding using UPnP to advertise external IP

The reason for this might be that my NAT device already has a port forwarding for the port 9735.

But as far as I see it I do not need a port forwarding to be set up. Because I have already configured it statically. What I assume is important is that lnd learns the external IP address...

frennkie commented 5 years ago

Making some progress.. I just changed this 

func (s *server) configurePortForwarding(ports ...uint16) ([]string, error) {
    ip, err := s.natTraversal.ExternalIP()
    if err != nil {
        return nil, err
    }
    s.lastDetectedIP = ip

    externalIPs := make([]string, 0, len(ports))
    for _, port := range ports {
        if err := s.natTraversal.AddPortMapping(port); err != nil {
            srvrLog.Debugf("Unable to forward port %d: %v", port, err)
            continue
        }

        hostIP := fmt.Sprintf("%v:%d", ip, port)
        externalIPs = append(externalIPs, hostIP)
    }

    return externalIPs, nil
}

into this

func (s *server) configurePortForwarding(ports ...uint16) ([]string, error) {
    ip, err := s.natTraversal.ExternalIP()
    if err != nil {
        return nil, err
    }
    s.lastDetectedIP = ip

    externalIPs := make([]string, 0, len(ports))
    for _, port := range ports {
        hostIP := fmt.Sprintf("%v:%d", ip, port)
        externalIPs = append(externalIPs, hostIP)
    }

    return externalIPs, nil
}

Now I get the correct "uri" information.

So the problem here is that when I set nat=true and lnd is unable to set the port fowarding by itself it will assume there is no port forwarding and will think it is not reachable (right?!). But as in my case this is not true because I setup the forwarding manually. I only need UPnP so that lndcan learn the changed IP address every 24 hours.

wpaulino commented 5 years ago

That's correct, as is lnd will not advertise the address/port if it was unable to set up the port forward for whatever reason. If you wish to run this without any additional patches, I would suggest removing the manual static port forward on your router and have lnd do it instead.

frennkie commented 5 years ago

I removed the static port forwarding on the NAT device and I still get the same error message (Not available Action):

Request

POST /igdupnp/control/WANIPConn1 HTTP/1.1
Host: 192.168.178.1:49000
User-Agent: Go-http-client/1.1
Content-Length: 598
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"
Accept-Encoding: gzip

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost></NewRemoteHost>
<NewExternalPort>9735</NewExternalPort>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>9735</NewInternalPort>
<NewInternalClient>192.168.178.116</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription></NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping>
</s:Body>
</s:Envelope>

Response

HTTP/1.1 500 Internal Server Error
DATE: Fri, 05 Oct 2018 22:48:05 GMT
SERVER: FRITZ!Box 7530 (UI) UPnP/1.0 AVM FRITZ!Box 7530 (UI) 164.06.93
CONNECTION: keep-alive
CONTENT-LENGTH: 439
CONTENT-TYPE: text/xml; charset="utf-8"

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>403</errorCode>
<errorDescription>Not available Action</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
frennkie commented 5 years ago

Well.. this is embarrassing.. my NAT device has two separate settings for UPnP port forwardings. One to generally disabling this (which I had not set). But I also had to enable this individually for the lnd host.

So, mostly sorry for wasting your time... although I think I learned quite a lot about lnd, go and NAT through this.. :-)

I still find it confusing (or maybe even wrong) that there is a direct interdependency between "Set up port forwardings" and "Please auto discover changes on my external IP".

frennkie commented 5 years ago

There is still a (definite) bug in the log messages.

https://github.com/lightningnetwork/lnd/blob/master/server.go

dennisreimann commented 5 years ago

Just cross-referencing here, but I hope this helps anyone struggling with this: Stadicus/guides#249

japaweiss commented 5 years ago

I had the same error so far (under Windows 10). But today it worked:

2018-11-26 09:13:26.392 [INF] LNWL: Started listening for bitcoind transaction notifications via ZMQ on tcp://127.0.0.1:18504
2018-11-26 09:13:26.392 [INF] LNWL: Started listening for bitcoind block notifications via ZMQ on tcp://127.0.0.1:18503
2018-11-26 09:13:28.578 [INF] LNWL: The wallet has been unlocked without a time limit
2018-11-26 09:13:28.585 [INF] LTND: LightningWallet opened
2018-11-26 09:13:28.620 [INF] LNWL: Catching up block hashes to height 551547, this will take a while...
2018-11-26 09:13:28.788 [INF] HSWC: Restoring in-memory circuit state from disk
2018-11-26 09:13:28.838 [INF] HSWC: Payment circuits loaded: num_pending=0, num_open=0
2018-11-26 09:13:28.890 [INF] SRVR: Scanning local network for a UPnP enabled device
2018-11-26 09:13:32.574 [INF] LNWL: Done catching up block hashes
2018-11-26 09:13:32.652 [INF] LNWL: Started rescan from block 000000000000000000181e29d96227aa3dd7094e2b722c7ad6e227b3b08f8db6 (height 550614) for 2 addresses
2018-11-26 09:13:32.652 [INF] LNWL: Starting rescan from block 000000000000000000181e29d96227aa3dd7094e2b722c7ad6e227b3b08f8db6
2018-11-26 09:13:33.088 [INF] LNWL: Catching up block hashes to height 550614, this might take a while
2018-11-26 09:13:33.158 [INF] LNWL: Done catching up block hashes
2018-11-26 09:13:33.159 [INF] LNWL: Rescanned through block 00000000000000000029f0f5e485da9f20715bb20e6921d6f58406311b1eb6ab (height 550614)
2018-11-26 09:13:33.190 [INF] SRVR: Automatically set up port forwarding using UPnP to advertise external IP
2018-11-26 09:13:33.366 [INF] RPCS: RPC server listening on 127.0.0.1:10009
2018-11-26 09:13:33.367 [INF] RPCS: gRPC proxy started at 127.0.0.1:8080

After restarting the server I got the same error again and since then it doesn't work anymore:

2018-11-26 11:30:22.520 [INF] LTND: Received shutdown request.
2018-11-26 11:30:22.520 [INF] LTND: Shutting down...
2018-11-26 11:30:22.523 [INF] LTND: Gracefully shutting down.
2018-11-26 11:30:22.523 [INF] ATPL: Autopilot Agent stopping
2018-11-26 11:30:22.523 [INF] CRTR: Channel Router shutting down
2018-11-26 11:30:22.524 [INF] CRTR: FilteredChainView stopping
2018-11-26 11:30:22.524 [INF] HSWC: HTLC Switch shutting down
2018-11-26 11:30:22.523 [INF] HSWC: Block epoch canceled, decaying hash log shutting down
2018-11-26 11:30:22.575 [INF] UTXN: UTXO nursery shutting down
2018-11-26 11:30:22.579 [INF] BRAR: Breach arbiter shutting down
2018-11-26 11:30:22.580 [INF] DISC: Authenticated Gossiper is stopping
2018-11-26 11:30:22.580 [INF] CNCT: Stopping ChainArbitrator
2018-11-26 11:30:22.581 [INF] FNDG: Funding manager shutting down
2018-11-26 11:30:22.581 [INF] SRVR: Disconnecting from 213.174.156.70:9735
2018-11-26 11:30:22.581 [INF] PEER: Disconnecting 213.174.156.70:9735, reason: server: disconnecting peer 213.174.156.70:9735
2018-11-26 11:30:22.582 [INF] PEER: unable to read message from 213.174.156.70:9735: read tcp 192.168.178.47:60317->213.174.156.70:9735: use of closed network connection
2018-11-26 11:30:22.582 [INF] SRVR: Disconnecting from 138.68.244.82:9735
2018-11-26 11:30:22.582 [INF] PEER: Disconnecting 138.68.244.82:9735, reason: server: disconnecting peer 138.68.244.82:9735
2018-11-26 11:30:22.583 [INF] PEER: unable to read message from 138.68.244.82:9735: read tcp 192.168.178.47:60316->138.68.244.82:9735: use of closed network connection
2018-11-26 11:30:22.737 [INF] LTND: Shutdown complete
2018-11-26 11:31:06.639 [INF] LTND: Version: 0.5.0-beta commit=, build=production, logging=default
2018-11-26 11:31:06.639 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2018-11-26 11:31:06.641 [INF] CHDB: Checking for schema update: latest_version=6, db_version=6
2018-11-26 11:31:06.674 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
2018-11-26 11:31:06.674 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080
2018-11-26 11:31:06.675 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2018-11-26 11:31:24.952 [INF] LNWL: Opened wallet
2018-11-26 11:31:25.222 [INF] LTND: Primary chain is set to: bitcoin
2018-11-26 11:31:25.286 [INF] LTND: Initializing bitcoind backed fee estimator
2018-11-26 11:31:25.286 [INF] LNWL: Started listening for bitcoind block notifications via ZMQ on tcp://127.0.0.1:18503
2018-11-26 11:31:25.286 [INF] LNWL: Started listening for bitcoind transaction notifications via ZMQ on tcp://127.0.0.1:18504
2018-11-26 11:31:27.491 [INF] LNWL: The wallet has been unlocked without a time limit
2018-11-26 11:31:27.497 [INF] LTND: LightningWallet opened
2018-11-26 11:31:27.534 [INF] LNWL: Catching up block hashes to height 551556, this will take a while...
2018-11-26 11:31:27.660 [INF] HSWC: Restoring in-memory circuit state from disk
2018-11-26 11:31:27.761 [INF] LNWL: Done catching up block hashes
2018-11-26 11:31:27.805 [INF] HSWC: Payment circuits loaded: num_pending=0, num_open=0
2018-11-26 11:31:27.891 [INF] LNWL: Started rescan from block 000000000000000000181e29d96227aa3dd7094e2b722c7ad6e227b3b08f8db6 (height 550614) for 2 addresses
2018-11-26 11:31:27.891 [INF] LNWL: Starting rescan from block 000000000000000000181e29d96227aa3dd7094e2b722c7ad6e227b3b08f8db6
2018-11-26 11:31:27.915 [INF] SRVR: Scanning local network for a UPnP enabled device
2018-11-26 11:31:28.357 [INF] LNWL: Catching up block hashes to height 550614, this might take a while
2018-11-26 11:31:28.451 [INF] LNWL: Done catching up block hashes
2018-11-26 11:31:28.465 [INF] LNWL: Rescanned through block 00000000000000000029f0f5e485da9f20715bb20e6921d6f58406311b1eb6ab (height 550614)
2018-11-26 11:31:37.923 [ERR] SRVR: Unable to discover a UPnP enabled device on the local network: context canceled
2018-11-26 11:31:37.923 [INF] SRVR: Scanning local network for a NAT-PMP enabled device
2018-11-26 11:31:38.264 [ERR] SRVR: Unable to discover a NAT-PMP enabled device on the local network: no gateway found
2018-11-26 11:31:38.264 [ERR] SRVR: unable to create server: Unable to discover a NAT-PMP enabled device on the local network: no gateway found

2018-11-26 11:31:38.335 [INF] LTND: Shutdown complete

Is it perhaps due to the time or the attempts it has?

wpaulino commented 5 years ago

@japaweiss the gateway discovery will take up to 10 seconds, so if we can't discover it by then, we either try the next or exit.

japaweiss commented 5 years ago

Can I increase the 10 seconds somehow to test if it's because the discovery needs more time? Or do you have another idea why it worked once and then not anymore without changing anything?

wpaulino commented 5 years ago

Can I increase the 10 seconds somehow to test if it's because the discovery needs more time?

See https://github.com/lightningnetwork/lnd/blob/master/server.go#L362.

frennkie commented 5 years ago

@japaweiss The 10 seconds are currently hardcoded here: server.go#L362. If you feel comfortable you could simply change that value, recompile and run that version for testing.

But I doubt that this is your problem. My suggestion would be to look at the network packets. Either locally (tcpdump), or the network using a mirror port - or both.

Do you have a local firewall (iptables) that could be blocking packets?

japaweiss commented 5 years ago

Completely shutting down the server, router and one additional router which worked as an AP in my network solved the issue

verquepasa commented 5 years ago

My Fix

My router supports Upnp I checked that it was working fine using a really nice Windows app Upnp Tester. My raspberry LN was not able to get the upnp working. I made it work by disabling ufw (even though I had 1900 UDP port enabled)

I decided to enable ufw anyways and see why it wasn't working I checked /var/log/syslog and found several UDP packets from my router to my raspberry with random source and dst ports blocked, those were the ones preventing it to work.

In this link I found the problem: upnp uses random ports (sometimes?): https://github.com/nextcloud/nextcloudpi/issues/400

TL;DR: open all udp ports from my router sudo ufw allow proto udp from 192.168.1.1

perefeliu commented 5 years ago

This worked for me too. Thanks @verquepasa

Is it not a little dangerous to open all UDP ports from the router to the the RPi?

frennkie commented 5 years ago

@verquepasa Are you sure that the incoming packets have random source ports? I configured my RPi with this line and UPNP is working:

sudo ufw allow proto udp from 192.168.178.1 port 1900 to any comment 'allow local LAN SSDP for UPnP discovery'
verquepasa commented 5 years ago

This worked for me too. Thanks @verquepasa

Is it not a little dangerous to open all UDP ports from the router to the the RPi?

Yes, not ideal, but what can we do. In order to be attacked, the raspberry's linux must have a udp enabled vulnerability first, then the attacker must get control of your router somehow and then upload a modified firmware to exploit the vulnerability.

andronoob commented 5 years ago

I wonder is it possible to let LND embed a routing hint into invoices by default if UPnP failed?

andronoob commented 5 years ago

@wpaulino It's still failing for me. Bitcoin Core 0.17 works flawlessly on the same machine (Win10 x64 17763). I tried wireshark and procmon, then I found that bitcoin-qt.exe seemed to be able to receive SSDP response (UDP Receive appeared in procmon), while lnd.exe failed to do this (only UDP Send recorded, no UDP Receive recorded).

frennkie commented 5 years ago

@andronoob Could this be caused by the Windows firewall? Do you have a network based sniffer to check whether the NAT device gets and responds to the request? (this helped me find out what I need to configure in iptables/ufw on linux)

andronoob commented 5 years ago

In the beginning, Wireshark showed nothing (with udp contains "HTTP" filter). lnd then exited due to failed port mapping attempt. Then I turned lnd.exe from "disallow" into "allow" in the Advanced Settings of Windows Defender Firewall. After that, I restarted lnd, though Wireshark showed some traffic this time, it still failed once again.

By the way, I wonder if some Windows settings would affect LND? Eg. the SSDP Discovery service, and the "Turn on network discovery" in the control panel?

andronoob commented 5 years ago

Oh, it seemed that I had misinterpreted what Wireshark showed me. There are some apps (Google Chrome maybe?) also sending SSDP discovery packets in the same time.

frennkie commented 5 years ago

By the way, I wonder if some Windows settings would affect LND? Eg. the SSDP Discovery service, and the "Turn on network discovery" in the control panel?

I have not tested lnd on windows but IMO it is very likely that Windows settings have an effect on this.

andronoob commented 5 years ago

I found something weird: Procmon showed that lnd was sending UDP packets from 169.254.167.193:56517 to 239.255.255.250:1900 - instead of 192.168.1.X:XXXXX -> 239.255.255.250:1900

@frennkie I don't know much around this stuff, but I guess that LND should not rely on UPnP services provided by Windows.

However, I found that enabling the SSDP Discovery service and the Turn on network discovery setting in the control panel can be very useful: Windows provides a friendly GUI to configure UPnP port mapping settings, my router appeared in the "Network" view of explorer as an "IGD device", the UPnP settings can be found in the properties of that "IGD device" icon.

frennkie commented 5 years ago

but I guess that LND should not rely on UPnP services provided by Windows.

Correct.. lnd implements the UPnP for itself and therefore does not use the Windows subsystem. But if Windows prevents the packets from reaching lnd or the NAT device then it will not work.

lnd was sending UDP packets from 169.254.167.193:56517 to 239.255.255.250:1900

Perfectly fine. That is the way the SSDP (Simple Service Discovery Protocol) works. The NAT device will respond to this multicast with a unicast reply (UDP, Src Port 1900, Dst Port Random) and this reply includes the Location of the service (in my case hxxp://192.168.0.1:49000/igddesc.xml).

frennkie commented 5 years ago

169.254.167.193

This actually looks strange. I assume you are using either DHCP or static IPs on your (192.168.1.0/24) network, right? Maybe this is a problem.

andronoob commented 5 years ago

Perfectly fine.

I don't think so. LND must be probing on a wrong interface. 169.254.167.193 was the link-local address of a virtual adaptor (Npcap loopback adaptor).

After disabling all unrelated adaptors (both virtual and physical), Procmon showed that LND could probe on the correct interface now, however, Wireshark showed that my router responded a "500 internal service error" to LND.

andronoob commented 5 years ago

@wpaulino I saw the "NewPortMappingDescription" field was empty - is that correct?

frennkie commented 5 years ago

After disabling all unrelated adaptors (both virtual and physical)

This sounds like there may be the need to more cleverly detect the local IP/interface - at least on Windows.

Wireshark showed that my router responded a "500 internal service error" to LND.

There are multiple steps, at least:

When do you get that error? Can you give some more details?

andronoob commented 5 years ago

When do you get that error?

I've found the reason - my router won't accept port mapping request with an empty NewPortMappingDescription field. I manually edited the HTTP request data & resent it, then it worked.

andronoob commented 5 years ago

IMHO, even if UPnP works, there are still a lot of issues:

  1. ISP may forcefully reassign a new IP address - all existing connection will simply break.

  2. Carrier-grade NAT (CGN) has been deployed widely, for quite a long time. In this scenario, port mapping isn't an available option at all.

  3. IP address might be a sensitive privacy info.

frennkie commented 5 years ago

my router won't accept port mapping request with an empty NewPortMappingDescription field.

What vendor/model are you using?

I manually edited the HTTP request data & resent it, then it worked.

The line in lnd that sets an empty Description is here: https://github.com/lightningnetwork/lnd/blob/master/nat/upnp.go#L65. If you change this to something (e.g. "LND") and recompile this should work for you. Can you give this a try?

ISP may forcefully reassign a new IP address - all existing connection will simply break.

Yes, this (or at least something similar) caused me to create https://github.com/lightningnetwork/lnd/pull/2014 which was recently merged into master. lnd will recover after an external IP change by periodically updating the port forwarding.

Carrier-grade NAT (CGN) has been deployed widely, for quite a long time. In this scenario, port mapping isn't an available option at all.

Correct.. I assume then your only option is Tor or another kind of VPN technology. What is the point of your statement?

IP address might be a sensitive privacy info.

I have not yet read up on or tested the Tor implementation of lnd. But I assume this was done to address that concern.

andronoob commented 5 years ago

What vendor/model are you using?

That doesn't matter, I think, since there must be countless users using the same model as mine.

If you change this to something (e.g. "LND") and recompile this should work for you. Can you give this a try?

I think it should work - but I don't have build environment still. Even if it works, there's still another issue: go-nat-pmp is probing on an incorrect interface.

I assume then your only option is Tor or another kind of VPN technology.

It's well known that Tor had been block by various entities, esp. the GFW of China - however, I don't think Internet censorship a big issue for now, since there're still some working workarounds, eg. shadowsocks.

What is the point of your statement?

The LN protocol seems to have some limitations which might affect common home node operators.

frennkie commented 5 years ago

That doesn't matter, I think, since there must be countless users using the same model as mine.

That was exactly the reason I was asking. Other people might have the same equipment and will run into the same issue(s). Collecting which vendors/devices require which "special" treatment could help in determining the correct way to solve this in a generally acceptable way.

Even if it works, there's still another issue: go-nat-pmp is probing on an incorrect interface.

Now you are confusing me..! ;-D Are you using NAT-PMP or UPnP? These are different protocols and RfCs. My Router (AVM Fritzbox) only supports UPnP. NAT-PMP (and the even more recent PCP) seem to often be available on Apple devices (e.g. Airport Extreme) which I don't have.

But you are right.. if lnd uses the wrong source IP when there are multiple interfaces then I would consider this a bug which either needs to be fixed in lnd or upstream in the packages that are used.

I would suggest you open two separate issues. One for the empty description and one (most likely in https://gitlab.com/NebulousLabs/go-upnp/ - if you are using UPnP) for the wrong source interface/IP selection on the SSDP requests.

andronoob commented 5 years ago

Collecting which vendors/devices require which "special" treatment could help in determining the correct way to solve this in a generally acceptable way.

It's a home gateway device made by Huawei. However, I don't know what strategy could be taken to make a "special" treatment" which is specific to this device. By the way, whether filling "LND" into NewPortMappingDescription will cause more problems should be more important - although I don't think this will be a problem.

Now you are confusing me

Sorry. It's UPnP, not NAT-PMP.

frennkie commented 5 years ago

By the way, whether filling "LND" into NewPortMappingDescription will cause more problems should be more important - although I don't think this will be a problem.

I tested this on my Router - no problems so far.