Zebra should support separate local bind and external advertise addresses

[teor2345]

Is your feature request related to a problem? Please describe.

Currently, Zebra binds to the configured listen_addr, and also advertises that address to peers for inbound connections.

This doesn't work for nodes which bind to an internal address, but receive inbound connections on a different external address. (For example, NAT and firewalls.)

These nodes won't get inbound connections, because other nodes don't know their inbound addresses.

Describe the solution you'd like

Zebra should:

• [ ] add an external_addr config option, which can contain one or more IPv4 or IPv6 addresses
• [ ] advertise these addresses to other nodes in Version messages
• [ ] add these addresses to inbound Peers responses
  • [ ] make the AddressBook ignore any null addresses (0.0.0.0 or [::]) when adding or updating peers from any source

Describe alternatives you've considered

We could just support a single external address, but that makes dual-stack IPv4/IPv6 impossible. We could support multiple listener addresses.

[teor2345]

We can re-open this if users ask for it.

[upbqdn]

I, as a random Zebra user, am interested in having this functionality. I could run Zebra at home on a private IP, redirect its traffic through a $5 VPS (which I already pay for) with a public IP, and accept inbound connections.

[teor2345]

I, as a random Zebra user, am interested in having this functionality. I could run Zebra at home on a private IP, redirect its traffic through a 5$ VPS (that I already pay for) with a public IP, and accept inbound connections.

I just discovered a workaround for this: Run 2 Zebra instances:

1. Port forward your external IP to the first instance
2. Add your external IP (or dynamic DNS name) to the initial_mainnet_peers list for the second instance, along with the default DNS seeders

Then the second instance will connect to the first instance via your external IP, and gossip its IP address.

Other Zebra instances will also auto-detect the external IPs of instances with 0.0.0.0 in their version messages. So if you're using the default Zcash port externally, and listening on 0.0.0.0 internally, your IP might already be gossiped on the network.

[teor2345]

I'm going to re-open this, because it would have been really useful to have for the final release candidate testing.

[emersonian]

+1, all of our instances are behind load balancers and cannot yet contribute to the P2P network.

[mpguerra]

I've scheduled this for next sprint (Sprint 10) let's see if we can tackle this then

[oxarbitrage]

We could just support a single external address, but that makes dual-stack IPv4/IPv6 impossible.

I think is a lot easier to do a single external address as having multiple address will require negotiate with each one of them.

@emersonian in your case, will a single address make it ?

[emersonian]

A single address is fine with me, thanks for looking into this.

For the backlog: it would be amazing if Zebra could auto-discover its public IP address(es) as a configuration option some day, saving me an initContainer step when rolling out deployments.

[oxarbitrage]

A single address is fine with me, thanks for looking into this.

Ok, lets do this for now as my first impression is telling me it will be a lot easier.

For the backlog: it would be amazing if Zebra could auto-discover its public IP address(es) as a configuration option some day, saving me an initContainer step when rolling out deployments.

We had an issue for this (https://github.com/ZcashFoundation/zebra/issues/1893) but it was closed as not planned. @mpguerra do you think we should reopen it ?