Skip to content
This repository has been archived by the owner on Apr 24, 2023. It is now read-only.

Listening for calls behind NAT #152

Open
owenauch opened this issue Jul 2, 2018 · 6 comments
Open

Listening for calls behind NAT #152

owenauch opened this issue Jul 2, 2018 · 6 comments
Labels
kind/support A question or request for support status/ready Ready to be worked

Comments

@owenauch
Copy link

owenauch commented Jul 2, 2018

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
Copy link
Member

dryajov commented Jul 3, 2018

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
Copy link
Author

owenauch commented Jul 3, 2018

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

@owenauch
Copy link
Author

owenauch commented Jul 3, 2018

@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
Copy link
Author

owenauch commented Jul 3, 2018

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

@owenauch owenauch closed this as completed Jul 3, 2018
@owenauch owenauch reopened this Jul 3, 2018
@owenauch
Copy link
Author

owenauch commented Jul 3, 2018

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
Copy link
Member

dryajov commented Jul 3, 2018

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.

@vasco-santos vasco-santos added the kind/support A question or request for support label Jul 22, 2018
@daviddias daviddias added the status/ready Ready to be worked label Aug 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/support A question or request for support status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

4 participants