OpenWRT Silently Blocks LAN Connections

Installing and Using OpenWrt
1

I am looking for assistance on trying to diagnose what is going wrong.

I've had OpenWRT set up for some many months, maybe 1.5 years now.

I have noticed a weird thing where if the uptime gets to the 20 day mark, some devices can no longer communicate to each other.

On Dec 8, when my uptime was 19 days, I used Plex to LAN stream from my pi to my phone.

The plex app failed after 2 or 3 minutes, so I would use a browser and point to the local address 192.168.0.x:32400/web and would stream from there successfully.

On Dec 10, I went to do the exact same thing. It now results in the error in browser:

Unable to connect

  1. The site could be temporarily unavailable or too busy. Try again in a few moments.
  2. If you are unable to load any pages, check your device’s data or Wi-Fi connection.

[Try Again]

All internet activity works just fine.

I try two more methods to contact the pi. First, the poorly performing Plex app. Nope, it tries for about 90 seconds to find the known server, silently fails, and instead loads the global streaming options / "live" tv.

Second, I try to use my VNC client to access the desktop of my pi. It tries for a minute before timing out and closing the attempt to connect.

I sign into the web ui for OpenWRT for the router and it shows the device its connected.

So, what then? Well, I go to my TV that is also on the router wirelessly and it loads the local plex server via its plex app just fine. I successfully streamed for an hour.

So now I write to the forums. This kind of phenomenon has happened multiple times where the network just... splits? Segregates? Separate LANs? I don't know.

The closest I have to trying to segragate traffic is shuttling devices to internet via different VPN thanks to Policy Based Routing.

Is there some kind of rollover bug happening from too high of an accumulator right around the 20 day mark that could be resulting in LAN devices no longer being able to reach each other? What could I look for in logs to find that out?

I would just work around the bug by having the router reset every week. Unfortunately, there is no way to get the VPNs to come online smoothly. They are all from the same service provider so there is a race condition conflict where multiple configs are trying to authorize their connections at the exact same time and the provider isn't accepting it. Even when attempting to edit the configs to wait longer on their timeouts and re-connect attempts so they are staggered at different intervals, that hasn't proven reliable.

2

You've described a bunch of symptoms, but we'll need to try to find specific patterns and details in order to narrow down what might be happening.

Let's start with the following:

  • If there is more than one networking device in your setup (i.e. if there is a router + switch/APs), please provide a topology diagram so we can understand how the network is structured. Include the brand+model and IP address in the diagram. A photo of a sketch on paper is sufficient.
  • Is Plex running on your OpenWrt system?
  • Is Plex the only issue, or do you have other connectivity loss (lan and/or wan)?
  • Does this situation affect wired devices only, or wireless only, or is it both wired+wireless?
  • Let's take a look at the current configuration:

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
3

networktopology

Using solid lines for wired connections, dashed lines for wireless connections.fla

(I have the Dynalink to serve as an OpenWRT device. Because OpenWRT has occasional issues like downed vpns, and I find it important that certain devices only ever use a vpn, and there are tech unsavvy people in the house, yes they will use their personal devices to access the internet without the OpenWRT providing policy based routing. Just easier for them rather than dead internet requiring me to troubleshoot.)

Plex is not on the OpenWrt system. Plex Server is running on a raspberry pi (192.168.1.2). Plex clients and web browsers acting as plex clients are not on the OpenWrt system. They are running on PC (192.168.1.3), Phone (192.168.1.4), and 192.168.1.6 (TV).

All devices seem to have access to WAN. I can access OpenWRT (192.168.1.1) on both Phone and PC. I cannot access pi via ssh or vnc from either Phone or PC. I cannot access the pi as a plex server from Phone or PC. However the TV can access the pi as a plex server. I expect, but cannot perform, that if I could ssh from TV to pi that they would connect. I do not know how to ssh into the TV from PC, and in attempting to I get a connection refused message.

root@OpenWrt:~# ubus call system board
{
	"kernel": "5.15.137",
	"hostname": "OpenWrt",
	"system": "ARMv8 Processor rev 4",
	"model": "Dynalink DL-WRX36",
	"board_name": "dynalink,dl-wrx36",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.2",
		"revision": "r23630-842932a63d",
		"target": "ipq807x/generic",
		"description": "OpenWrt 23.05.2 r23630-842932a63d"
	}
}


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 'ip6address redacted out of caution::/48'

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

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

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	option peerdns '0'
	list dns '9.9.9.9'
	list dns '149.112.112.112'
	option broadcast '1'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'
	list dns '2620:fe::fe'  ; this is quad9's ip6 address, it is okay to publish, it is not private info accidentally being published
	list dns '2620:fe::9' ; this is quad9's ip6 address, it is okay to publish, it is not private info accidentally being published
	option auto '0'

config rule6
	option priority '1'
	option action 'blackhole'
	option out 'wan'
	option dest '::/0'

config interface 'vpnclient'
	option proto 'none'
	option device 'ovpnc0'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'vpnStream'
	option proto 'none'
	option device 'ovpnc1'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'vpnTorrent'
	option proto 'none'
	option device 'ovpnc2'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'vpnstate92'
	option proto 'none'
	option device 'ovpnc3'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config device
	option name 'ovpnc3'
	option ipv6 '0'

config device
	option name 'ovpnc1'
	option ipv6 '0'

config device
	option name 'ovpnc0'
	option ipv6 '0'

