Showing results for 
Search instead for 
Did you mean: 

RV340 and RV160W SCHEDULED firewall rules don't work

Level 1
Level 1

I administer three RV340s.  They're all running firmware   This fault has been observed in every RV340 I've tested, on this point: i.e., two.   I say it's a bug in the firmware of the RV340.    Moreover, this bug does not exist in the RV160w, of which I have also recently ONE unit.       (Correction, Nov 30, 2020; see below.)

NO problem if a firewall rule is set for ANYTIME.   But if I schedule a firewall rule to START and END periodically, the START fails.  The END succeeds.

You can duplicate this test by having two IPv4 hosts, connected to an RV340 router; each host connected to a LAN port on the back panel of RV340, while each of those LAN ports is UNTAGGED to a distinct VLAN.   Thus the hosts are addressed by different IPv4 subnets.  The RV340 is used for OSI level 3 communication between the two subnets; this happens if an ALLOW construct is established in the firewall. 

Then ping from the VLAN1 host (I used a Windows 10 computer) to the VLAN2 host (I used a Synology NAS).   

The fault manifests when a temporary firewall condition is supposed to START.    I used, variously, ALLOW and DENY rules, but mostly DENY was used for the temporary rule. 

I hope Cisco reads this posting and fixes its firmware.

Thank you.

See frame grabs, annotated, from my testing.



11 Replies 11

Martin Aleksandrov
Cisco Employee
Cisco Employee

Hello  Hohn,


Have you checked your Router system time?





At first I was off by an hour, by reason that these routers failed to
automatically change from PDT (Pacific Daylight Savings Time) to PST.  I
thought that was my Eureka moment but I was soon disappointed to
discover that, even with the time corrected, the bug persisted.

I started this examination by attempting SMB shares.    I distilled my
experiment ...simplified it... to PING tests, in the hope that the
firmware authors at Cisco would replicate my experiment, and fix the bug.

Thank you for your response.

Hello John,


Thank you for your prompt reply!


We've seen this occasionally happen when implement deny access rules related to Internet traffic and using the schedule. Please do open a tech support ticket so we can gather and record all the data for the issue. Meanwhile, we'll contact the corresponding team to further investigate the problem. Cisco STAC support center contact details are as follows: 




Hi Martin,

Thanks for the reply and the recommendation  to open a case.   I've never done that before, and I hit a dead end when I followed what seemed to be the right pathway.    See screen grab; notice the grey (inaccessible) screen button.   What am I doing wrong?  Cheers!

open a Cisco 'case' dead end.jpg

Hi John,


Please try with another browser and/or delete/clear cookies and cache. If you are still facing the issue please reach out to our network engineers by phone using STAC contacts: 




Thank you, Martin, for the encouragement.    I don't have a service contract with Cisco, so initiating a case is impossible online.  But someone took my phone call and started a case.   I have already uploaded introductory information, pertinent to alleged firmware bug, as shown in this thread.

I will follow up in this thread to describe resolution.   It might take a few days... or a few months... I don't know.

Hi John,


Thank you for your feedback. We'll be expecting the resolution of this case.




It's very satisfying to know that my "problem" has been accepted, and moved up the ladder, by one of the world's premier corporations, even though I don't have a service contract.    I am a small fry consulting engineer with big responsibilities to small businesses who depend on my keen oversight, topological engineering, and manipulations from afar.    I rarely visit my customers' sites, but interact nightly by use of site-to-site IPSec VPNs between my home office and their business locations, in the Los Angeles metro area.    These businesses do not use "domains" in the Microsoft sense.  They do have peer networks.  They are highly modularized.    They enjoy site-to-site VPNs.   Employees are thus able to work at a downtown office, or from home.   We eschew "cloud storage" generally, and favor ownership of all equipment, by businesses.   Redundancy is commonplace.


At this time I will volunteer the reasons why "scheduled firewalling" is important to me... and possibly to other small business owners who read this.   Though other innovations might follow, the primary need is to facilitate reliable work data BACKUP, scheduled during non-business hours when all is quiet, data-wise.   My scheduled backup software comes alive and does what it is supposed to do.   The problem is that my workers habitually walk away from their desks, at the end of each work day, with applications open and ... data files open.   


While modern backup software succeeds (but not always), regardless of a data file's state of openness, I long for the older-fashioned method of disconnecting workers from file servers, on schedules.   A backup thus has monopolistic access to a file server during backup operations, and my workers return the next business day and pick up as if nothing happened.    Meanwhile, I receive e-mails from backup softwares at completions of jobs, reporting status... PASS or FAIL.   This is oversight, from afar.


Why not rely on said "FILE SERVER" for such time windowing?  ... you ask?   Because I moved away from file-server operating systems... a fixture of 1990s and 2000s mentality.   I choose to rely on ROUTERS instead of clunky, expensive, unnecessary FILE SERVERS, for my system control.    My boxes are smaller, now.  They work faster.   Instead of relying on big boxes that hum and throw lots of hot air, that employ inefficient general purpose CPUs and software, I rely on smaller, faster, lighter boxes that employ special purpose computer architectures (hardware + firmware) that run faster, and cooler.   My various boxes can be physically installed much more conveniently, inconspicuously, and safely, than, say, Dell mini-tower computers.     Configurable routers receive firmware updates, from a manufacturer, all of which is much simpler, smaller, and less frustrating than horrendous "Microsoft service packs."     


Computers are now cheap, replaceable, and nothing to depend upon.   I don't even have to visit the customer site, on those rare occasions when things go wrong.   I pick up the telephone and have my customer swap a box, about once every two years.


This preference comes from a senior engineer... a hardware and firmware veteran.     I also wear a hard hat and pull cable!   I understand that CABLES, though simple, are valuable, while BOXES, though complex, are cheap, and replaceable.  It's about replacing file server operating systems with routers.   And enjoying old fashioned scheduled access to file servers.

I have the same problem 

Firmware Information 
Firmware Version:
Current Time:2022-May-30, 22:56:55 CST

Level 1
Level 1

I have experimented with a new RV160W router (firmware version and observed the same failures as found in the RV340.   I have added this observation to my open case, with Cisco engineering, and mention it here for general readership interest.