--- Tracing route to S0106a4badb14c311.gv.shawcable.net...

[mdk]

@ksihota --- 

Tracing route to S0106a4badb14c311.gv.shawcable.net [24.108.193.xxx]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms box.local [10.10.10.1]
2 11 ms 10 ms 119 ms 24.108.192.1
3 22 ms 22 ms 24 ms S0106a4badb14c311.gv.shawcable.net

About: S0106e8447e03f0e8.gv.shawcable.net

About: S0106a4badb14c311.gv.shawcable.net

Every DNS-name assigned by Shaw starts with "S0106".

Every DELL networking adapter has a MAC-address starting with "A4:BA:DB" -- see: https://maclookup.app/search/result?mac=a4badb14c311

Every BITDEFENDER networking adapter has a MAC-address starting with "E8:44:70"

The trace shows:

#1 - your computer connecting to a LAN port on your DELL router

#2 - through the "LAN" side of your DELL router to the "WAN" port on your DELL router, connecting to a LAN port on a Shaw router, in Shaw's offices. Those routers tend to have IP-addresses ending with ".1".

#3 - connection from that SHAW router to the "public" IP-address assigned to BITDEFENDER router.

So far, so good.

When I tried the server domain name instead of IP address I kept getting time outs but noticed that the IP address for the server was wrong. I checked back later and then it went through properly and the IP address for the server was correct. Obviously a DNS updating issue there. Times were about the same.

Yes, any DNS-server responds with both an IP-address and a TTL-value ("time to live"). Compare to leasing a hotel room. You pay for NN nights, and the hotel expects you to stop using the room after the end of the lease.

The TTL-value indicates for how long that the response from the DNS-server can be "trusted" -- no need to ask the DNS-server again, until the "cached" result expires from the requestor's "cache" of results from the DNS-server.

So, the "correctness" of the IP-address depends on the DNS-server handing-out a "short" (15 minutes? 1 hour?) lease for the IP-address that it supplies.   What software are you using to update the DNS-server, and how often does that "updater" run?

Maybe its a DNS issue but I can't see why the direct IP address connection wouldn't work or why I can access from outside my home or by using a VPN. From what I can see, it appears as if the modem is the issue

It should work, if the IP-address currently handed-out by the domain's DNS-server is the current IP-address (assigned by Shaw) to your routers.  Your trace-output shows that the Shaw router (ending with ".1") is correctly routing packets that it receives to your routers.

The following results, for both your IP-addresses, seem to be "normal":

Tracing route to S0106a4badb14c311.gv.shawcable.net [24.108.193.30]

1 1 ms 1 ms 1 ms hitronhub.home [192.168.0.1]
2 13 ms 10 ms 18 ms 70.67.224.1
3 35 ms 11 ms 9 ms rd1cv-be122-1.gv.shawcable.net [64.59.161.249]
4 11 ms 10 ms 13 ms dx8so-la0-s1.gv.int.shawcable.net [64.59.161.218]
5 34 ms 21 ms 18 ms S0106a4badb14c311.gv.shawcable.net [24.108.193.30]

Trace complete.

Tracing route to S0106e8447e03f0e8.gv.shawcable.net [24.108.196.33]
1 1 ms 1 ms 1 ms hitronhub.home [192.168.0.1]
2 11 ms 10 ms 11 ms 70.67.224.1
3 9 ms 10 ms 9 ms rd1cv-be122-1.gv.shawcable.net [64.59.161.249]
4 10 ms 10 ms 12 ms dx8so-la0-s1.gv.int.shawcable.net [64.59.161.218]
5 23 ms * 16 ms S0106e8447e03f0e8.gv.shawcable.net [24.108.196.33]

Trace complete.

For both IP-addresses, the first 4 "hops" are identical, as expected.

So, the only issue is that the DNS-server for your domain is either not getting frequently updated, or the TTL-value is too long -- it should be shortened to 60 seconds, so that any DNS-update is "immediately" available to the next computer to make a DNS-query.

[ksihota]

Thanks for the info, I'll have to look more closely at all this when I get some time. I have a script on my server that checks the IP address every 5 mins or so (Its been a while since I put it together so I'm not sure of the timing) and if there has been a change it changes the DNS settings on ENOMS servers where it is registered. It has been working fine for several years and usually my IP address only changes after a power outage where my server has been offline for some time.
I can also manually change the IP address on ENOM but it is just easier to let the script take care of it.
From what I can tell, it really shouldn't be a DNS problem as I can easilly access the server from outside my home using the domain name or by using a VPN from home. Its just accessing the server when I am using the one Shaw IP to go out and the other to go back into the server. I would expect that they would act as totally unique entities. Out from one IP to the Shaw centre and then back in on the other, However its more like there is a traffic jam at the modem which is slowing down any throughput when there shouldn't be.
What is more confusing is why it suddenly started working properly last year and worked for a year and now its back to the same issues. Like I said, I can work around it by using my VPN but it would be nice to understand why the bottleneck is occurring.

[rstra]

@ksihota 

Rogers customers complaining that NAT loopback stopped working on their XB6 modems about a month ago. I can DM the link if you want.

[ksihota]

Sure.

Does my issue sound like a NAT loopback problem?

[mdk]

