<p>first of all if your lightning node sits behind a NAT it can still connect to other lightning nodes and also open channels with them. once you have channels you don't need a public IP address but your node id is enough. your channel partner and nat will solve the rest. </p>

<p>The problem is that your node behind a NAT does not have a public IP address. therefor you need to configure port forwarding in your NAT.</p>

<p><strong>edit</strong>:
Also you can run your lightning node behind a toronion to have a static address. </p>

CC BY-SA 4.0
2019-02-07T01:19:12.633Z
To my understanding, port forwarding configuration is not available for CGN users.
Chris Chen
CC BY-SA 4.0
2019-02-07T01:21:03.153Z
There's another problem: on-chain funds are linked to IP address.
Chris Chen
CC BY-SA 4.0
2019-02-07T10:05:20.460Z
No, on chain funds are not linked to ip addresses. No ip Address stored in the blockchain
Rene Pickhardt
CC BY-SA 4.0
2019-02-08T00:54:30.060Z
But IP address and funding txid are published across the LN, isn't it?
Chris Chen
CC BY-SA 4.0
2019-02-08T09:11:46.910Z
Only the funding txid and the nodeid but not the iPad dress of the node. The ip Adress is published at a different part of the protocol. That is why it is easy for the node to change its ip address for example if moved to a different server
Rene Pickhardt
CC BY-SA 4.0
2020-03-03T07:41:48.127Z
Just edited the option to run behind tor into my answer
Rene Pickhardt
CC BY-SA 4.0
2019-02-07T01:14:12.557Z
2020-03-03T07:41:08.223Z
2020-03-03T07:41:08.223Z
Rene Pickhardt
<p><a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow noreferrer">IPv6 is still growing</a>, so the problem described should be temporary - as in solved within 50 years. In the meantime, how about a portforwarding arrangment like this: Bob's LN node connects to his (ipv4) webserver on port 9736; Alice connects to Bob's webserver on port 9735; Bob's webserver sends inbound traffic on 9735 out 9736 and vice versa. </p>

CC BY-SA 4.0
2019-02-07T01:33:23.363Z
2019-02-07T01:33:23.363Z
Alistair Mann
<p>As we all know, IPv4 address space is already exhausted, many ISPs have deployed carrier grade NAT (CGN). So how could an LN node living behind NAT deal with NAT transversal problem? How could two NATed LN nodes communicate with each other?</p>

<lightning-network><network>
How could LN mitigate NAT transversal problem?
Chris Chen
# How could LN mitigate NAT transversal problem?

(Asked by: username_0 on 2019-02-07)

As we all know, IPv4 address space is already exhausted, many ISPs have deployed carrier grade NAT (CGN). So how could an LN node living behind NAT deal with NAT transversal problem? How could two NATed LN nodes communicate with each other?

**Tags:** lightning-network, network


---

## 2 answers

### Answer by username_1 on 2019-02-07. Score: 1 | Accepted answer

first of all if your lightning node sits behind a NAT it can still connect to other lightning nodes and also open channels with them. once you have channels you don't need a public IP address but your node id is enough. your channel partner and nat will solve the rest.

The problem is that your node behind a NAT does not have a public IP address. therefor you need to configure port forwarding in your NAT.

**edit**:
Also you can run your lightning node behind a toronion to have a static address.

> **Comments:**
> **username_0**: To my understanding, port forwarding configuration is not available for CGN users.  
> **username_0**: There's another problem: on-chain funds are linked to IP address.  
> **username_1**: No, on chain funds are not linked to ip addresses. No ip Address stored in the blockchain  
> **username_0**: But IP address and funding txid are published across the LN, isn't it?  
> **username_1**: Only the funding txid and the nodeid but not the iPad dress of the node. The ip Adress is published at a different part of the protocol. That is why it is easy for the node to change its ip address for example if moved to a different server  
> **username_1**: Just edited the option to run behind tor into my answer  

---

### Answer by username_2 on 2019-02-07. Score: 0

[IPv6 is still growing](https://www.google.com/intl/en/ipv6/statistics.html), so the problem described should be temporary - as in solved within 50 years. In the meantime, how about a portforwarding arrangment like this: Bob's LN node connects to his (ipv4) webserver on port 9736; Alice connects to Bob's webserver on port 9735; Bob's webserver sends inbound traffic on 9735 out 9736 and vice versa.


---

