On 2024-01-01 Kevin McGregor wrote:
I ran a traceroute from site B to google.ca: 1 <1 ms <1 ms <1 ms router.home [192.168.1.1] 2 10 ms 8 ms 8 ms 50.71.160.1
From site A to site B, the traceroute shows: 1 3 ms 3 ms 2 ms 192.168.1.1 2 7 ms 5 ms 6 ms 10.0.0.1 <site A is double-NATted :-(
3 15 ms 16 ms 17 ms 50.71.160.1
If B-out and A-out share 50.71.160.1 along the way then why isn't 50.71.160.1 just directly routing between A & B? Unless I'm missing something, or your labeling of which box is doing what is wrong? Weird.
12 50 ms 46 ms 47 ms <WAN IP of site B (104.159.x.y)> 13 79 ms 78 ms 98 ms <WAN IP of site B, again> 14 * * * Request timed out.
Maybe the tr thinks it can get farther... mtr might give you different results. Sometimes they have to do some guessing and it's all based on TTL tricks and not entirely reliable. It is normal for some hops to not respond, for various reasons. I wouldn't read too much into it.
In fact, you must be wrong on your labeling because you said:
"
From site A to site B, the traceroute shows:
1 3 ms 3 ms 2 ms 192.168.1.1 2 7 ms 5 ms 6 ms 10.0.0.1 <site A is double-NATted "
Yet you've told us you (Kevin) are site A on Shaw and certainly you are not double-NATted? Isn't the problem that the freaky Telus side is doing wacky double-NAT stuff?
In any event, it will be nigh impossible to do anything without the double-NATted side initiating the connections, especially when you don't control a level of the NAT.
So any solution will require you to initiate connections on the silly (Telus) side into the "good" (Shaw) side. If you need it the other way, you'll have to still do it this way and then utilize the connection in reverse.
But I think you've already indicated previously that you're doing that...? So then the only problem becomes a) what ports are the 2 (3? 4?) ISPs blocking, and making sure your "good" side really is port-forwarding properly. If you have access to another remote box that is not NATted, or single-NATed, and has known port-blocking policies, get the solution working on that first, then worry about making it work with the silly connection. That way you know what hop to blame and can try alternative ideas (ports and technologies).
If I were you I'd get rid of the canned router on your end (I'm making assumptions here) and make your own router/firewall, as part of your main linux box or a little extra box in a closet, and then get your ISP to "direct" connect you so you have an external IP, and 100% complete control of at least 1 side of the equation. The best part of that is then you can do packet logs at the lowest level to see where things are falling apart... if you could do that on your canned router right now you'd probably solve this in 5 minutes. And then there should be nothing you cannot achieve.
Then I'd look at doing an always-on linux strongswan ipsec vpn between the 2 boxes so they can talk to each other like they are on the same LAN, even if you're just going to run ssh between them (and you can use firewall rules to limit what can be done). Because of everyone's remote work from home stuff these days there is no ISP that can block VPNs. YMMV and that's just me. Everyone has their own favorite.
Too bad we can't easily replicate your setups to try some things out... I guess I could try to hookup my laptop to my cell as a hotspot and thus should be able to become double-NATted? However, that might be even more portblock-happy than your home-use cell provider example.
Last thing: if you're trying to do ssh for all of this, can the silly host ssh into somewhere (else) external on port 22? If it can't do that, then 22 is blocked on the silly side and you can't use that with finding an open port they don't block.