This isn't a Racket question per se, but I'm hoping someone here will have a suggestion. We're working on NAT traversal, it's failing to connect, and we aren't clear why.
On hostname Alice on the LAN: (define s (udp-open-socket)) (udp-bind! s #f 37777) (udp-send-to s "18.218.67.59" 54545 #"hi") Over on the EC2 instance at 18.218.67.59:54545: (define s (udp-open-socket)) (udp-bind! s #f 54545) (define buffer (make-bytes 50)) (udp-receive! s buffer) Bytes received: 2 Source IP: "76.127.206.145" Source port: 37777 This shouldn't be the case. Alice has a socket bound to 37777 on that local machine, but when the message is sent to the router, the router should choose a new external port number. That's what this particular router has done in the past and we aren't sure why that would have changed. Still, it wouldn't be an issue except that it's also not accepting traffic as expected. More on that below. This router uses (used to use, since everything is uncertain now) symmetric NAT, so it will only forward traffic from address X back to Alice if she had previously sent traffic to address X. (As opposed to, e.g. full cone NAT where any traffic arriving at the port would be forwarded and Alice could sort out what to do with it.) The problem is that traffic isn't being forwarded even when it should be. Demonstration follows, using Alice and Bob (two instances on our LAN) and the EC2 server from above. We are deliberately forcing everything to use the public IP instead of going across the local network. Alice and Bob hold a continuous connection to EC2 server. The router's IP is 76.127.206.145, which I'll type as R for convenience. R:47777 therefore means 76.127.206.145, port 47777. Alice -> server: I want to talk to Bob server -> Alice: He's connected to me from R:47777 Alice -> R:47777 ping [Router should note that Alice tried to talk to R:47777 and shoul start accepting traffic for her from that address. Message will not be received by Bob because he has not previously talked to Alice.] server -> Bob: Alice wants to talk to you. She's at R:37777 Bob -> R:37777 ping [Router should note that Bob tried to talk to R:37777 and should start accepting traffic for him from that address. Message should be received by Alice, since she already had the mapping set up to listen for Bob's messages] Alice -> R:47777 ping [Message should be received by Bob, since he was already listening for Alice] That's normal STUN-based NAT traversal, and we had it working until recently. Now it's failing and we're unsure what has changed that would affect it. Then we get to our next issue, which is that the router is not choosing different ports for outbound connections to different machines. In the past, what we've seen is this: On Alice: (define s (udp-open-socket)) (udp-bind! s #f 37777) (udp-send-to s "18.218.67.59" 54545 #"hi") ; EC2 server, instance #1 (udp-send-to s "18.218.67.59" 63212 #"hi") ; EC2 server, instance #2 The instance running at 54545 used to see the message as coming from an arbitrary remote port, e.g., 41378. The instance running at 63212 used to see the message as coming from a different remote port, e.g., 41379. Now, both instances see the message as coming from port 37777. When we were seeing different external ports we could use the difference between them to make a prediction about what our next outbound UDP port would be and leverage that into connecting despite having symmetric NATs at both ends of the connection (which STUN will not handle). Unfortunately, now both servers are reporting the same port number: 37777. To summarize, we have two separate issues that are probably related: 1) The router is re-using the local port as the external port 2) It's not accepting traffic from an address that has already been sent to from that port We're pretty stumped here and could use a hint. Anyone have thoughts on where to look? (udp-bind! s 37777) ( -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKoc28kfZAOo9TLmonTL8Go%2BBYbbBFBFMv5WW_uA7AP9pxQ%40mail.gmail.com.
