Miising alias description

[advcron]

After upgrade to 18.7 alias description/detail is missing (in attach).
But in configuration backup exist.

Code: [Select]

    <alias>
      <name>FQDN_CRL</name>
      <type>host</type>
      <descr>Adresy List CRL ocsp</descr>
      <address>crl.certum.pl ovcasha2.ocsp-certum.com tg.symcd.com tg.symcb.com gj.symcb.com gj.symcd.com repository.certum.pl crl2.alphassl.com ocsp2.globalsign.com crl3.digicert.com crl4.digicert.com ocsp.digicert.com cacerts.digicert.com</address>
      <detail>CRL Certum||OCSP Certum||OCSP Thawte||CRL Thawte||CRL GeoTrust||OCSP Geotrust||CERT Info Certum||CRL GlobalSign||OCSP GlobalSign||CRL DigiCert||CRL DigiCert||OCSP Digicert||Wystawca Digicert</detail>
    </alias>

This is Bug ?
This field was very helpfull to identify specific entry.

[franco]

https://forum.opnsense.org/index.php?topic=9280.0

specifically:

o In preparation for the firewall alias API the per-item descriptions have been removed along with support for the deprecated types urltable_ports and url_ports.

[advcron]

OK. I understand.
Will there be any tool for identifying alias entries?

For example, I have 10 ip addresses in host alias, and I would like to now which workstation has certain address.

[franco]

We've discussed how we can retain this, but were unable to find a useful way.

What you can do is nest your aliases by creating single aliases for your devices with a unique description, then merge them into another alias by typing the alias name of the individual ones instead of providing addresses, e.g.

Alias 1: 10.0.0.1 Host 1
Alias 2: 10.0.0.2 Host 1
Alias 3: Alias 1, Alias 2


Cheers,
Franco

[advcron]

Yes. I also think this is only way.
But I notice one issue:
When you have this "Alias group" and rename individual host alias. In alias group name chaged. This is correct.
When you delete individual host alias, the entry in alias group not delete. This is not correct.
@franco I don't now it is possible to prevent from delete "individual host/port alias, when it use in alias group or delete this entry in alias group.

[RGijsen]

Ouch. We are doing in test a migration from pfSense to OPNsense, but this might very well be a deal breaker for us. We have several aliasses like 'IMAPS hosts required by customers' with several IP's in them. In the description we store for which customer it actually is. This prevents us from creating a seperate firewall rule for each IMAPS connetion in this example. However, now OPNsense is unable to show the descriptions (they are still in our config file by the way) it makes it impossible for us to distinguish which IP or 'random' hostname belongs to which customer.

Nesting aliases gets extremely dirty very quickly. Having read the release notes, I still don't understand why the descriptions are deprecated now?

What is / will be the replacement? Is this final?

[franco]

Yes, it is final.

[RGijsen]

Hmm. And what's the reason behind dropping that functionality? Really trying to understand why such changes are made. Don't pretty much all users want descriptions in their aliasses? How could one ever keep track of what's in otherwise?
I'm just trying to be constructive and understand how to use OPNsense opposed to pfSense.

[AdSchellevis]

plain and simple, if it's an entity worth describing, treat it like that. create an alias, and bundle sets of aliases for the firewall rule you want to create.
This is pretty standard in a lot (most?) firewall systems.

In detail:

Code: [Select]

client_1_machine_a  [192.168.1.100]
client_1_machine_b  [192.168.1.101]

client_1_all_machines [client_1_machine_a, client_1_machine_b]


[RGijsen]

Hmm ok. Well I fully understand adopting to whatever new software takes time to get used to it, and we certainly should expect 1:1. However, I must say I still can't understand this move. Forcing us to create nested aliasses makes for twice as many work when creating one (first create an alias for a new FQDN, THEN add it to another alias), as well as it consuming more resources, even though if it's measured in bytes rather than kilobytes or megabytes even. But the most important issue I have with it is that is certainly adds unnecessary complexity to the aliassing. Our list would expand from about 150 aliasses to over 500 because of this. And we are a just a small shop.
I'll try to get myself over the point to accept this.

