mgoldey - Thanks for posting your question on the forum.
To be honest, I would pay less attention to the part you have in bold and more attention to the message that it is showing. In the example above, the message states "Connection closed. Bytes transferred" This means that a TCP session was opened and data was transferred and now that TCP session has been closed. This is not a warning, but more of an informational message that is being reported based on your event-history settings.
Information regarding firewall events and what certain attack messages may mean can be found in the appendix of the document below:
Please do not hesitate to let us know if you have any questions.
I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post to unmark it and select another in its place with the applicable buttons. If you have any additional information on this that others may benefit from, please come back to this post to provide an update. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
To be frank, Noor, your response is unhelpful and patronizing. It assumes that my question isn't really what I want to know (patronizing), and that I really want to know something else that I didn't ask (unhelpful). It assumes that I don't know how HTTP works, what a firewall does, or that I have any skill to determine why the firewall would tear down a connection when a rule is triggered. (Also, patronizing.)
Then you provide a link to information that doesn't answer my question. (Unhelpful.)
This is very frustrating.
What I really don't know is AOS. But I spent a lot of time going through online manuals looking for firewall diagnostics, CLI commands, etc., and turned up nothing except other people asking similar questions. Probably, that's because because translating log results back into firewall rules is undocumented.
Since I'm not the only person who has wondered how to do this, I'll reiterate the question: how does one translate a reference in the firewall log (in this case, "pri=6 rule-4") to the firewall rule itself. You know, something like: go to the console and type this command _________. But if you can't do that, and your job requires you to say something, at least say "I don't know."
1 of 1 people found this helpful
I'm not sure about the history on this or past experiences, so I want to carefully avoid the frustration part of your message. I will say that I've had the privilege to work with Noor on several occasions and she's been great. Noor's original answer was helpful; at least I learned something, though it didn't seem to provide the info you were looking for. If you have an important issue you need to figure out quickly, it may be best to call and open a ticket--I'm sure you know this, just mentioning for future readers that the Support Community, while a fantastic supplement, isn't intended to be a replacement for official support channels. I hope your experiences moving forward will be more satisfactory. ADTRAN takes your feedback seriously.
I found that rule=4 pertains to the fourth policy in your configuration. Look at your Private and Public policy-classes (or whatever you name them). Combine their allow/discard/nat lines into one contiguous list. Go down the list to the fourth overall policy (and maybe look at its corresponding ACL).
noor: Can you explain the pri=6 part? The document you linked describes priority 0-5, with 5 being the most verbose (least severe), related to the event-history priority command. What does 6 mean?
1 of 1 people found this helpful
First off, I want to apologize for the way my post came off. It was certainly not my intention to come off in such a manner. I will do my best here to answer your question.
As cj! mentioned, the "rule" is an ID for the policy-class entry. However, this may not be the index as seen in the configuration as internal reordering may assign a value that differs from what you and I see.
The "pri" value is an internal number that relates back to the priority of the message. The values range from 0 to 7, but does not map directly to the syslog levels. Below is how the priority values can be interpreted:
These fields relate back to "WELF" message formatting (WebTrends Enhanced Log file Format). Here is a link that has more information regarding the fields that are specified using this format: https://www3.trustwave.com/support/kb/article.aspx?id=10899
I hope this helps in answering your question. However, please do not hesitate to let us know if you have any further questions.
I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it, and select another in its place, with the applicable buttons.