[BALUG-Admin] (forw) Re: Comcast Business apparently blocking 5353 UDP Re: linuxmafia.com "retry limit exceeded"

Wed Jun 5 04:40:44 UTC 2024

Gateway > Connection > Comcast Network
WAN IP Address (IPv4): 73.189.65.18
WAN Static IP Address (IPv4): 96.86.170.230
WAN Default Gateway Address (IPv4): 73.189.64.1
WAN IP Address (IPv6): 2001:558:6045:b3:9887:23a:a685:f346
WAN Default Gateway Address (IPv6): fe80::201:5cff:fea
Thanks ... well, that at least does eliminate a bit of guesswork
as to what/where that/those IPs are.
And as for what NAT uses ... have to check from relevant client IP ...
https://www.wiki.balug.org/wiki/doku.php?id=system:what_is_my_ip_address
So, behind Comcast's NAT on the "modem"/router ...
$ ip -4 a s | sed -ne '/inet/!d;/inet 127\./!p'; curl -s https://ip4only.me/api/
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
IPv4,96.86.170.230,v1.1,,,See http://ip6.me/docs/ for api documentation
$
Or from another such client host, and preceding with a check that doesn't
traverse NAT/SNAT to see the IPv4 IP on my external interface ...:
$ ssh -q myip@10.1.10.2
10.1.10.142
$ curl -s https://ip4only.me/api/
IPv4,96.86.170.230,v1.1,,,See http://ip6.me/docs/ for api documentation
$
So, not too surprisingly, it uses the 96.86.170.230 IP, that's IP of
router/gateway itself,
static, and in all cases, relevant return traffic would need come to
or via that IP anyway.
So, no big surprises there.  For IPv4, probably the only logical possibilities
open to Comcast without consuming more IPv4 IPs (a precious resource)
would be: 73.189.65.18
as that's the IP on WAN side ... but that wouldn't work as efficiently for
communicating with the rest of
96.86.170.224/29
So probably simpler for them to use 96.86.170.230 ...
or it might even be a limitation of their "router"/"modem" software/firmware
and its NAT/SNAT capabilities, on where it can do that.
And, also easier and more consistent, e.g. when I'm
doing stuff on firewall(s) elsewhere and whitelisting my "home"
IPv4 sources, I'll typically just whitelist 96.86.170.224/29
and that covers all the possibilities IPv4-wise that I'd be originating
out to The Internet on globally routable IP addresses.

