Is this a valid approach for testing P2P behind CGNAT?

[slw2qdc6xqca]

I'm testing a P2P node running on Android/Termux behind CGNAT.
For testing, I used a temporary Pinggy tunnel to expose one node.
The remote node discovered the peer and successfully synced the chain. The "/chain" response from the public endpoint matched both local nodes (3 blocks).

POST /add_peer → 200
GET /peers → 200
GET /chain → 200

Public endpoint → 3 blocks
127.0.0.1:5000 → 3 blocks
127.0.0.1:8080 → 3 blocks

Is this a reasonable approach for testing P2P connectivity behind CGNAT, or is there a better approach?

[DireWolfM14]

I've never used Termux.  Can it run a Tor node?

One of my properties doesn't have great internet options, so while living there I opted for Starlink which uses CGNAT unless you want to pay like $300 a month for static direct IP.  I found the simplest way to run P2P was to use Tor and set up hidden services for all the services I wanted access to outside the local network.  It was very reliable and relatively simple to set up.

Another option is to host a small remote server running a wireguard server and nginx reverse proxy, and connect the local node devices to that.  That's a bit more complex, but you'll have a clearnet address to connect to rather than just onion addresses.

[slw2qdc6xqca]

I've never used Termux.  Can it run a Tor node?

One of my properties doesn't have great internet options, so while living there I opted for Starlink which uses CGNAT unless you want to pay like $300 a month for static direct IP.  I found the simplest way to run P2P was to use Tor and set up hidden services for all the services I wanted access to outside the local network.  It was very reliable and relatively simple to set up.

Another option is to host a small remote server running a wireguard server and nginx reverse proxy, and connect the local node devices to that.  That's a bit more complex, but you'll have a clearnet address to connect to rather than just onion addresses.

Thanks for the suggestions. I’m currently testing P2P networking on Android/Termux behind CGNAT, so I’m using a temporary tunnel to provide an externally reachable endpoint. The goal is only to test peer discovery and blockchain synchronization, not production deployment. The test successfully discovered the peer and synchronized the chain

[Cinexa]

I'm testing a P2P node running on Android/Termux behind CGNAT.
For testing, I used a temporary Pinggy tunnel to expose one node.
The remote node discovered the peer and successfully synced the chain. The "/chain" response from the public endpoint matched both local nodes (3 blocks).

POST /add_peer → 200
GET /peers → 200
GET /chain → 200

Public endpoint → 3 blocks
127.0.0.1:5000 → 3 blocks
127.0.0.1:8080 → 3 blocks

Is this a reasonable approach for testing P2P connectivity behind CGNAT, or is there a better approach?

Yeah - for a smoke test that is a success.

Tunneling the termux node through Pinggy only provides an ephemeral public address with which an other peer can reach out to your node - pairing on 3 blocks both locally and the public exposed connection indicates that your app-layer connection between the nodes has been established (peer add, discover and sync).

This not in fact a real CGNAT setup yet (the connection with pinggy is simply routing inbound traffic over your own, outbound connection), so not "punching trough" the carrier's CGNAT - but it works for the purpose of testing the network path. You more normally see a fixed public seed(later on maybe STUN/TURN/relay) so that the phone just establishes the outer dial.

But for what your were trying it out seems like good result!

[Danish Ali]

Yeah, to top off Cinexa here a little. If you are looking to get "does my node handle CGNAT ok", this test does not really give everything you need, as Pinggy is basically doing the hard bit for you. It does not necessarily have awareness, or active behind a translated IP, it is simply communicating with a "holed" tunnel.
To test it, try running 2 nodes (using docker networks or VMs is perfectly fine here, and one does not need real hardware), and do not have either of them complete a tunnel or give any relay to each other. Then test to see, they are able to locate each other at all. That is more the real problem with CGNAT.
If things do not matter, it will help you with something you already did, you can use peer discovery/sync/all this app level stuff. Not the same as it will survive CGNAT though.

[slw2qdc6xqca]

I'm testing a P2P node running on Android/Termux behind CGNAT.
For testing, I used a temporary Pinggy tunnel to expose one node.
The remote node discovered the peer and successfully synced the chain. The "/chain" response from the public endpoint matched both local nodes (3 blocks).

POST /add_peer → 200
GET /peers → 200
GET /chain → 200

Public endpoint → 3 blocks
127.0.0.1:5000 → 3 blocks
127.0.0.1:8080 → 3 blocks

Is this a reasonable approach for testing P2P connectivity behind CGNAT, or is there a better approach?

Yeah - for a smoke test that is a success.

Tunneling the termux node through Pinggy only provides an ephemeral public address with which an other peer can reach out to your node - pairing on 3 blocks both locally and the public exposed connection indicates that your app-layer connection between the nodes has been established (peer add, discover and sync).

This not in fact a real CGNAT setup yet (the connection with pinggy is simply routing inbound traffic over your own, outbound connection), so not "punching trough" the carrier's CGNAT - but it works for the purpose of testing the network path. You more normally see a fixed public seed(later on maybe STUN/TURN/relay) so that the phone just establishes the outer dial.

But for what your were trying it out seems like good result!

Thanks, that makes sense. The Pinggy test was mainly useful for checking the application-layer peer discovery and synchronization.

I'll keep in mind that it doesn't demonstrate actual CGNAT traversal. Thanks for the clarification.

Yeah, to top off Cinexa here a little. If you are looking to get "does my node handle CGNAT ok", this test does not really give everything you need, as Pinggy is basically doing the hard bit for you. It does not necessarily have awareness, or active behind a translated IP, it is simply communicating with a "holed" tunnel.
To test it, try running 2 nodes (using docker networks or VMs is perfectly fine here, and one does not need real hardware), and do not have either of them complete a tunnel or give any relay to each other. Then test to see, they are able to locate each other at all. That is more the real problem with CGNAT.
If things do not matter, it will help you with something you already did, you can use peer discovery/sync/all this app level stuff. Not the same as it will survive CGNAT though.

Thanks for the additional explanation. I'll try the two-node test without a tunnel and see whether the nodes can discover each other directly.

Also, if you're interested, would you be willing to help test Queen? Even just running a node and reporting any bugs or networking issues would be very helpful.

[Cinexa]

I've never used Termux.  Can it run a Tor node?

Yeah, Termux can run Tor. pkg install tor and you can set up a hidden service pointing at whatever local port you want. People run onion services straight off a phone that way. Ah yes, the very familiar CGNAT problem with your Starlink installation. You will not be able to receive traffic without paying for a true public IP address. A Tor onion service would be the way around that. Devices only initiate outbound connections which Starlink will allow, and other peers will try to connect to the .onion rather than attempting to go through the NAT.

This is also somewhat closer to a real world CGNAT implementation than what the other commenter had with the Pinggy tunnel. Pinggy merely forwards inbound traffic on your behalf. Tor HS is would be the real way to see how a node can be exposed without a true public IP address.

A WireGuard plus reverse proxy setup through a VPS is a better solution if you just desire a common clearnet address but have more pieces to worry about, as well as need that other box for however long it will be functioning to stay online. Tor onion service would still be the path of least resistance in order to expose your P2P node behind CGNAT.

[Danish Ali]

Also, if you're interested, would you be willing to help test Queen? Even just running a node and reporting any bugs or networking issues would be very helpful.

Time's a bit tight on my end, so I can't promise anything firm, but I'll try to fit it in when I get a chance.