OpenDNS has raised a TCP/IP question
OpenDNS has raised a TCP/IP question
Scenario: to use openDNS web filtering requires input of DNS into the WAN settings of the modem- but the issued Telstra (Australia) modem/routers have their WAN settings disabled in firmware. Solution: - use another router.
Complication: for end user (not me) simplicity I don't want to replace the OEM modem/router - this way if there are internet supply problems then users can *easily* default back to their original set-up.
**** I know it will work by replacing with a new modem/router but this IS NOT an answer to my questions ****
So I'm using a second router (a Dlink DIR-826L that was sitting around for something else...it was dirt cheap!) but I can't bridge the first (firmware wont let me) nor can I simply use the second router as a repeater because I need to enter different DNS settings.
As I need two routers I had the light-bulb idea of using the OEM router for my computers & devices (no openDNS) and then using the second router (with openDNS) for the rug-rats. Brilliant, but it's not quite working - 80%. So far my best solution is the pretty standard set-up of:
Subnet: 255.255.255.0 (can only change last octet)
DHCP Server 192.168.0.2-62 (again can only change the last octets)
Set DHCP reservation lease for DIR-826L MAC = 192.168.0.4 = OK
Router IP: 192.168.1.1
Subnet Mask: 255.255.255.0
Internet Connection setup works with either Static IP (192.168.0.4) or Dynamic IP.
Everything works, except:
1. I can't get access to DIR-826L connected devices from CGD24N connected devices. Can ping 192.168.0.4 from CGD24N but nothing else(extending DHCP range makes no difference)
2. Can ping everything from the DIR-826L router, and whilst DIR-826L connected devices (eg iPhone) can browse or have network access to CGD24N connected devices (eg Seagate NAS) unfortunately most apps (eg. phone backup) wont let two devices connect unless they are connected to the same router. Or perhaps need the routers connected differently.
I've turned off all firewalls and even tried putting the 192.168.0.4 IP into the DMZ of the CGD24N router.
**** I know everything will work if all devices connect directly to the DIR-826L - but that IS NOT MY QUESTION!! ****
I have been trying to get my head around subnets & subnet masks, and from what I have read there should be a way to communicate in both directions. My noob logic suggests to me the problem is because the two routers are in different subnets (192.168.0.1 & 192.168.1.1) but whenever I set up the DIR-826L with the same subnet (eg. router IP: 192.168.0.64) I get stuck. Even when trying subnet masks the problem is I can't get any internet access through to the DIR-826L using Dynamic IP Internet Connection settings - but I can't use static IP as the router then tells me I have a subnet conflict between the LAN & Internet Connection settings (which I do). Different subnet masks make no difference either. I have wondered if this is possibly a PORT issue but again I don't want to change the default set-up of the CGD24N router.
I realise this two-direction communication may not be possible, but I've got to the point where even if I *did* get it working I wouldn't actually know why, so.....
Q1. From a TCP/IP perspective, why is the communication one-way but not the other?
Q2. Is it a hardware limitation of the DIR-826L or CGD24N routers? Not really a TCP/IP question I know....
Q3. Is it possible to have two-way communication between the routers with this hardware set-up, and if so what is the TCP/IP set-up? A NO is fine BTW
Q4. If not, what extra hardware would I need and what would be the TCP/IP set-up?
Q5. I understand how to get remote access to the CGD24N router (Provider IP address), but how do I get remote access to the DIR-826L router if it's IP is 192.x.x.x? Not possible? Fortunately I can access the Dlink via a cloud login....
Really appreciate any thoughts - and are more than happy to be pointed in the right direction for relevant web-site references. Even if I can't get it working the way I want it will be good to know the TCP/IP reasons.