Listening for calls behind NAT

[owenauch]

Hello, I was wondering if anyone know how to get peers to connect when one (or, ultimately for my use case, both) are behind NAT. Right now, I'm running the same code on two peers -- one on my local computer behind a NAT router (call it machine A), and one on a cloud-based VM (call it machine B). I'm pointing both to the public signaling server and each is both trying to dial each peer with and listening for the same protocol string, and then sends a message. When machine A (behind NAT) tries to dial machine B (not behind NAT), machine B receives the message from machine A, and the machine A has this Connection object:

Connection {
  peerInfo: 
   PeerInfo {
     id: 
      PeerId {
        _id: <Buffer 12 20 04 79 18 2f e0 e5 5b 99 58 ff ce d9 34 24 88 ff c7 6f fc cf f1 28 4b 4f ff 73 6b 21 ed 89 40 83>,
        _idB58String: 'QmNe7SHzM2amR2xHPpvKTvD46mL9KHc7Qwf1D6T7jD4Dbg',
        _privKey: undefined,
        _pubKey: undefined },
     multiaddrs: MultiaddrSet { _multiaddrs: [Array], _observedMultiaddrs: [] },
     protocols: Set {},
     _connectedMultiaddr: <Multiaddr 361b737461722d7369676e616c2e636c6f75642e697066732e7465616d0601bbde039302a5032212200479182fe0e55b9958ffced9342488ffc76ffccff1284b4fff736b21ed894083 - /dns4/star-signal.cloud.ipfs.team/tcp/443/wss/p2p-webrtc-star/ipfs/QmNe7SHzM2amR2xHPpvKTvD46mL9KHc7Qwf1D6T7jD4Dbg> },
  conn: 
   { source: { [Function: read] resolve: [Function], abort: [Function] },
     sink: { [Function: consume] start: [Function], ready: [Function], resolve: [Function] },
     resolve: [Function: resolve] },
  info: 
   Connection {
     peerInfo: null,
     conn: 
      { source: [Object],
        sink: [Object],
        resolve: [Function: resolve] },
     info: Connection { peerInfo: null, conn: [Object], info: [Object] } } }

However, when machine B tries to dial machine A, machine A doesn't receive a message and machine B's Connection object when it receives the dial from A looks like this:

{ handlerFunc: [Function], matchFunc: undefined }
Connection {
  peerInfo: null,
  conn:
   { source: { [Function: read] resolve: [Function], abort: [Function] },
     sink:
      { [Function: consume] start: [Function], ready: [Function], resolve: [Function] },
     resolve: [Function: resolve] },
  info:
   Connection {
     peerInfo: null,
     conn:
      { source: [Function],
        sink: [Function],
        resolve: [Function: resolve] },
     info:
      Connection { peerInfo: null, conn: [Object], info: [Connection] },
     setPeerInfo: [Function] } }

When I run this code on two VMs that aren't behind NAT, it works perfectly. How can I go about circumventing NAT to make this work? I thought that NAT traversal was built into the protocol.

[dryajov]

What you're describing should work. The public signaling server might currently be having issues (// cc @victorbjelkholm). Have you tried running your own public (as in not NATed) signaling server?

[owenauch]

I have not, I'll give that a shot and let you know what happens. Thanks!

[owenauch]

@dryajov So I just connected both peers to my own signaling server hosted in the cloud, and had the exact same issue (NAT peer can dial non-NAT peer, but not the other way around). Any thoughts? I am on public coffee shop wifi, but for my use case it would need to work for situations like this.

[owenauch]

@dryajov Wait false alarm, for some reason on further attempts it worked and calls could go through both ways! Thank you!

[owenauch]

Ok so the behavior seems to be really inconsistent. I tried it and both peers were able to dial one another seamlessly, but then after shutting both peers down and restarting them, neither could connect the next few times I tried. And then it worked again after a few tries inexplicably. Is there any reason for the inconsistency?

[dryajov]

This might be happening due to many different reasons, one might be that either of the nodes took longer to get connected to the rendezvous server. However, this still can be a legitimate issue, so lets keep an eye on it. If the issues persist, I suggest you create a new issues around it to track that behavior.