[franco]

Thanks for your consideration.

Over the years we have had to make a choice: listen to the users that we have or listen to potential users who only miss this one feature X. We choose to listen to the former group as that is the one we can depend on. And we also like to build solutions for them, not only take things away.

Maybe this is a little harder to understand as an outsider. We have no reason for your trust yet.


Cheers,
Franco

[RGijsen]

I'm trying not to clutter the forum too much by posting another thread. I've been looking in the documentation but can't find an answer there, in fact, the word 'flush' doesn't show up when searching.

I'm working on those aliasses, but also testing some things to get a grip on OPNsense. Say I erroneously flushed an alias table. How can I re-populate that? When I add something to the alias, the added host ends up in the table, but the existing ones (which I flushed) don't. Is there a way to repopulate them?

[edit]
you just replied so I'll discuss that as well:

Thanks for your consideration.

Over the years we have had to make a choice: listen to the users that we have or listen to potential users who only miss this one feature X. We choose to listen to the former group as that is the one we can depend on. And we also like to build solutions for them, not only take things away.

Maybe this is a little harder to understand as an outsider. We have no reason for your trust yet.


Cheers,
Franco

Ok, fully agree that existing users are somehow more important than new / not existing ones. Still, I don't see how anyone would want those descriptions to be dropped completely? If you don't like 'em, don't use 'em, and if you do like 'em, DO use 'em. Sorry to be an @ss about that, but I still don't see the point in removing them. Did people explicitely ask to remove a descriptive field?

Yet, I don't like dumb work. So I'm trying to build me a script that generates me an alias.xml with nesting I can import, rather then go through them one by one.

[AdSchellevis]

We've rebuild the feature from the ground up, which has many advantages (api support, less fragile loading, ..).

It's not a matter of removing something as it is to fit the most important use-cases when building new software. (addresses + descriptions don't fit the ui model and would complicate our data model, since in the end, it would always be separate entities).

There are always manners to improve input, we likely will add some kind of import export feature at some point in time. How it works under the hood won't change (for reasons explained)

Scripting to push aliases is pretty easy, as mentioned before, our new components always are api enabled.

[fmaxwell]

Over the years we have had to make a choice: listen to the users that we have or listen to potential users who only miss this one feature X. We choose to listen to the former group as that is the one we can depend on. And we also like to build solutions for them, not only take things away.

I was an OPNsense user and I never saw a poll asking if I would be okay with losing countless alias item descriptions I had entered.  Had I seen such a poll here, I would have registered at the time to voice my objections.

I had blacklist aliases I developed to protect our servers, with descriptions that included type(s) of abuse, whether the entry was to be permanent or temporary, and what ISP/organization owned the IP block.  Without those descriptions, it became all-but-impossible to maintain those aliases.  That's why I went through the extremely time-consuming process of migrating back to pfSense.

Imagine if you updated to a later revision of your IDE (integrated development environment) and all of the comments were stripped out of your source code.  That's what it was like.  My well-documented aliases turned into the firewall equivalent of source code with all of the comments and line breaks stripped out.

plain and simple, if it's an entity worth describing, treat it like that. create an alias, and bundle sets of aliases for the firewall rule you want to create.

That's as silly as saying that if a line of C is worth describing with a comment, then it should be worth putting into its own standalone file that you can #include into the parent source file.

I hope that the OPNsense developers reconsider the decision to remove the alias item description from the web GUI.  Its removal might not bother a hobbyist using OPNsense to implement a simple home firewall, but it's a serious blow to many of us trying to maintain OPNsense firewalls on networks with multiple servers, multiple WANs, and large aliases used to block malicious traffic.

[franco]

As previously stated the core team will not spend time bringing the feature back. The time is better spent elsewhere.


Thank you for your understanding,
Franco