Can not access local IP 10.0.1.3

Question

Level 1

9 points

Can not access local IP 10.0.1.3

I have been using a Lorex security camera system since 2013. I have it setup using NAT & DHCP on my time capsule version 7.6.7 I use port forwarding and a Lorex DDNS address for remote access. I have been accessing the cameras internally by entering 10.0.1.3:1300 for about 3 years. This week that suddenly stopped working. I contacted Lorex and they can see my cameras through their DDNS. We can see our cameras on our phone through their DDNS. I have done a hard reset on the TC. We are having this problem on both our MacBook air and iMAC running El Capitan. I thought it might be some wireless problem (just installed zwave automation and thought it might be interference) so I direct connected to the TC. No luck. Also, I have been not able to open the cameras on our computers from the DDNS address. From what I have read, I think this is a common reverse NAT issue. Can anyone give me advice on what could have changed that cause me not to be able to connect to an internal IP address? Thanks in advance.

MacBook Air, OS X El Capitan (10.11.6)

Posted on Jul 30, 2016 8:25 AM

Reply

Answer 1

Tesserax

Level 10

148,447 points

Jul 30, 2016 8:46 AM in response to Oviedomike

If you can't access the cameras locally, then I doubt you will have any luck connecting to them from a remote location.

What happens when you ping the 10.0.1.3 address from a local host? If the ping is unsuccessful, I would suggest clearing the ARP cache on your MacBook Air.

Before doing so, let's take a look at what entries are currently in the cache.

To do so, enter the following command in Terminal: arp -a

The results will show a list of devices on your local network that includes both their IP (network) & associated MAC (hardware) addresses. Did you find one for 10.0.1.3?

To clear the cache, enter the following command in Terminal: sudo arp -a -d

Note that using sudo will require that you log onto your Mac with a user account that has Administrator privileges.

Then try another ping.

Reply

Answer 2

Oviedomike Author

Level 1

9 points

Jul 30, 2016 8:55 AM in response to Tesserax

Yes, I found a listing for 10.0.1.3.

Last login: Fri Jul 29 18:26:32 on console

MikesMacBookAir:~ mikejacobs$ arp-a

-bash: arp-a: command not found

MikesMacBookAir:~ mikejacobs$ arp -a

? (10.0.1.1) at 70:56:81:c6:ea:8c on en0 ifscope [ethernet]

? (10.0.1.3) at 0:23:63:23:9:6 on en0 ifscope [ethernet]

? (10.0.1.4) at 28:37:37:1b:b5:e8 on en0 ifscope permanent [ethernet]

? (10.0.1.8) at 14:99:e2:29:c3:46 on en0 ifscope [ethernet]

? (10.0.1.12) at f0:24:75:80:4e:b5 on en0 ifscope [ethernet]

? (10.0.1.15) at a4:d1:d2:82:ea:4f on en0 ifscope [ethernet]

? (10.0.1.20) at 70:a2:b3:cd:50:b9 on en0 ifscope [ethernet]

? (10.0.1.21) at c0:1a:da:52:9a:64 on en0 ifscope [ethernet]

? (10.0.1.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]

all-systems.mcast.net (224.0.0.1) at 1:0:5e:0:0:1 on en0 ifscope permanent [ethernet]

? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]

MikesMacBookAir:~ mikejacobs$

I need to setup a password to do the clear procedure.

Reply

Answer 3

Tesserax

Level 10

148,447 points

Jul 30, 2016 9:04 AM in response to Oviedomike

As you can see IP 10.0.1.3 is associated with the MAC address starting with 0:23. This may or may not be the correct MAC for the camera interface.

You should not need to create a password to do the clear procedure, you just need to logon to your MacBook Air's Administrator account ... or just your user account if it already has upgraded privileges.

What happened when you pinged this device?

Reply

Answer 4

Oviedomike Author

Level 1

9 points

Jul 30, 2016 9:11 AM in response to Oviedomike

Sorry for the delay. Still learning how to get around this site.

Here is what the new ping looks like

Last login: Sat Jul 30 12:02:39 on ttys000