On Tue, Jun 4, 2024 at 8:09 PM Al <awbalug@sunnyside.com> wrote:
>
> Your mdem's web page will tell you what the modem's WAN address is.
> Gateway > Connection > Comcast Network should show
> WAN IP Address (IPv4):98.45.214.155 (Ok, the IP is on my modem, but supposedly the 73.thing will be on yours)
> It will certainly be interesting if it isn't the 73.whatever
> NAT normally uses the 96.86.170.230 address (in your case) but in some cases I believe it sometimes uses the WAN address.  I don't have it right in front of me, and it's been a while, so I can't back it up, and maybe I'm wrong but I'm pretty sure I've seen that.
> Why 5353? is a whole other speculation exercise.
>
> On 6/4/2024 19:59, Michael Paoli wrote:
>
> No NAT/SNAT for my* 96.86.170.224/29
> *well, 5 of those are "mine", and 3 Comcast's:
> 96.86.170.224 network (Comcast's)
> 96.86.170.225 ("mine")
> 96.86.170.226 www.mpaoli.net., tigger.mpaoli.net, ... ("mine")
> 96.86.170.227 ("mine")
> 96.86.170.228 ("mine")
> 96.86.170.229 balug.org, etc. ("mine")
> 96.86.170.230 gateway/router (Comcast's)
> 96.86.170.231 broadcast (Comcast's)
> So, 73.189.65.18 is likely Comcast's WAN side.
> Though at moment, next to last hop I see ...
> 68.85.103.154
> ... but I did that from Rick's, so ... probably different routing from
> Comcast Business to Comcast Business,
> vs., e.g. from AT&T to Comcast.
> And ... minutes later I try and see next to last of:
> 73.189.65.18 (to balug.org., but same target subnet)
> So, likely they've got load balancing / failover in their routing too.
>
> On Tue, Jun 4, 2024 at 5:48 PM Al <awbalug@sunnyside.com> wrote:
>
> Actually I take it back, 73.189.65.18 must be the WAN address of
> Michael's modem.  That won't appear on a message from Michael, unless
> somehow NAT got involved in the modem?  Not sure if that's quite right.
> I think NAT would come from the last of the assigned static IPv4
> addresses, but IIRC I have also seen messages from a modem's WAN address.
>
> Most interesting.
>
> On 6/4/2024 17:43, Al wrote:
>
> I think "c-73-189-65-18.hsd1.ca.comcast.net" is their naming system
> for end modems, not internal infrastructure, but don't quote me.
> When I look up the names of routers in the traceroute I don't think I
> see that type of name, but it may be that's an irresponsible poorly
> verified comment on my part.
>
>
> For example from traceroute to Michael:
> 186.78.151.162.in-addr.arpa domain name pointer
> po-1-rur101.pinole.ca.sfba.comcast.net.
>
> ooooooooooooooh, omigosh - I just perfected a traceroute to Michael,
> entirely within the CC network:
>
> traceroute to 96.86.170.229 (96.86.170.229), 30 hops max, 60 byte packets
>  1  50.242.105.62  2.080 ms  2.743 ms  3.439 ms
>  2  10.61.209.66  14.028 ms 10.61.209.67  13.729 ms 10.61.209.66
> 14.373 ms
>  3  96.216.9.141  12.757 ms 96.216.9.137  13.045 ms 96.216.9.141
> 13.401 ms
>  4  68.85.154.113  21.023 ms 68.85.154.117  21.093 ms 68.85.154.113
> 20.944 ms
>  5  96.108.99.249  26.011 ms  25.722 ms  26.272 ms
>  6  68.86.143.89  23.688 ms 68.86.143.93  21.156 ms  20.778 ms
>  7  162.151.86.58  22.077 ms  20.330 ms 162.151.87.226  20.215 ms
>  8  162.151.79.134  21.787 ms 162.151.78.186  17.686 ms
> 162.151.79.134  21.466 ms
>  9  68.85.103.154  19.388 ms 68.85.191.206  12.456 ms 68.85.103.154
> 14.255 ms
> 10  73.189.65.18  21.185 ms  36.832 ms  31.356 ms
> 11  96.86.170.229  36.366 ms  34.933 ms  34.918 ms
> root@routr0:/z/r/srv#
>
> It appears that 73.thing is in fact Michael's upstream router.
>
> Ok, did everyone else already know that?  Am I late to the party?
>
>
> On 6/4/2024 17:14, Rick Moen wrote:
>
> ----- Forwarded message from Al <awbalug@sunnyside.com> -----
>
> Date: Tue, 4 Jun 2024 16:29:04 -0700
> From: Al <awbalug@sunnyside.com>
> To: Rick Moen <rick@linuxmafia.com>
> Subject: Re: [BALUG-Admin] Comcast Business apparently blocking 5353
> UDP Re:
>     linuxmafia.com "retry limit exceeded"
>
> Rick, you're at the right place - that gear icon and right side panel
> on business.comcast.com is just the right thing.
> And I think the situation as you're outlining it is right to me.  So
> the answer to your question, broadly, is yes I think you have it
> right.
> If you end up at securityedge.comcast.com, IMHO you've gone too far.
> My sense is that all that stuff is disabled back at the right side
> panel...
> Once SE (security edge) is disabled I think everything is.  That
> said, you're being smart about it - if symptoms persist, drill down
> and look into individual
> settings for various elements of SE and just make sure they're all off
> - in case Comcast can't quite sort out how to actually disable stuff.
> AFAIK however your nets (yours and Michaels) are unrestricted.
> My tests from here are that access to both 96.86.170.229 and
> 96.95.217.99 on port 53 is not blocked (and not just those /32s but
> the entire subnet in each case).
> I am looking back over email from the last few days trying to sort out
> where 73.189.65.18 crept into the conversation.
> As I mentioned I have been unable to focus sufficiently on this the
> last few days, and missed where that came from.
> I also haven't looked closely enough at the discussion to see if what
> I am trying to reproduce isn't exactly where you're having trouble.
> I'll go back over the notes and see if I can pay more attention to the
> details and whether I can actually add any insight to the discussion.
> Al
>
> ----- End forwarded message -----
>
>
> To clarify, I noticed "73.189.65.18" as the source of NOTIFYs for
> Michael's domains, which can legitimately come _only_ from Michael's
> authoritative nameserver, IP 96.86.170.229.
>
> And 73.189.65.18 is Comcast's _own_ IP, not Michael's.
>
> :r! dig -x 73.189.65.18 +short
> c-73-189-65-18.hsd1.ca.comcast.net.
>
> So, something is rotten, there.  I'm immediately inclined to suspect
> that Comcast is playing man-in-the-middle games with DNS traffic.
> Which, if true, suggest Comcast acting like a rogue state security
> agency or one operating on behalf of a totalitarian state.  Not a good
> look.
>
>
>
> _______________________________________________
> BALUG-Admin mailing list
> BALUG-Admin@lists.balug.org
> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin
>
> _______________________________________________
> BALUG-Admin mailing list
> BALUG-Admin@lists.balug.org
> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin
>
> _______________________________________________
> BALUG-Admin mailing list
> BALUG-Admin@lists.balug.org
> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin
>
>
> _______________________________________________
> BALUG-Admin mailing list
> BALUG-Admin@lists.balug.org
> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin