[SOLVED] All Aliases Missing - Still Visible in Rules but Not Editable

[TheLatestWire]

Hi,

All my aliases in Firewall/Aliases are missing.  I know that I have a number of aliases.  I can still see that they are applied by looking at the Firewall/Rules.  I see them in there, but if I click to Edit one of the aliases in Firewall/Rules, it just takes me back to a blank aliases page.

Any thoughts?  I'm running 18.7.6-amd64.

Here's what I'm seeing:
https://imgur.com/a/kuLFrP7

I'd be grateful for any thoughts, insight or assistance as I need to edit one of the Aliases.

Thanks,
ObecalpEffect

[franco]

Can you post your output of:

# /usr/local/opnsense/mvc/script/run_migrations.php

And if there is an error for the aliases sticking out the relevant system and configd log?


Thanks,
Franco

[TheLatestWire]

Hi Franco,

Here's the output of run_migrations.php:

root@OPNsense:~ # /usr/local/opnsense/mvc/script/run_migrations.php
Keep version OPNsense\CaptivePortal\CaptivePortal (1.0.0)
Keep version OPNsense\Cron\Cron (1.0.1)
Keep version OPNsense\TrafficShaper\TrafficShaper (1.0.2)
Keep version OPNsense\IDS\IDS (1.0.1)
Keep version OPNsense\Proxy\Proxy (1.0.1)
Keep version OPNsense\Diagnostics\Netflow (1.0.0)
Keep version OPNsense\Backup\NextcloudSettings (1.0.0)
Migrated OPNsense\Routes\Route from 0.0.0 to 1.0.0
*** OPNsense\Firewall\Alias Migration failed, check log for details
Keep version OPNsense\Monit\Monit (1.0.4)


Looking at the system log in the gui, I see this:

Nov 2 18:58:38    config[46641]: Model OPNsense\Firewall\Alias can't be saved, skip ( Phalcon\Validation\Exception: [OPNsense\Firewall\Alias:aliases.alias.e95d51f5-6a2c-44e6-9c26-1dc5bd3c046a.content] Entry "212.227.0.0/16" is not a valid hostname or IP address. [OPNsense\Firewall\Alias:aliases.alias.e95d51f5-6a2c-44e6-9c26-1dc5bd3c046a.content] Entry "213.165.64.0/19" is not a valid hostname or IP address. in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:538 Stack trace: #0 /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php(645): OPNsense\Base\BaseModel->serializeToConfig() #1 /usr/local/opnsense/mvc/script/run_migrations.php(56): OPNsense\Base\BaseModel->runMigrations() #2 {main} )
Nov 2 18:58:38    config[46641]: [OPNsense\Firewall\Alias:aliases.alias.e95d51f5-6a2c-44e6-9c26-1dc5bd3c046a.content] Entry "213.165.64.0/19" is not a valid hostname or IP address.
Nov 2 18:58:38    config[46641]: [OPNsense\Firewall\Alias:aliases.alias.e95d51f5-6a2c-44e6-9c26-1dc5bd3c046a.content] Entry "212.227.0.0/16" is not a valid hostname or IP address.

Those look like valid CIDRs to me, unless they are actually wrapped in quotes, or were entered or are listed as hosts rather than networks, but I would think I would not have been able to enter them in the first place if there was an issue with them.

Is there a file that would allow me to edit the aliases to clean out offending entries that might be causing an issue?

Thanks,
ObecalpEffect

[franco]

Maybe the previous validation was faulty? The new one isn't.

Can you edit /conf/config.xml and remove / edit these offending entries?

After that migration should work ok and the new alias dialog will be populated.


Cheers,
Franco

[TheLatestWire]

Thanks for the help Franco.

Looks like the offending alias was originally entered and accepted as a host, but it should have been a network(s).

This was the problematic section of /conf/config.xml:

    <alias>
      <name>WebDe</name>
      <detail>Entry added Sun, 20 Mar 2016 18:52:05 -0500||Entry added Sun, 20 Mar 2016 19:45:47 -0500</detail>
      <address>212.227.0.0/16 213.165.64.0/19</address>
      <type>host</type>
      <descr>web.de</descr>
    </alias>

I then changed it to this:

    <alias>
      <name>WebDe</name>
      <detail>Entry added Sun, 20 Mar 2016 18:52:05 -0500||Entry added Sun, 20 Mar 2016 19:45:47 -0500</detail>
      <address>212.227.0.0/16 213.165.64.0/19</address>
      <type>network</type>
      <descr>web.de</descr>
    </alias>

I then re-ran /usr/local/opnsense/mvc/script/run_migrations.php:

Keep version OPNsense\CaptivePortal\CaptivePortal (1.0.0)
Keep version OPNsense\Cron\Cron (1.0.1)
Keep version OPNsense\TrafficShaper\TrafficShaper (1.0.2)
Keep version OPNsense\IDS\IDS (1.0.1)
Keep version OPNsense\Proxy\Proxy (1.0.1)
Keep version OPNsense\Diagnostics\Netflow (1.0.0)
Keep version OPNsense\Backup\NextcloudSettings (1.0.0)
Keep version OPNsense\Routes\Route (1.0.0)
Migrated OPNsense\Firewall\Alias from 0.0.0 to 1.0.0
Keep version OPNsense\Monit\Monit (1.0.4)

Now all the aliases are again visible in the web gui and are editable.

Many thanks for the help and the incredible work you and all the developers do on OPNsense 

ObecalpEffect

[franco]

Hey ObecalpEffect,

Glad to hear this worked! So war we are happy with the alias API transition. First try was held back over quality concerns, second time was pretty good. Even the later addition of the fallback seemed to work fine for you (not in the GUI, but still in the rules).

Clever fix changing the alias type to the correct one.


Many thanks,
Franco

[mfle]

Hi,

solved similar problem after reading this post:

config[61081]: [OPNsense\Firewall\Alias:aliases.alias.aad468bd-fdcb-4c4e-95ae-9a94a6ad80e1.name] Reserved protocol or service names may not be used
config[61081]: Model OPNsense\Firewall\Alias can't be saved, skip ( Phalcon\Validation\Exception: [OPNsense\Firewall\Alias:aliases.alias.aad468bd-fdcb-4c4e-95ae-9a94a6ad80e1.name] Reserved protocol or service names may not be used  in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:538 Stack trace: #0 /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php(645): OPNsense\Base\BaseModel->serializeToConfig() #1 /usr/local/opnsense/mvc/script/run_migrations.php(56): OPNsense\Base\BaseModel->runMigrations() #2 {main} )

Changed alias name "rdp" in /conf/config.xml
Now aliases are back 

Thanks!

Max

[Andreas_]

I got the very same problem, but the message just couldn't imagin which alias might be the faulty one.
I extended the message "Reserved protocol or service names may not be used" to include the name, and thus found out that 'sieve' and 'mysql' are forbidden.

I suggest extending that error message in upstream as well.