SSH Tunnel broker over IPV4 for machines behind CNAT

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite
1












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.







share|improve this question






















  • 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














up vote
1
down vote

favorite
1












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.







share|improve this question






















  • 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












up vote
1
down vote

favorite
1









up vote
1
down vote

favorite
1






1





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.







share|improve this question














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.









share|improve this question













share|improve this question




share|improve this question








edited Nov 19 '17 at 18:49

























asked Nov 19 '17 at 16:10









user1263746

1993516




1993516











  • 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
















  • 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















Is setting up a VPN on AWS instance a viable option?
– sebasth
Nov 19 '17 at 16:31




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




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




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




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




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





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




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




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















active

oldest

votes











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405616%2fssh-tunnel-broker-over-ipv4-for-machines-behind-cnat%23new-answer', 'question_page');

);

Post as a guest



































active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405616%2fssh-tunnel-broker-over-ipv4-for-machines-behind-cnat%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?