Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic Firewall/NAT Detection #271

Merged
merged 8 commits into from
Oct 29, 2024
Merged

Automatic Firewall/NAT Detection #271

merged 8 commits into from
Oct 29, 2024

Conversation

AgeManning
Copy link
Member

Description

Symmetric NATs and IPv6 are currently a pain point in discovery. Discv5 has a mechanism to discover its external IP and port (socket from now on). We use a majority voting system based on PONG responses.

The problem is that full-cone NATs can be included in the IP address discovery. Furthermore, with ipv6, all connections are likely not NAT'd and the external IP discovery is going to return our IPv6 address.

Currently we are assuming that if our external address is discoverable, that we are contactable (as we get discovered when a correct port forward is established in ipv4). However this will generally not be the case for full-cone NATs and IPv6. In fact, if we default to dual-stack, all ipv6 nodes will update their ENR to their ipv6 address, rendering them non-contactable (as ipv6 is the default connection for ipv6-compatible nodes) if their firewall still prevents ipv6 traffic.

We therefore need a way to determine if we are contactable or not to avoid incorrectly advertising our ipv6 or ipv4 discovered addresses.

This PR proposes the following:

  1. We discover our external IP addresses as usual (ipv6 will likely always be discovered)
  2. We advertise our discovered address as usual
  3. We wait a period of time for inbound connections
  4. If we do not see any inbound connections, we assume we are not contactable and remove our IP advertisement from our ENR and then wait an extended period of time (6 hours) before attempting again
  5. If we do see inbound connections, consider ourselves contactable and leave our ENR advertising our address, until we discover a new external ip address (as usual)

I have done some preliminary testing on this PR and it seems to function as I expect.

However with these added complexity more eyes are always helpful :)

Copy link
Member

@ackintosh ackintosh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also tested this, and it works fine!

src/service.rs Outdated Show resolved Hide resolved
@AgeManning AgeManning merged commit ccc3a57 into master Oct 29, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants