A question on network router cabling

Is it possible that the router puts restrictions on certain ports or ranges of ports?
 
no
 
Is there a problem with using 80xx?
 
no
 
Does the Elk software continue to work using the WAN address while connected to the WLAN address after about 30 minutes?
 
Wondering about maybe its caching the data.  Guessing too that Elk and cams ports are configured as TCP (versus TCP/UDP?)
 
T-Mobile now is massaging the video data flow and restricting tethering to 3G versus LTE (4G) recently. IE: specifically for video streaming.  AT&T may be doing similiar?  There seems to be an about-face relating to net neutrality rules going on with the cellular carriers, much the same as the ISP's.  They have been doing it all along and playing ignorant about it.
Not sure if this would have anything to do with your issue / NAT reflection / change from one router to another though. 
 
RTSP typically utilizes two ports ...one for video and one for control of the video.
 
Video is video is video is video. 
 
You have only mentioned that now this doesn't work with new Frontier router and it did work with old ISP router.
 
Test one camera in a DMZ and see what happens.  IE: open the camera IP addess to the internet.  - IE: no rules for a bit.
 
Googling found another reference to ISP routers and NAT reflection specific to models utilized by ISPs.
 
Many DSL routers/modems prevent loopback connections as a security feature. This means that a machine on your local network (e.g. behind your DSL router/modem) cannot connect to a forward facing IP address (such as 199.149.252.44) of a machine that it also on your local network. Connecting to the local IP address (such as 192.168.2.40) of that same machine works fine.
 
This is an issue since each region has to specify an IP address for the client to connect. This is the ExternalHostName parameter in a regions config file (e.g. bin/Regions/Regions.ini). In the absence of NAT loopback, if a forward facing IP address is specified (such as 199.149.252.44) then external clients will be able to connect to the region but clients on your local network will not. If the internal address were put in ExternalHostName instead (e.g. 192.168.2.40) then viewers on the local network will be able to connect but viewers from an external network would not.
 
Here on Cocoontech brought up the issue (on another thread) that my Linux Firefox flash isn't working anymore for a bunch of news sites using the Home ISP connection and that it is been made dysfunctional due to security concerns.  Odd thing is if I use the same laptop tethered to my T-Mobile account then the Linux Firefox Adobe flash videos work fine but if I do an IPSEC VPN tunnel to my home mothership then the Firefox Adobe Flash videos do not work.
 
I have never had ekeypad/elk connected for more than a few minutes at a time. I forgot to mention though that the cameras do NOT work from ekeypad although all other functions do.
 
What would you conclude if the camera does work in dmz?
 
Putting a camera in the dmz made no change. the camera is still only accesible when I turn wifi off on the phone.
 
What would you conclude if the camera does work in dmz?
 
If the camera worked in the DMZ then maybe the NAT reflection is getting turned on or maybe the router OS has some rules or switch for port enabling buried on another page. 
 
I am guessing here that while using the GSM connection you can connect to your cameras just fine from the Internet eh?
 
AND just maybe it could be related to video massaging by your cellular phone provider.
 
Here many years ago using ZoneMinder (http://zoneminder.com) (http://zoneminder.com) (http://zoneminder.com) for multiple cameras switched from using individual ports per camera to one for software NVR views.  Some of the cams also had the multiview camera software built in to the firmware of the camera.
 
All in all it is puzzling that NAT reflection appears to be enabled for your ELK and not for your cameras.  You mentioned that it worked fine with the old router and not the new one such that I was sure that it related to a switch or the enabling of NAT reflection.
 
While the base rules for firewall routers are similar; they can be different depending on the mfg of the router.
 
 
 
Side picture of the old and first Triumph Spitfire transmission gear here unrelated to this OP.  I found it today and used to use it as a paper weight on my desk.  Wife asked what it was.  I was a kid, replaced the clutch on the Spitfire, popped the clutch and tore up the transmission one day.  It is today the only piece or part left to that old vehicle that I kept.  Told dad that I could fix it such that I took the transmission apart in the garage...many pieces...gave up and purchased a rebuilt transmission for $50 which was a lot for me at the time...well too parents kept telling me not to drive the 60's Spitfire in the snow as it wasn't made to do this....
 
 
spitfire.jpg
 
pete_c said:
Side picture of the old and first Triumph Spitfire transmission gear here unrelated to this OP.  I found it today and used to use it as a paper weight on my desk.  Wife asked what it was.  I was a kid, replaced the clutch on the Spitfire, popped the clutch and tore up the transmission one day.  It is today the only piece or part left to that old vehicle that I kept.  Told dad that I could fix it such that I took the transmission apart in the garage...many pieces...gave up and purchased a rebuilt transmission for $50 which was a lot for me at the time...well too parents kept telling me not to drive the 60's Spitfire in the snow as it wasn't made to do this....
 
 
attachicon.gif
spitfire.jpg
 
 I rebuilt the 3-speed transmission in my first car , a 1962 Rambler American, nice memories.
 
It sounds like we were both little gearheads as kids. I got a mini-bike when I was 11 and took the governor off the Tecumseh engine. Before long the camshaft broke in half and a close friend let me take the camshaft from his father's broken lawn mower. The operations was pretty exciting at that age and turned out well but boy was his dad pissed when he saw his mower!
 
Good times.
 
Yup; good 1960's memories.  Dad did help me align the clutch plate and transmission (small) holding it on the top while I was underneath the automobile using a wooden dowel.  Spitfire stuff was small and light. 
 
Try setting the IP camera's IP configuration DNS entries to 8.8.8.8 and 8.8.4.4 (Google DNS) or make your router's secondary DNS 8.8.8.8.
 
BTW are the Elk's DNS entries something other than the router's DNS entries?
 
Curious if this will change anything.
 
I tried setting a cam's dns address from the gateway address to 8.8.8.8 with no change. the camera does not allow for a secondary dns setting, only the primary.
 
Mike.
 
Yeah typically in a camera configuration you have to reboot the camera for the changes to take place in the IP.  The changes are not dynamic and relate to loading the network stuff on reboot.  The firmware these days is just Linux based.  Note too that the DHCP configuration (whether dynamic or static) will typically auto configure your stuff.  Line by line static configuration gives you more granularity.
 
Here on the older Ubiquiti IP cams had a saving configuration and a dynamic change button which probably disabled and enabled IP to enable the new stuff.
 
If you can telnet/ssh to the camera you may also be able to use ifconfig to see the settings.
 
IE: you can check the route say for google by pinging www dot google dot com.  First stop will be the DNS server.  Via command line you can change the routing tables (old fashioned long math way).
 
When I ping or tracert my gateway WAN address it is successful pinging at 4ms and when I add the port number to that address I get the error - "Unable to resolve target system name"
 
error - "Unable to resolve target system name"
 
That is just related to the firewall open ports and the such and I do not think you can ping ports.
 
That said you can do nmap.  nmap is a security auditors best friend and has many many features.
 
IE:
 
/pete# nmap -p 80 www.google.com

Starting Nmap 7.01 ( https://nmap.org ) at 2016-12-26 15:32 CST
Nmap scan report for www.google.com (172.217.4.100)
Host is up (0.011s latency).
Other addresses for www.google.com (not scanned): 2607:f8b0:4009:800::2004
rDNS record for 172.217.4.100: ord37s06-in-f4.1e100.net
PORT   STATE SERVICE
80/tcp open  http
 
Back
Top