I am not sure if I should be asking this in Unix & Linux or Network Engineering

Here is the physical scenario

[Host 1]----[Carrier-grade NAT]---->AWS<----[Carrier-grade NAT]----[Host 2]

Host 1 and Host 2 are reverse ssh'ed (autossh) into an AWS Box, so they do have shell connectivity if required, and possibility to expose any other port if required.

Host 2 pushes backup dumps to Host 1 using SCP on regular basis. There are actually Host2 X 10 boxes pushing the data dumps. Nearest AWS location is quite far from the location of boxes so latency is quite a lot.

Is there a possibility to use the AWS box as a rendezvous point to broker a ssh tunnel between the boxes? I am aware about the IPv6 tunnel brokers but the ISPs in the region are yet to adopt it (20 years late... duh!) I am exploring a solution bases on:

  • TCP / UDP hole punching (with practical implementation)
  • UPnP / NAT-PMP service on AWS
  • Using tools such as Chrome Remote Desktop, hack it to expose SSH port rather then VNC
  • Any other router service.
  • Any other practical approach.

Boxes are running CentOS 6/7 mostly.

  • Is setting up a VPN on AWS instance a viable option? – sebasth Nov 19 '17 at 16:31
  • Not in this specific case, the latency issue. Also the direct connection (once brokered) will help keeping AWS bills in check. – user1263746 Nov 19 '17 at 16:37
  • 2
    I don't see why you need a regional IPv6 broker. I use one that's based out of the US (not my country). As long as your IPv6-in-IPv4 traffic isn't blocked I don't see the problem. I'll make this an answer if it helps you. – roaima Nov 19 '17 at 19:55
  • 2
    For TCP hole punching: you should gather more informations on how your CGN is working. Perhaps by comparing with multiple tests the SSH source port seen on host1 then same source seen on aws. Do they differ?. Same for the ssh source port seen on host2 then on aws. Doing tests with a 2nd "broker" IP would be preferable too. If they differ and you can't find an algorithm able to predict what it will become, I don't see what to do. If you can find or they don't differ, then maybe its possible (TCP allows handshakes initiated with a simultaneous SYN/SYN instead of the usual SYN/SYN+ACK/...) – A.B Nov 20 '17 at 1:40
  • 1
    you surely can use socat (not netcat) to punch the hole, then connect ssh to it (to localhost). eg: on one side (the "server" side, so host1) : socat TCP4-CONNECT:cgnatedhost2:cgnatedport2,bind=outgoingip1:outgoingport1 TCP4-CONNECT:localhost:22 on the "client" side socat TCP4-CONNECT:cgnatedhost1:cgnatedport1,bind=outgoingip2:outgoingport2 TCP4-LISTEN:2222 and on the "client" you'd connect with ssh -p 2222 user1@localhost (and if the port 2222 is never used for something else, modern ssh will remember the correct remote hostid, so no need for NoHostAuthenticationForLocalhost) – A.B Nov 29 '17 at 0:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.