@ksihota -- I have a script on my server that checks the IP address every 5 mins or so (Its been a while since I put it together so I'm not sure of the timing) 

You mentioned "timing". That may be significant. Each IP-address that ENOM hands-out to any DNS-request includes a "TTL" -- time-to-live -- that specifies how long that the IP-address can be trusted to be correct & active.

So, if your computer receives the response from ENOM's DHCP server, it does not need to contact that server until the "TTL" expires.  So, if the value of the TTL is "large", then your computer will not send another DHCP-query to ENOM for a "long" time -- even though the "new" IP-address is being stored by ENOM.

Example of output from: IPCONIG /DisplayDNS

www.comics.com
----------------------------------------
Record Name . . . . . : www.comics.com
Record Type . . . . . : 5
Time To Live . . . . : 76667
Data Length . . . . . : 8
Section . . . . . . . : Answer
CNAME Record . . . . : comics.com

So, "76667" means the IP-address for the domain will not change for about 21.9 hours. The TTL probably started at 24 hours, and I accessed that domain about 2.1 hours ago. 

Since it is "May The Force" day, I looked at: https://www.gocomics.com/theargylesweater/2022/05/04 

which is a strip with the (required?) Star Wars theme.

So, check the TTL that you get in the DHCP-response.  Maybe, have your script apply a "small" value.

[ksihota]

Thanks for the idea. I checked my settings and they all look good. Your idea did make me notice an error in one of my settings that had one of my virtual servers using a totally wrong IP address (hadn't updated to the server's) but luckily it was just a test site.
The script doesn't really do anything except notify enom that the ip address associated with my domain name has changed when I get a new one from Shaw.

However, I still can't see why the problem would be DNS since I can't use the IP address to access the site from within my home as well. If I use a VPN and provide the IP address or the Domain name the server connects just fine, or if I use any outside IP to access the server it works fine using IP or Domain name.
Its like shaw's dynamic ips won't talk to each other if they are connected to the same modem.

At least using the VPN it works fine.

[mdk]

@ksihota -- If I use a VPN and provide the IP address or the Domain name the server connects just fine, or if I use any outside IP to access the server it works fine ...

Yes, when connecting to a VPN-server, the VPN-server has an IP-address that is "somewhere" out on the Internet, just the same as when you use any other "outside" IP-address. 

>  I still can't see why the problem would be DNS since I can't use the IP address to access the site from within my home as well.

Given that information, I don't think that it is a DNS problem, if the DNS-server for your domain is returning the current IP-address of your router (which passes-through the packets to your server).

On one computer connected to your router, enter the command: nslookup -debug www.example.com.

(replacing 'example.com' by your domain-name)

to get output like:

------------
QUESTIONS:
www.example.com, type = A, class = IN

ANSWERS:
-> www.example.com
internet address = 93.184.216.34
ttl = 65795 (18 hours 16 mins 35 secs)

and confirm that the IP-address is what you expect, and that the TTL is "short", because a "short" TTL means that when your script changes the IP-address, the change is quickly noticed. A "long" TTL means that any computer that previously queried the DNS-server will have "cached" the result (the IP-address) for, in this case, over 18 hours, and will not issue another query to the DNS-server for a long time.

[ksihota]

Using the VPN (on) and running the nslookup on my laptop I get this:

Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, want recursion
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
8.8.8.8.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 8.8.8.8.in-addr.arpa
name = dns.google
ttl = 3160 (52 mins 40 secs)

------------
Server: dns.google
Address: 8.8.8.8

------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
Myserver_domain.local, type = A, class = IN
ANSWERS:
-> Myserver_domain.local
internet address = 100.96.41.28
ttl = 15 (15 secs)

------------
Non-authoritative answer:
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
Myserver_domain.local, type = AAAA, class = IN

------------
Name: Myserver_domain.local
Address: 100.96.41.28

I have no idea where this IP address is coming from.
When I run the same nslookup with the VPN off I get this:

------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0

QUESTIONS:
1.10.10.10.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 1.10.10.10.in-addr.arpa
name = box.local
ttl = 0 (0 secs)

------------
Server: box.local
Address: 10.10.10.1

------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0

QUESTIONS:
Myserver_domain.local, type = A, class = IN

------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0

QUESTIONS:
Myserver_domain.local, type = AAAA, class = IN

------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0

QUESTIONS:
Myserver_domain, type = A, class = IN
ANSWERS:
-> Myserver_domain
internet address = 24.108.193.XX
ttl = 1738 (28 mins 58 secs)

------------
Non-authoritative answer:
------------
Got answer:
HEADER:
opcode = QUERY, id = 5, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:
Myserver_domain, type = AAAA, class = IN
AUTHORITY RECORDS:
-> Myserver_domain
ttl = 3600 (1 hour)
primary name server = dns1.name-services.com
responsible mail addr = info.name-services.com
serial = 1651423881
refresh = 172800 (2 days)
retry = 900 (15 mins)
expire = 1814400 (21 days)
default TTL = 3600 (1 hour)

------------
Name: Myserver_domain
Address: 24.108.193.xx

The IP address is correct in this scenario (No VPN.) This makes even less sense to me than before. Wrong IP reported for the server when accessed through the VPN but the connection works. Correct IP address reported without the VPN but the connection doesn't work.

Is this that NAT Loopback issue? Is the Modem considering both IPs that I have as being on the same LAN or is it the router in Shaw's setup that is doing it? I would have thought that both IPs I get from Shaw would be considered individual and separate for routing purposes. It appears that the modem is causing a bottleneck or one of Shaws routers. Can I alter the modem's settings to allow this to work the way I would expect or is it a device in Shaw's centre that has to do this?