Thank you mk24, I added Allow forward to destination zones : WAN to the cctv firewall, the internet is working, I can connect using the Hik Connect app.
Sorry but I don't know where to find the connection status to see the ports, I checked the Status -> Firewall -> i looked for the cctv but there are no ports there. could you direct me where to find these?
Are you talking about the traffic rules tab? I'm not using ssh yet, I added blocking rules, but not sure if correct, is it correct?
I can't remember where in Luci but somewhere in there it has realtime monitoring and graphs, one thing is connections, you can see which connections are active there.
Thanks dlakelan, I found it in Status -> Realtime Graphs -> Connections Tab,
Did i correctly do the Block rules?
No you want to turn off input in the camera zone, and then create input rules allowing port 53 and port 67-68 as input not forward from camera zone
Hi dlakelan,
I changed the input into reject
I'm not sure about the traffic rules
And I found the ports are changing? While looking at the connections. This are the ports when I connect one mobile device.
Source Ports
60270, 38231, 33471, 51247
Then I conencted another mobile device and these are the additional ports
51246, 51216, 43887, 43816
The Destination ports are also changing and adding
6800, 12395, 13028, 13131
You want to accept input from CCTV zone not from WAN zone!
As for ports, the port of interest is the destination port on the remote host. Also the remote host IP, if that is consistent.
Here is the updated traffic rules, but shouldn't i need to block these from the cctv?
Is this the right firewall rule?
You are blocking everything by default, if you don't enable these, your cctvs won't get DHCP addresses and won't be able to do DNS lookups.
Got it now, Thank you dlakelan.
How about the firewall rule for destination port, is it correct?
I think you want input zone CCTV and output zone wan
Here is the update config
I noticed that other ports are still being connected in the Destination. How to limit to only port 6800 only?
I changed the firewall zone to reject everything (input, output, forward) but the app can still connect to it.
In the picture you show above, you are allowing forwarding to destination zone WAN:
https://forum.openwrt.org/uploads/default/original/2X/5/50cff6cecd27fae1a3b12b38754ea506f68c7525.png
Turn that off, so it's not allowed to forward to any zone.
Thank you dlakelan, I forward to the destination zone WAN so it will get internet connection.
When I removed the forward to destination zone WAN, I cant connect to the HIK connect, even I change the input, output, forward to accept.
Turn off the forward to WAN, and then add your rule allowing only destination ports 80, 8000, 554, 443 to forward to WAN. Though this is pretty wide given the port 80 and 443 it's apparently the minimum ports:
Hey, I wanted to jump back in here.
As @dlakelan pointed out, my advice had a few critical assumptions attached, and I'm sorry I didn't make that clear. However, in your case, those assumptions might still be true. It's very likely that your ISPs modem/router does have basic firewall and NAT. A very clear hint would be whether or not it has more than 1 ethernet port. I would say it's worth checking out. Also, look at the brand/model of the modem and look it up, see if it's configurable. EDIT: search for possible security issues found for your model modem
To know for sure:
check out your public IP address on your current network by going here:
http://checkip.dyndns.com
(and since it's your public address, keep that private, to yourself)
and compare that address with what you see under the WAN interface in LuCI on the FIRST router directly connected to the ISPs modem/router
If the addresses are different, your modem/router has NAT and probably a firewall. You can then look into how to log in to your ISPs modem/router and adjust firewall and port forwarding from there.
Otherwise, placing everything into separate LANs and zones is the way to go
In my opinion no one should ever trust a device provided by an ISP. History shows that ISP provided devices routinely are compromised, as are consumer routers with stock firmware. For a camera network in particular, keeping things behind your OpenWrt firewall, completely under your control is the best option.
It is possible to make this more restricted by limiting only to the IP addresses of the HIK servers if you can find that list.
Again, very good point, that's possible. For that reason, I would want to know everything about the equipment that my ISP supplied, and if I was so extremely concerned with security, I would configure it as best as it can be, especially changing the default password. Otherwise, guests might be able to guess its address and log into it...
I'm also wondering...does this CCTV have its own light security? like username/password? What about connection encryption? Without that, even with the best firewall, anyone can view, or in the case of no encryption, snoop the content if they can guess or test all ports...
I know ISP equipment is terrible...but you need to trust it to some small degree. All packets are moving through it after all. Just because modems are the bad egg doesn't mean we should ignore its existence.
It's not just terrible, normally any ISP employee can send arbitrary packets to any device connected directly to the ISP equipment by design. without a firewall between your ISPs equipment and your equipment you are already compromised, game over.
It's true that the ISP equipment carries the outbound packets, but there is no reason to let your ISP send arbitrary packets to equipment you own.
Agreed
But if one is so worried about how evil their ISP is, or how weak the protocol they use to access them, compared to anons on the outside, I would buy my own modem that is compatible with their service...
I was talking more of the relevance of having more than a basic NAT/Firewall against outside attacks. Every device needs to be able to protect itself to some degree from rogue packets, no matter what firewall is in place, the port can still be abused if its open to the public...
On that point, I don't see a huge difference between the possible sources of those rogue packets...
Either way, its up to you @subie how critical your setup is, if you want to remove every possible threat, even the most unlikely, you guys are on the right track.
it's been a nice talk, time for bed