config device
	option name 'ovpnc2'
	option ipv6 '0'


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

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi'
	option channel '44'
	option band '5g'
	option htmode 'HE80'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'myssid 5ghz'
	option encryption 'psk2'
	option key 'mywifipassword'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi+1'
	option channel '4'
	option band '2g'
	option htmode 'HE20'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'myssid 2.4ghz'
	option encryption 'psk2'
	option key 'mywifipassword'


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 cachesize '1000'
	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'
	list server '9.9.9.9'
	list server '149.112.112.112'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

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

config host
	option name 'PC'
	option ip '192.168.1.3'
	option mac 'redacted'
	option leasetime 'infinite'
	option duid 'redacted'

config host
	option name 'Phone'
	option mac 'redacted'
	option leasetime 'infinite'
	option ip '192.168.1.4'

config host
	option name 'raspberrypi'
	option mac 'redacted redacted'
	option ip '192.168.1.2'
	option leasetime 'infinite'

config host
	option name 'laptop'
	option mac 'redacted'
	option ip '192.168.1.5'
	option leasetime 'infinite'


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

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

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'
	list device 'ovpnc0'
	list device 'ovpnc1'
	list device 'ovpnc2'
	list device 'ovpnc3'
	list network 'wan'
	list network 'wan6'
	list network 'vpnclient'
	list network 'vpnStream'
	list network 'vpnTorrent'
	list network 'vpnstate92'

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 dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'redacted 4-digit hex prefix?::/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 include 'pbr'
	option fw4_compatible '1'
	option type 'script'
	option path '/usr/share/pbr/pbr.firewall.include'

To be clear, I would be able to fix everything and have to wait ~3 weeks to do a follow up if the Dynalink router was simply rebooted. That's what I did 3 weeks ago to fix it when I hit this issue. I'm going to try keeping it going as long as I can, and if the uptime stays >21 days and can resolve itself, cool. This is in part why I've waited months to post about it because I wanted to notice this pattern where we hit 20 days or 3 weeks mark (not quite sure what the earliest or average time of noticing the issue is) and be confident it wasn't a fluke.

When I first noticed this many months ago, I had been trying to ssh into the pi from my laptop and couldn't get in and did a series of tests seeing who could connect to who and basically found if A and B could talk, and C and D could talk, but A cannot get to C, then A could not get to D either and B could not get to C or D. It was as if they were on entirely different networks, or as if a virtual LAN is emerging spontaneously.

4

Sorry friends, I don't know what happened but maybe I can still get access to logs if someone points me in the right direction?

I had other network things I wanted to look at, some IoT stuff, and to help me try to identify stuff that has poor naming I thought I'd try a network monitor to maybe figure out which device is what IP. So I installed nlbwmon and the luci-app-nlbwmon, and some point after that, Plex was working on all devices and I could ssh from pc to pi and use vnc from phone to pi.

Maybe in the installing of a new service it also refreshed other network settings that de-segregated these unintentional lans back to the normal singular lan. I'll try to keep an eye out for if and when this acts up again and maybe can pinpoint something in logs at that point.

5

Well, it has reared its ugly head again.

Refer to the diagram above.
I have 5 primary devices connected to the OpenWRT router.
Pi, PC, Phone, Laptop, TV.
The connection we're interested in is every device should access the Pi at 192.168.1.2:32400 via a webbrowser to watch Plex on it.
As of Jan 6 2025, my PC cannot. My Phone cannot. My laptop can. My TV cannot.
I don't remember the exact date, but it wasn't log ago (less than a week) that I was using my phone to connect via VNC to get to a desktop view of the Pi to do power off commands so I could unplug its external hard drive. I cannot connect via VNC on Jan 6 2025 either. My method for shutting down the Pi is to use ssh via laptop. All of PC, Phone, and Laptop of course can access the OpenWRT router via browser.

What I am doing now is using ssh to shut down the pi via the laptop. And when the pi comes back up, I'll recheck every device trying to access plex on the pi.

I can confirm when I used sudo shutdown on the pi, it gave me a 1-minute shutdown time. The device became inaccessible via ssh as expected which, while given the nature of the original topic doesn't confirm it shut down, it likely did shut down.

Unplugging and plugging in the pi and giving it 2 minutes to get everything running, I now find these results:

PC can access the pi and plex webserver.
Laptop can (still) access the pi and plex webserver.
Phone can (still) not access the pi and plex webserver.
TV can access the pi and plex webserver.

As a bonus, Phone can not use VNC to get to desktop of the pi.

Is it a pi issue selectively blocking connections from different lan devices? Is it the openwrt not allowing the connections? Not sure, I don't know what logs to review. The System Log on openwrt is overrun by a VPN connection spamming replay warnings at up to 50 entries per second, and I don't know how to extract other logs or what grep may be useful to pinpoint the lan connections.

logread via commandline just shows the same content as the webui System Log page. My next step will be trying to resolve the VPN issue so it stops filling the logs up and maybe I'll have a chance at getting a diagnosis.

6

This is almost certainly a Pi issue, but I don't know what/why.

OpenWrt cannot effectively block any connections because you only have a single lan. All connections between devices in your lan happen at L2 (switching), so the firewall on OpenWrt cannot be involved since it only affects L3 (routing) connections.

That said, it would make sense to make sure you are testing with your Pi's IP address (192.168.1.2) and not a host name. This will ensure that it's not a DNS related issue.

1 Like
8

@Yusuf6411 - Are you using AI to generate these suggestions? I ask because they don't seem relevant to the issue at hand.

1 Like
9

Ah - it's a Dynalink WRX36.

You'll be needing to check the multicast-to-unicast option for your wireless networks. It's a known bug for this device and a fix is rolling through the kernel for it at the moment.