[ale] 10.1.10.1 Comcast access from local LAN? (Slightly OT BUT there is Ubuntu AND PI involved!)
neal at mnopltd.com
neal at mnopltd.com
Fri Feb 5 11:45:28 EST 2021
Our church has a Business Comcast DPC3939 connected to Our little Cisco
RV 180 VPN.
The Comcast has a local IP of 10.1.10.1, and the WAN Static Address of
50.248.230.105.
Our Cisco router has a WAN address of 50.248.230.106, and it supports a
192.168.1.X network behind that, which is where everything on the LAN
lives.
INTERNET==>Comcast DPC3939 <===>Our Cisco RV180VPN<====Our 192.168.1.X
LAN <==JackTrip Raspberry Pi Virtual Studio
50.248.230.105 50.248.230.106
<== Everything
else on the LAN
10.1.10.1
|== Ubuntu JackTrip Audio Server
10.1.10.91
Port Forwarding 4464, UDP
61002-62000
We really need to do a couple of things:
- our office administrators need to occasionally be able to http access
the Comcast router from our 192.168.1.X LAN. They cannot. Any attempt
times out. (Fun fact: you CAN http to 50.248.230.105, and get a login
response, BUT the correct userid/password will result in a Password
failure. It only allows login from the 10.1.10.1 address.)
- we need for ME to be able to occassionally get an ssh session from an
office PC TO the Ubuntu server. Similar challenge I think.
- The Raspberry Pi Virtual Studio box in the sanctuary needs to connect
to the Ubuntu server on port 4464. I think it can hit the external
address of the Comcast router for that. I've got that port forwarding
all working now at home with a UVerse router.
We can access the Comcast Router as http://10.1.10.1 IF we go downstairs
to the furnace room and plug into the LAN ports on the DPC3939. The PC
will then get a 10.1.10.X address.
Now, when I look at the DPC3939, I see no evidence that it has a static
route for our LAN. So, when someone on, say 192.168.1.145 puts
10.1.10.1 in their browser, the PC hands it to our Cisco router, it
knows it's not on our LAN, so it hands it to its gateway: the DPC3939.
And then I THINK the DPC3939 then says, "I don't know where to send
192.168.1.145" and so it times out.
I THINK the Comcast router needs a static route that says 192.168.1.X is
behind our Cisco router: 50.248.230.106.
Am I thinking right? I don't mind stuffing in the route myself, but I
asked Comcast first, since it's their equipment. Tier 1 said, "no
that's not possible". Tier 3 response was:
_1- you need to know, in order for two local networks to communicate
they have to be in the same lan scheme, either both 192.168.x.x or
10.1.x.x_
_2- My suggestion is to change the local IP scheme for Comcast
modem/router to match the other router _
_192.168.1.X_
_ _
_3- Make sure the IP scope of the modem is not conflicting with the
other router._
_ _
_For example if the other router IP scope is from 192.168.1.1 to
192.168.1.100 then make the modem DHCP 192.168.1.101 to 192.168.1.200.
Same lan scheme different IP scope to avoid future issues._
The Tier 3 response sounds insane to me; if I'm on 192.168.1.145, and I
want to send data to 192.168.1.4, my IP stack will just put it out on
the LAN wire. The Comcast router is never going to see that, 'cause
it's connected to the WAN port on our router. The only way my gateway
would get involved is when a workstation knows that the destination is
NOT on the local network, and hence the packet needs to get passed to
the gateway. The Tier 3 response also seems to open up all kinds of
security issues if it in fact worked; then a compromise to anything on
the Comcast side could easily bleed into our LAN.
What is kinda weird to me is that at home this "just works". I have an
AT&T Uverse router which provides 192.168.1.X. I have a Sonicwall VPN
router plugged into that, which provides a LAN of 192.168.100.X. The
linux and PC devices are on the 100.X network. There are a few
expendable devices and IOT on the 1.1 network. I can ssh and http
from the 100.1 network to hosts on the 1.1 network; but of course they
cannot go the other way. I didn't do anything for this to happen.
Did the routers exchange BGP and just figure that out?
Regards,
Neal Rhodes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210205/848a7ee2/attachment.html>
More information about the Ale
mailing list