If you need security to separate out the 192.168.1.0 subnet from 192.168.16.0 subnet, maybe vlans would work? Maybe you could give the DVR the address 192.168.16.87 and eliminate the second router? NAT behind NAT isn't a great idea, anyway. Either way, don't forget to put everything back the way it was ASAP.Īnd then, there's the question of why you need to have the CCTV on a different subnet, via a router, in the first place. If you cannot access the CCTV using that method, then there are some details that are wrong. If you can access the CCTV using that method, the problem is in your router config.
That has the effect of making any request to 192.168.1.100:37777 go directly to it rather than going out the gateway. Temporarily change the IP config of a device on the 192.168.16.0 subnet and give it a 255.255.0.0 subnet mask.That has the effect of putting both subnets on the same LAN and removes that router from the equation AND Plug the cable currently going into the WAN socket on 192.168.1.1 into a LAN socket on 192.168.1.1.You * might* try doing the following as a test: Since you are running a 3rd-party firmware on that router (and I have zero familiarity with that product), I would check that the ACL for the incoming port (if ACLs have been implemented) allows connections from the 192.168.16.0 subnet,īased on what you have said, it should be as simple as accessing the WAN port of the 192.168.1.1 router but since it doesn't work, there is obviously something else in play.I would log into 192.168.1.1 and make sure that it is actually listening on 37777 and that there is no port translation taking place on the 192.168.16.1 router AND.I would expect the router at 192.168.16.1 to be port forwarding 37777 to 192.168.16.87 (the WAN port of the CCTV's router) BUT.I can only suspect it's the 192.168.1.1 router doing something funnyĮxternal users are able to access the CCTV via, say, an address such as dvr.your-external-domain,com:37777 (sounds like a Dahua DVR) then The 192.168.16.1 router should be treating it as a internal connection so routing should not apply. I wish hairoinning / nat loopback was available as this would make it just work. If your internal users are not getting to the CCTV using 192.168.16.87:37777 but external users get to it, then I suspect the details you have supplied are wrong. You can use the actual 192.168 addresses. How about a diagram showing the actual inside and outside addresses of the CCTV router and the inside address of the. What is the subnet that your users are on? Is it. Shall we start again? From the beginning? Your diagram says CCTV is on 192.168.1.87 You are correct 16.x router is port forwarded to 192.168.16.87 and the the 1.x router is port forwarded to 1.100 Re-enabled.External comes in.on 16.x the cctv is on ip address 192.168.1.100:37777
FIXED: Asus had disabled the NAT loopback fix on MIPS's iptables in GPL 3762.
FIXED: vsftpd wouldn't start if you had IPv6 enabled. FIXED: Non-DPI build of AC56U had incompatible Tuxera modules
Nat loopback merlin update#
CHANGED: Moved the AC68U CFE update process to the same location as in GPL 3626 to see if it works more consistently. NEW: Added custom config and postconf support for avahi, netatalk and mt-daapd (iTunes server). This package includes a customized firmware targeted at ASUS routers that brings various changes without modifying the interface of the original firmware. The AsusWrt-Merlin firmware was developed with the primary goal of boosting the original ASUS firmware, fix bugs and also add new improvements.
0 kommentar(er)
