Issue with openchannel_optional_addr_reverse Test Across Different IP Networks

[bitwalt]

Description:
We’re encountering an issue with the openchannel_optional_addr_reverse test when running Node1 and Node2 on separate IP networks. Below is the detailed context and observed behavior:

Setup

• Nodes:
  • Both nodes are operating on regtest.
  • Node2 is deployed on a VPS with a public IP.
  • Node1 is located behind a NAT (e.g., within a local network).
  • Node2 acts as the channel initiator (equivalent to an LSP).

Steps to Reproduce

1. Set up Node1 and Node2 on separate IP networks.
2. Connect Node1 to Node2 (connection succeeds).
3. Node2 initiates a channel opening to Node1 (API call succeeds, but the channel never opens).

Observed Behavior

• The /openchannel API call returns success, but:
  • The channel remains in the "opening" state on Node2.
  • The channel never appears on Node1.
• Node2 remains stuck in a "channel opening" state, restricting certain operations.
• If Node1 disconnects, logs on Node2 show the openchannel operation failing due to a peer disconnect.

Expected Behavior

• The channel should open successfully, even when Node1 and Node2 are in different network environments (e.g., NAT vs. public IP).

Additional Information

• This issue is specific to IP network separation and does not occur when both nodes are on the same local network.
• The problem appears to be tied to the openchannel_optional_addr_reverse test.
• In current tests, nodes are configured on the same network, which doesn’t expose this issue.

Request

Introduce a new test case to cover scenarios where Node1 and Node2 operate on separate IP networks (e.g., one behind a NAT, one with a public IP).

[nicbus]

Thanks for reporting this, we'll look into adding a test to reproduce this condition.