You are saving settings by hitting the + icon?
Sent from my CPH2305 using Tapatalk
Hi All... It's been a while... So be gentle
I have just had the new Telstra Technicolor Gen 3 Cobra XH installed on the home network. (Telstra FTTN)
I am attempting to open and forward a port for remote access of my DNR-322L (D-link Network Video Recorder) however it appears to close whichever port I open after a very short time.
I have been using this feature for many years with various modem / router configurations but this time it's got me stumped ;(
Is there a simple way to work around this ? i.e. firewall rule or similar ?
1. I have a fixed IP address with telstra
2. DNR has a fixed IP address on Modem
3. I also have a dynamic DNR service running fine on the modem
4. All IP Camera's using port forwarding are accessable just fine
5. I am running latest firmware and all hotfixes on the DNR which is working perfectly on local network etc.
Any guidance would be most awesome
Thanx
Look Here -> |
You are saving settings by hitting the + icon?
Sent from my CPH2305 using Tapatalk
wotnot (30-09-22)
Yes, all setting changes have saved fine. Modem re-booted to test and it held the port forwarding rules ok.
It just doesn't keep the port open very long.... then closes it ;(
fromaron (30-09-22),snapperhead (29-09-22),wotnot (29-09-22)
LoL....if I keep running with that slant, when I say "it's a pity there's no manual to download to work out how they operate"...it takes on a different bent =)
What I say is true tho', anyone got a link to the pdf manual for this modem?...I can't find one....
I take that to mean the DNR-322 is configured with a static IP address that's outside the range of the modem's DHCP address pool?....(or there's a specific exception?).. and you have a static route configured to the DNL-322 ?..2. DNR has a fixed IP address on Modem
I suppose something else to try, would be configuring a DMZ for the DNL-322 to hang in, because that should work externally...caveat proper config ofc =)
fromaron (30-09-22),snapperhead (29-09-22)
Yes, the modem is default 192.168.0.1
The DHCP pool I set as 192.168.0.50 - 192.168.0.254
So the DNR is setup on a static route below 50 at 192.168.0.8
But whatever port I forward it to closes after a short time, and isn't accessable outside or inside the network.
The DNR of course is accessble without the port from within the network.
Strange
Given that it's a Helstra supplied modem, have you tried asking them? Of course it's a remote possibility that you find someone who actually knows what they are doing, but could be worth a try.
I'm out of my mind, but feel free to leave a message...
snapperhead (09-10-22)
There's not much 'telstra' in them, caveat the firmware artwork...they're just rebadges...ie; most all of the telstra branded modems get sold with tpgi branding (and others worldwide)..ie; the previous 'smart modem gen 2' model was available from both t's....which is kinda funny when tpgi use optus backbone...muhahaha....
Wrt that previous gen2 smart modem, I found a thread about a very similar problem, and it turned out NAT loopback was somehow broken...at a guess, in the firmware but who knows (in the old days I've seen big routers lose the plot when a single ram chip goes bad that just happened to be the ram location where the MAC address tables were held =) Regardless of what these things are branded, I tend to look at all of them as being linux appliances, running one or another custom fork of openwrt or similar, and they're largely going to be using the same softwares available to your average linux distro...and it's the linux kernel doing all the hard lifting....so you can sort of look at problems like this, in the light of what would cause openwrt to carry on like this?
The report "whatever port I forward it to closes after a short time" gets the Mr Spock raised eyebrow look, because one would like to know how long a 'short time' is, and whether it always happens after the same amount of time...ie; periodical policy updates ...OP's right, this kinda smells something like firewall/iptables going screwy...or... it's gone all woke and this is the default underlying policy for the LAN group. In any event, breaking it out into a DMZ will result with the host (the DNR-322) having a different policy applied to those applied to the LAN group, and makes for easier checking (from the LAN side). The fact the DNR-322 is still accessible on the LAN side (but without port specification), again looks like ipfw is somehow involved here, and the best way to change things without physically changing things, is going the DMZ route.
"You are saving settings by hitting the + icon?" ...fair question, because they could've botched this with the webgui ...on the gui port forwarding page, there's no need to read and parse the actual config file(s) in /etc ...you can just read (and change) the current kernel running config by reading the appropriate /proc interface ... ergo when one hits the + icon, this should be an 'apply & save' action...ie; change the realtime kernel config via /proc, and append/change/save the associated daemon config file in /etc -- if the latter were not taking place, and whatever was reloading it's config file periodically (or a crontab or some other process), then that might explain the behaviour...hmmm......is ssh available on the DNR-322?
If you were feeling adventurous -->
snapperhead (09-10-22)
Bookmarks