Hi @steve6732 

Thanks for posting in our business forum.

Looks like the reset is the only way if the reboot does not work.

That means the file has been changed and you don't have the privilege to access or modify it.

You can try to use CLI and review the entries if there is any unknown values or parameters. Delete them and try again.

If that does not work, only resetting the system to the default would work. Recover the backup may still behave the same but it depends on what file went wrong.

Or if you have anything to add to explain what configs you have failed.

Hi @steve6732 

Thanks for posting in our business forum.

steve6732 wrote

  Hi @Clive_A 

 

Thank you for responding with suggestions.

 

I have better identified the problem and a work-around, but an undesired one.

 

With firmware 2.2.6, if the computer connecting to the ER605 V2 standalone web interface is not in the orginal subnet 192.168.0.0/24, then firewall access control entries can not be added or edited.

• After editing a new or existing access control entry, clicking OK responds with a popup "Invalid Parameter", discarding changes.
• The new IPv4/IPv6 selection does not appear when editing an Access Control entry.
• The new "Firewall / Application Control" does not appear.

 

I have not observed other affects.

• The problem occured every time when logging in outside the 192.168.0.0/24 subnet and never occurred when logging in from the 192.168.0.0/24 subnet.
• The ER605 web interface is accessable on the gateway address of each VLAN.  The VLAN accessed had no impact, only the address of the client with the browser.
• This problem did not occur with firmware version 2.1.2, the original as manufactured.

 

I prefer to avoid using the original 192.168.0.0/24 subnet.  It is the first place a person would look to find the router administration and can conflict when routers are nested.

 

How are bugs reported so this might be fixed in a future release?

 

I tried the CLI as you suggested.  I was able to add an access control entry from it, but it neither shows nor sets the rule "States" or the new IPv4/IPv6 selection.  The CLI does not support sufficient functionality.  Also, the CLI is implemented with a deprecated encryption of the host key.  The following option is required for openssh to offer use of this deprecated encryption.  This is not a serious issue for a connection within the local network but it is a waste of time resolving the connection problem.

 

       $ ssh 192.168.7.1
        Unable to negotiate with 192.168.7.1 port 22: no matching host key type found. Their offer: ssh-rsa

       $ ssh -oHostKeyAlgorithms=ssh-rsa 192.168.7.1

        The authenticity of host '192.168.7.1 (192.168.7.1)' can't be established.
        RSA key fingerprint is SHA256:Iz7wmu5fc0NlOS9JOSMamLBrajSX7WOaM5COBEQsIiM.
        This key is not known by any other names.
        Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
        Warning: Permanently added '192.168.7.1' (RSA) to the list of known hosts.

 

This does not sound normal if you describe that you have reset it and changed the subnet without any pre-existing ACL entries.

After you altered the subnets, without pre-existed ACL, it behaves like this? Is this what you are writing? At least, looks like what I am reading.

About what you described, just give me the screenshots or a video to show this. I find it hard to believe that it behaves so. The highlighted part.

The web is accessible on any VLAN, that's normal. Regardless of whatever the software you use, it is allowed by default. Unless a firewall is implemented to block 80 and 443.

SSH requires fingerprint records, you can use Putty or other software. For the command prompt on Windows, you might need to clean the fingerprint later on if you need to access a different device with the same IP. I don't see this as posing a threat. At least on the various open source systems, Openwrt and varients I have tested, this is the normal popup message.