Can ping macbook, but not IP Cameras on isolated network

Kenny · October 14, 2022, 6:25pm

I'm trying to set up a WLAN network without access to the internet which my IOT devices/ IP cameras will connect to, and is reachable from the LAN, however am running into some weird issues.

To start, describing my network layout, I have a Verizon router (IP Address 192.168.1.1) acting as my primary network/running DHCP (the wifi capabilities are superior to my openwrt router). I have my openWRT router connected to that configured with the DHCP disabled for the LAN interface (IP Address 192.168.1.2) (so essentially an unmanaged switch).

I have a linux box also connected on the LAN to host home assistant.

The OpenWRT router has a wlan configured with IP Address 192.168.3.1, and connected to that wlan I have an IP Camera (192.168.3.156) and my macbook to test with (192.168.3.175).

I had to set up static routes on my verizon router, however I'm now able to ping and traceroute my macbook from the linux server. Further, I'm able to ping the IP camera from my macbook, which makes sense since it's on the same network.

What's strange though, is that I can't ping the IP camera from my linux server. the traceroute suggests to me that it's at least getting to the openwrt, but then failing to route to the camera, or else blocking the response for some reason.

And below is pinging/tracerouting the IP camera from the Macbook, so I know the device does respond:

I've added another IP camera (192.168.3.216), same issue, can stream it to my macbook while also connected to the IOT wlan, but can't ping it from my linux box.

I also checked, and I can SSH onto the openwrt router and can ping the cameras from there.

When I connect the macbook to the LAN I again can't ping the camera.

I've been beating my head on this for a while, would love to hear if anyone has suggestions on what is going wrong connecting to the IP Camera.

psherman · October 14, 2022, 6:38pm

To make sure I/we understand the issue, the TL;DR is this:

successful ping from Mac > camera (both on the same 192.168.3.0/24 network)
successful ping from Linux > Mac (192.168.1.0/24 > 192.168.3.0/24)
failed ping from Linux > camera (192.168.1.0/24 > 192.168.3.0/24)

Is that correct?
It is possible that this is an issue with the cameras, not OpenWrt. Maybe cameras won't respond to connection requests from a different subnet (Windows firewall does this by default, so this could be a firewall/config setting on the camera, or maybe a shortcoming of the camera's network stack in general).

Let's take a look at your configuration to make sure everything is setup properly.

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

Kenny · October 14, 2022, 7:21pm

Thanks for the quick response!

Yes, the TL;DR you posted is accurate

here's the config:

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd15:8702:dd62::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'wan'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '192.168.1.2'
	option gateway '192.168.1.1'
	list dns '192.168.1.1'

config device
	option name 'wan'
	option macaddr '**:**:**:**:**:**'

config interface 'IOT'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.3.1'

config route
	option interface 'lan'
	option target '192.168.3.0'
	option netmask '255.255.255.0'
	option gateway '192.168.3.1'

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option disabled '1'
	option country 'US'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option macaddr '**:**:**:**:**:**'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option macaddr '**:**:**:**:**:**'
	option disabled '1'

config wifi-device 'radio2'
	option type 'mac80211'
	option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'
	option channel '34'
	option band '5g'
	option htmode 'VHT80'
	option disabled '1'

config wifi-iface 'default_radio2'
	option device 'radio2'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'

config wifi-iface 'wifinet3'
	option device 'radio1'
	option mode 'ap'
	option ssid 'iot'
	option key '**********'
	option ieee80211w '0'
	option network 'IOT'
	option encryption 'psk2'

root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option ignore '1'
	list ra_flags 'none'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'IOT'
	option interface 'IOT'
	option start '100'
	option limit '150'
	option leasetime '12h'
	list ra_flags 'none'

Another thing I just tried was running tcpdump icmp from the router, then pinging the mac then the camera from my Linux box.
This shows up when pinging Linux -> Mac:

19:19:57.147269 IP 192.168.1.159 > MacBook.lan: ICMP echo request, id 19, seq 1, length 64
19:19:57.417165 IP MacBook.lan > 192.168.1.159: ICMP echo reply, id 19, seq 1, length 64
19:19:58.148753 IP 192.168.1.159 > MacBook.lan: ICMP echo request, id 19, seq 2, length 64
19:19:58.440108 IP MacBook.lan > 192.168.1.159: ICMP echo reply, id 19, seq 2, length 64
19:19:59.149539 IP 192.168.1.159 > MacBook.lan: ICMP echo request, id 19, seq 3, length 64
19:19:59.257088 IP MacBook.lan > 192.168.1.159: ICMP echo reply, id 19, seq 3, length 64

But nothing shows up for Linux -> Camera

psherman · October 14, 2022, 7:26pm

The only issue I see is this:

The above is unnecessary and can be removed. If you are aiming for symmetric routing, you need to have a static route defined on your Verizon router to route 192.168.3.0/24 via 192.168.1.2 --- do you have this already in place?

Otherwise, you omitted the firewall file -- that's the only other file that needs to be checked.

Kenny · October 14, 2022, 7:29pm

yeah, initially didn't have that and was wondering if it wasn't properly routing the packets on the openWRT side so I had added it, I can definitely remove it.

Sorry, here's the firewall file:

root@OpenWrt:~# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled 'false'

config include
	option path '/etc/firewall.user'

