[RndTbl] Problems with setting up off-site backup via Shaw (residential)

[Trevor Cordes]

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.