<div dir="auto">Can you draw gif file of the network diagram with IPs showing. You mentioned several real world IP addresses. This could help better understanding. <div dir="auto"><br></div><div dir="auto">Thanks.</div><div dir="auto"><br></div><div dir="auto">You can substitute real IP with something else if you want.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 5, 2021, 14:03 Neal Rhodes via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks. I forgot about NAT. So the RV180 is doing NAT on.. everything <br>
that goes out the WAN port? Which essentially means it changes the <br>
packet to say it's coming from its 50.248 address, but somehow remembers <br>
the local address to send the response.<br>
<br>
Would the RV180 be deciding NOT to do the NAT on something bound for <br>
10.1 address? Obviously the NAT is working for everything else.<br>
<br>
Maybe there is some packet capture on the Comcast router that will shed <br>
some light on that. (ultimately, it always comes back to printf's in <br>
the kernel...)<br>
<br>
<br>
On 2021-02-05 11:20, Derek Atkins wrote:<br>
> HI,<br>
> <br>
> Youre ascii art is hard to read, so I can't tell what's where.<br>
> But basically, no, what SHOULD be happening is that your RV180 would <br>
> NAT<br>
> your 192.168 network to its 50.248 address. then it will send a <br>
> request<br>
> to 10.1 -- the DPC3939 might not allow that.<br>
> <br>
> I think it very unlikely that the Comcast device is seeing the packet<br>
> coming from 192.168.<br>
> <br>
> More likely it's blocking access from the 50.248 to the 10.1 address.<br>
> <br>
> Here's something to try: Can you ADD a 10.1. address to the Comcast <br>
> side<br>
> of the RV180? In other words, let it have the 50.248 address as the<br>
> default address, but also add a static address of 10.1.10.X? And <br>
> ensure<br>
> it properly NAT's from 192.168 to 10.1.<br>
<br>
I only partially understand that. You are saying can I compel the <br>
Comcast router to add an additional 10.1 address it listens on? <br>
Unsure. And in fact would that address allow http login?<br>
<br>
<br>
> <br>
> -derek<br>
> <br>
> <br>
> On Fri, February 5, 2021 11:45 am, Neal Rhodes via Ale wrote:<br>
>> Our church has a Business Comcast DPC3939 connected to Our little <br>
>> Cisco<br>
>> RV 180 VPN.<br>
>> <br>
>> The Comcast has a local IP of 10.1.10.1, and the WAN Static Address of<br>
>> 50.248.230.105.<br>
>> <br>
>> Our Cisco router has a WAN address of 50.248.230.106, and it supports <br>
>> a<br>
>> 192.168.1.X network behind that, which is where everything on the LAN<br>
>> lives.<br>
>> <br>
>> INTERNET==>Comcast DPC3939 <===>Our Cisco RV180VPN<====Our 192.168.1.X<br>
>> LAN <==JackTrip Raspberry Pi Virtual Studio<br>
>> 50.248.230.105 <br>
>> 50.248.230.106<br>
>> <== <br>
>> Everything<br>
>> else on the LAN<br>
>> 10.1.10.1<br>
>> |== Ubuntu JackTrip Audio Server<br>
>> 10.1.10.91<br>
>> Port Forwarding 4464, UDP<br>
>> 61002-62000<br>
>> <br>
>> We really need to do a couple of things:<br>
>> - our office administrators need to occasionally be able to http <br>
>> access<br>
>> the Comcast router from our 192.168.1.X LAN. They cannot. Any <br>
>> attempt<br>
>> times out. (Fun fact: you CAN http to 50.248.230.105, and get a login<br>
>> response, BUT the correct userid/password will result in a Password<br>
>> failure. It only allows login from the 10.1.10.1 address.)<br>
>> - we need for ME to be able to occassionally get an ssh session from <br>
>> an<br>
>> office PC TO the Ubuntu server. Similar challenge I think.<br>
>> - The Raspberry Pi Virtual Studio box in the sanctuary needs to <br>
>> connect<br>
>> to the Ubuntu server on port 4464. I think it can hit the external<br>
>> address of the Comcast router for that. I've got that port <br>
>> forwarding<br>
>> all working now at home with a UVerse router.<br>
>> <br>
>> We can access the Comcast Router as <a href="http://10.1.10.1" rel="noreferrer noreferrer" target="_blank">http://10.1.10.1</a> IF we go <br>
>> downstairs<br>
>> to the furnace room and plug into the LAN ports on the DPC3939. The <br>
>> PC<br>
>> will then get a 10.1.10.X address.<br>
>> <br>
>> Now, when I look at the DPC3939, I see no evidence that it has a <br>
>> static<br>
>> route for our LAN. So, when someone on, say 192.168.1.145 puts<br>
>> 10.1.10.1 in their browser, the PC hands it to our Cisco router, it<br>
>> knows it's not on our LAN, so it hands it to its gateway: the DPC3939.<br>
>> <br>
>> And then I THINK the DPC3939 then says, "I don't know where to send<br>
>> 192.168.1.145" and so it times out.<br>
>> <br>
>> I THINK the Comcast router needs a static route that says 192.168.1.X <br>
>> is<br>
>> behind our Cisco router: 50.248.230.106.<br>
>> <br>
>> Am I thinking right? I don't mind stuffing in the route myself, but I<br>
>> asked Comcast first, since it's their equipment. Tier 1 said, "no<br>
>> that's not possible". Tier 3 response was:<br>
>> <br>
>> _1- you need to know, in order for two local networks to communicate<br>
>> they have to be in the same lan scheme, either both 192.168.x.x or<br>
>> 10.1.x.x_<br>
>> <br>
>> _2- My suggestion is to change the local IP scheme for Comcast<br>
>> modem/router to match the other router _<br>
>> _192.168.1.X_<br>
>> _ _<br>
>> _3- Make sure the IP scope of the modem is not conflicting with the<br>
>> other router._<br>
>> _ _<br>
>> _For example if the other router IP scope is from 192.168.1.1 to<br>
>> 192.168.1.100 then make the modem DHCP 192.168.1.101 to <br>
>> 192.168.1.200.<br>
>> Same lan scheme different IP scope to avoid future issues._<br>
>> <br>
>> The Tier 3 response sounds insane to me; if I'm on 192.168.1.145, and <br>
>> I<br>
>> want to send data to 192.168.1.4, my IP stack will just put it out on<br>
>> the LAN wire. The Comcast router is never going to see that, 'cause<br>
>> it's connected to the WAN port on our router. The only way my <br>
>> gateway<br>
>> would get involved is when a workstation knows that the destination is<br>
>> NOT on the local network, and hence the packet needs to get passed to<br>
>> the gateway. The Tier 3 response also seems to open up all kinds of<br>
>> security issues if it in fact worked; then a compromise to anything on<br>
>> the Comcast side could easily bleed into our LAN.<br>
>> <br>
>> What is kinda weird to me is that at home this "just works". I have <br>
>> an<br>
>> AT&T Uverse router which provides 192.168.1.X. I have a Sonicwall VPN<br>
>> router plugged into that, which provides a LAN of 192.168.100.X. The<br>
>> linux and PC devices are on the 100.X network. There are a few<br>
>> expendable devices and IOT on the 1.1 network. I can ssh and http<br>
>> from the 100.1 network to hosts on the 1.1 network; but of course they<br>
>> cannot go the other way. I didn't do anything for this to happen.<br>
>> Did the routers exchange BGP and just figure that out?<br>
>> <br>
>> Regards,<br>
>> <br>
>> Neal Rhodes_______________________________________________<br>
>> Ale mailing list<br>
>> <a href="mailto:Ale@ale.org" target="_blank" rel="noreferrer">Ale@ale.org</a><br>
>> <a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
>> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
>> <a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
>> <br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank" rel="noreferrer">Ale@ale.org</a><br>
<a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>