config zone
	option input 'ACCEPT'
	option output 'ACCEPT'
	option name 'iotZone'
	list network 'IOT'
	option forward 'ACCEPT'

config forwarding
	option src 'lan'
	option dest 'iotZone'

config forwarding
	option src 'iotZone'
	option dest 'lan'

Initially had IOTZone firewalled off from LAN, and will add that back later to block the cameras from the internet but for now removed it while testing

psherman · October 14, 2022, 7:34pm

ok... so no issues in the firewall, from what I see.

I suspect that the cameras themselves don't respond to requests coming from another subnet. Depending on the camera, it may a configurable option, or it could be a config error in the camera (specifically if you have assigned it a static IP with the wrong gateway or subnet mask).

Kenny · October 14, 2022, 7:38pm

I was actually incorrect in a prev comment when I said I don't see anything in tcpdump icmp

I actually see this:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
19:34:17.596145 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 1, length 64
19:34:18.604686 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 2, length 64
19:34:19.628686 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 3, length 64
19:34:20.652616 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 4, length 64
19:34:21.676651 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 5, length 64
19:34:22.704669 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 6, length 64
19:34:23.728671 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 7, length 64
19:34:24.748545 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 8, length 64
19:34:25.772659 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 9, length 64
19:34:26.796566 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 10, length 64
19:34:27.820664 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 11, length 64
19:34:28.844624 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 12, length 64
19:34:29.868630 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 13, length 64
19:34:30.892606 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 14, length 64
19:34:31.916634 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 15, length 64
19:34:32.940668 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 16, length 64
19:34:33.964614 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 17, length 64
19:34:34.992633 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 18, length 64
19:34:36.012579 IP 192.168.1.159 > IPC.lan: ICMP echo request, id 25, seq 19, length 64
19:35:51.354395 IP 192.168.1.159 > MacBook.lan: ICMP echo request, id 26, seq 1, length 64
19:35:51.590767 IP MacBook.lan > 192.168.1.159: ICMP echo reply, id 26, seq 1, length 64
19:35:52.354599 IP 192.168.1.159 > MacBook.lan: ICMP echo request, id 26, seq 2, length 64
19:35:52.611463 IP MacBook.lan > 192.168.1.159: ICMP echo reply, id 26, seq 2, length 64
19:35:53.355974 IP 192.168.1.159 > MacBook.lan: ICMP echo request, id 26, seq 3, length 64
19:35:53.634775 IP MacBook.lan > 192.168.1.159: ICMP echo reply, id 26, seq 3, length 64
19:35:54.356758 IP 192.168.1.159 > MacBook.lan: ICMP echo request, id 26, seq 4, length 64
19:35:54.658534 IP MacBook.lan > 192.168.1.159: ICMP echo reply, id 26, seq 4, length 64

I think that supports what you're saying that the camera doesn't respond to requests from another subnet.

The camera I have is an Amcrest (I realize this is sort of out of scope for a openWRT forum, just leaving breadcrumbs for anyone else that might run into this )

I'm going to look into if it's configurable for the camera, do you know if there's some other configuration that would match my use case so that the camera doesn't realize it's on another subnet or something like that?

Kenny · October 14, 2022, 7:44pm

Checking the camera config, I think it has the right gateway/subnet mask:

psherman · October 14, 2022, 7:47pm

If the goal is to be able to reach it from other systems, give those systems an address on the same subnet -- this can be done by connecting via wire on one network + wireless on the other, 2 wired connections, or wired with VLANs and tagged frames (coming directly from the OpenWrt router; you also need to configure your computer to work with 802.1q tags).

Alternatively, if the goal is simply to prevent the camera from reaching the internet, you could connect it back to the 192.168.1.0/24 network, and create a firewall rule in your verizon router that drops all connections from the address of the camera. This will not affect your ability to reach it via the linux box or any other devices on the 192.168.1.0/24 network.

psherman · October 14, 2022, 7:48pm

yes, everything looks right there. For grins, try connecting to the web server of that camera directly and see if it works from the linux box. My guess is no, but you've only tested pings, from what you've described.

Kenny · October 14, 2022, 7:56pm

Thanks for the suggestions - Ultimately I want to run home assistant on the Linux box, so I think I want that to have access to the internet and to the IOT network, but have the IOT network isolated from accessing the rest of my network and the internet.

It seems like the first idea of connecting the linux box wirelessly to the IOT network, but wired to the LAN network should work - What sort of config do I have to do on the linux box to make it route traffic to the 192.168.3.0/24 network over the wifi?

I'm a bit hesitant to add the IOT devices to the 192.168.1.0/24 network since it would be a pretty manual process firewalling devices anytime I get some new toy.

I had initially been trying to connect to the camera via the rtsp stream with VLC, which I am able to do from within the 192.168.3.0/24 network, but not the 192.168.1.0/24 network.

psherman · October 14, 2022, 8:07pm

no special configs should be necessary. The Linux box will have an address on two networks. It will know to send local traffic on the respective networks with no further configuration. Since it seems that you will have the IoT network isolated from the internet, you will want to make sure that the main LAN is the default method by which the linux box uses for upstream/internet connectivity. I'm not sure how to change the service order on linux as I've rarely needed to mess with that. On the mac, you can set the service order in the network settings. On linux, it might be by means of a metric setting (that's how OpenWrt's mutli-wan works) or similar. Should be easy enough to find that info.