not able to access my internal dvr

karanc

need help/suggestion ...why this is not working out

i have a setup like this :

ISP ADSL modem <-->(fa0/1) cisco 1841 (fa0/0)<-->internal network
public static ip with dvr ip 192.168.9.13

network diagram:



now i am able to reach to internet and access website from my internal network but when i try to reach my dvr from outside...i get unreacheable in DVR software program.

my router config is below :

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname LC_divya_01
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
enable secret 5 <removed>
no aaa new-model
no ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.9.1 192.168.9.11
!
ip dhcp pool CLIENT
network 192.168.9.0 255.255.255.0
default-router 192.168.9.1
dns-server 4.2.2.2
domain-name lacurdvr.com
!
!
no ip domain lookup
!
!
!
username karan privilege 15 secret 5 $1$Txqu$e7ztvaedZDIpUkRLU3tCu/
!
!
!
!
!
interface Loopback0
ip address x.x.x.x 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.9.1 255.255.255.0
ip nat inside
ip virtual-reassembly
no ip route-cache
ip tcp adjust-mss 1412
duplex auto
speed auto
!
interface FastEthernet0/1
description $ETH-WAN$
no ip address
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer0
ip unnumbered Loopback0
ip mtu 1452
ip nat outside
ip virtual-reassembly
encapsulation ppp
no ip route-cache
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication pap callin
ppp pap sent-username <removed> password 0 <removed>
ppp ipcp route default
!
no ip http server
no ip http secure-server
ip nat inside source list 100 interface Loopback0 overload
ip nat inside source static tcp 192.168.9.13 2804 200.26.207.103 2804 extendab .......(dvr works on port 2804)
ip nat inside source static udp 192.168.9.13 2804 200.26.207.103 2804 extendab
ip nat inside source static udp 192.168.9.13 3000 200.26.207.103 3000 extendab
ip nat inside source static udp 192.168.9.13 4000 200.26.207.103 4000 extendab
!
access-list 100 deny ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
access-list 100 permit ip 192.168.0.0 0.0.255.255 any
dialer-list 1 protocol ip permit
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
logging synchronous
login local
transport input telnet ssh
line vty 5 15
logging synchronous
login local
transport input telnet ssh
!
scheduler allocate 20000 1000
end

now if i try to log into my dvr internally with ip address 192.168.9.13:2804 ...i can watch my cameras......but when i try to access it on my public ip x.x.x.x:2804 ...i cannot
my internal network computer can access internet .........i have put no firewall no port blocking .....but still i am not able to log into dvr from outside world ...........

i have given static ip to DVR with deafult route to 192.168.9.1 which is my router...

i even tried few online port scanner website ....on my public ip x.x.x.x:2804 and all replied with no service available


need suggestion on whats going wrong in my config why my static map is not working correctly.... also when i debug ip nat ........i can c translation from x.x.x.x->192.168.9.13 on port 2804 but no inside to outside translation 192.168.9.13->x.x.x.x...so it means i am able to reach my router public interface...then translation is occuring ...but getting no reply from dvr .......

is it some nat timeout problem ............or how should i troubleshoot this strange problem ?????

karan

networker050184

The configuration looks good at first glance. You should contact your ISP to see if the port is being blocked.

karanc

they said to me there is no port blocking from their side also i c the nat translation in my nat table ...so it is reaching to my router internet side ....but something fishy happening on internal side

networker050184

The translation you see is most likely just the static translation you configured not an active session.

Are you sure about the port number??

EDIT: closest thing with ports for DVR I could find with a quick search is this. This does not list the port you are using....

karanc

yes the port is correct.i double check with DVR vendors...


here is my nat table translation when i try to connect to dvr from internet

LC_divya_01#show ip nat tran
Pro Inside global Inside local Outside local Outside global
tcp x.x.x.x:2804 192.168.9.13:2804 200.26.223.46:2632 200.26.223.46:2632
tcp x.x.x.x2804 192.168.9.13:2804 200.26.223.46:2633 200.26.223.46:2633
tcp x.x.x.x:2804 192.168.9.13:2804 --- ---
udp x.x.x.x:2804 192.168.9.13:2804 --- ---
udp x.x.x.x:3000 192.168.9.13:3000 200.26.223.46:2528 200.26.223.46:2528
udp x.x.x.x:3000 192.168.9.13:3000 200.26.223.46:2629 200.26.223.46:2629

Forsaken_GA

The easy way to check and see if the port is actually open coming in from the outside is to forward that port to something else that should be answering on the inside, like port 80 to another machine (for example, I have all of my servers running on port 22 for ssh, but I have the router forwarding ports 33564, 33565, etc etc to the correct IP on port 22). Assuming you've got something with a web server setup, forward that port to port 80 on that IP, if you get a response, the ISP isn't blocking the port (don't take their word at face value, test it for yourself! alternatively, run nmap against your IP from outside to see if that port is open).

I had an issue with this recentlhy with my wireless router which I turned into an AP (ie, wasnt using the routing portion of it). I could communicate with the machines behind it just fine, but I couldn't talk to it directly unless it was with a machine on the same subnet.

Example:

The Router/AP has ip 192.168.2.11, my laptop associating with it has 192.168.2.199. My monitoring server is on a different subnet at 192.168.3.7. I could ping 192.168.2.199, but not 192.168.2.11.

The issue turned out to be that, although I was essentially using it as a switch, I had to define static routes to the subnet's gateway before the other subnets could ping it. Was just a matter of the device not knowing how to respond to an IP that came in from a different subnet.