Hi, author of most of the NAT madness in libp2p here.
libp2p tries really hard to work in just about any networking environment, and I think it’s been largely successful. We assume the worst case (symmetric NAT or a firewall blocking all inbound connections) and then try to take advantage of any mitigating factors (static NAT, PMP/uPNP, a configured port mapping, etc) to improve the circumstances.
I’ll try to detail the cases you mention below:
- allow no incoming connections
If libp2p can connect outbound, it will still be able to connect to the network and obtain gossiped peers and blocks. Additionally a relay address will get obtained to allow other peers to connect via existing connections. Relay addresses are not the most stable thing right now, so this can affect cases where reliable connectivity is important (challenges and consensus group membership). This is a very common configuration in the network and the one we tend to assume people have.
- Let hotspot do uPnP or NAT-PMP, if so, what ranges do I allow it to have access to? How does it deal with NAT-PMP leases expiring and changing?
It will just try to use any port that it is allocated, the port range doesn’t matter.
- port forward 44158 for one hotspot and a different port for the other hotspot
This is totally fine, the external port doesn’t matter. libp2p will figure it out and add it to its peer entry.
- Effect of the NAT being symmetric, aka NAT’ing port as well vs not.
Truly symmetric NATs are a pain, but we do detect them and work around them. It’s equivalent to the ‘block all inbound connections’ case above.
- Effect of two hotspots behind the same IP, even on different ports external ports.
This should work fine, they’ll both discover their NAT situation and any working external ports independently.
There’s still more work to be done (ipv6 support, reworking relays to be less fragile, etc) but overall the goal is that you should be able to get connected to the network in almost any network environment. Firewalled outbound connections (we run some nodes in AWS on port 443 to try to dodge this by pretending to be HTTPS but deep packet inspection won’t be fooled) and captive portal networks (think hotel wifi where you have to time your name/room number into a page before you can browse the internet) are the main cases you’'ll have problems. Adding a websocket transport might help with the former (depending on how draconian the firewall is) but the latter is not something we’re planning on solving any time soon.
Hope some of this helped,