MikesMacBookAir:~ mikejacobs$ arp -a

? (10.0.1.1) at 70:56:81:c6:ea:8c on en0 ifscope [ethernet]

MikesMacBookAir:~ mikejacobs$ ping

usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]

[-g sweepminsize] [-h sweepincrsize] [-i wait] [−k trafficclass]

[-l preload] [-M mask | time] [-m ttl] [-p pattern]

[-S src_addr] [-s packetsize] [-t timeout][-W waittime] [-z tos]

host

ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i wait]

[−k trafficclass] [-l preload] [-M mask | time] [-m ttl] [-p pattern] [-S src_addr]

[-s packetsize] [-T ttl] [-t timeout] [-W waittime]

[-z tos] mcast-group

MikesMacBookAir:~ mikejacobs$ arp -a

? (10.0.1.1) at 70:56:81:c6:ea:8c on en0 ifscope [ethernet]

? (10.0.1.3) at 0:23:63:23:9:6 on en0 ifscope [ethernet]

MikesMacBookAir:~ mikejacobs$

Reply

Answer 5

Oviedomike Author

Level 1

9 points

Jul 30, 2016 9:12 AM in response to Oviedomike

Checked the MAC on my device and that looks correct.

Reply

Answer 6

Tesserax

Level 10

148,447 points

Jul 30, 2016 9:18 AM in response to Oviedomike

Ok, thanks.

The correct syntax for ping, in this case, would be: ping -c3 10.0.1.3

The results should show three ping attempts to 10.0.1.3 with a summary at the bottom. All ping packets should have been transmitted and received with 0.0% packet loss. Is this the case for you?

Reply

Answer 7

Oviedomike Author

Level 1

9 points

Jul 30, 2016 9:21 AM in response to Tesserax

Yes. Did that and they came back with 0% loss.

MikesMacBookAir:~ mikejacobs$ ping -c3 10.0.1.3

PING 10.0.1.3 (10.0.1.3): 56 data bytes

64 bytes from 10.0.1.3: icmp_seq=0 ttl=64 time=1.460 ms

64 bytes from 10.0.1.3: icmp_seq=1 ttl=64 time=2.765 ms

64 bytes from 10.0.1.3: icmp_seq=2 ttl=64 time=3.179 ms

--- 10.0.1.3 ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 1.460/2.468/3.179/0.733 ms

MikesMacBookAir:~ mikejacobs$

Reply

Answer 8

Tesserax

Level 10

148,447 points

Jul 30, 2016 9:44 AM in response to Oviedomike

Thanks.

That would indicate that, at least, at the physical, data link, & network layers of your network connection between the devices there isn't an issue. Which basically means there doesn't appear to be anything wrong with your current network as far as connectivity between devices is concerned.

Which would leave us to the transport & application layers. When you access a network service using a port number after an IP address, like 10.0.1.3:1300, this is known as a socket. It tells the host application on your MacBook Air where to sent its request for data to. That is what process or application, running on the camera interface, needs to be accessed. In this case, the process is at port 1300 @ at the device located @ 10.0.1.3.

... and this is where something appears to be going amiss.

Some things to check:

Verify that the camera interface is actually configured to use port 1300.
Your Mac has two built-in software firewalls. Basically one for applications and another for system processes. Both are disabled by default. One or the other may have been enabled and is blocking communications to this device.
You are using a third party software firewall. Murus or LittleSnitch come to mind. If you are temporarily disable them to see if this will help.

Reply

Answer 9

Oviedomike Author

Level 1

9 points

Jul 30, 2016 9:44 AM in response to Oviedomike

Found a hard reset procedure for my DVR. I think I may be connecting, but just getting a blank screen. More later.......

Reply

Answer 10

Oviedomike Author

Level 1

9 points

Jul 31, 2016 7:22 PM in response to Oviedomike

After another day of testing and checking, I have come to the conclusion this is a Safari issue. I have never been able to open this link in Chrome. Today I tried Firefox and it gave me the banner but not the camera images. I will move this over to the Safari board.

Reply