Object resolution

Unanswered Question
May 25th, 2008

Here is row syslog msg example:

"<164>May 25 2008 18:30:29: %PIX-4-106023: Deny udp src RET-inside:RETSEAP002V/137 dst RETREBRAND-AD:pobdc005/137 by access-group "RETREBRAND-AD_access_out" [0x0, 0x0]"

I want to track such connections: for example, in case when a customer need an access to some resource from inside to DMZ or...whatever. I can query on demand or just create a rule which will "make" incidents. Also, I have CSM plugged with MARS. But MARS tracks such events (syslog entries) as unresolved. Here what I mean: the SourceIP and DestinationIP showed as Policy Table Lookup process becomes impossible - the CSM icon "Policy Query" (looks like crazy planet:) ) is not showed.

Is it possible to resolve this issue in next realises? During device discovery (analyzing config file) MARS can resolve such objects into real IP addresses (or at least resolveble domain naims) and tracks it correctly.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Farrukh Haroon Mon, 05/26/2008 - 21:58

You post is a little cryptic, but I am assuming you are talking about the 'name' command in PIX/ASA/FWSM?

We faced the same issues on our network, MARS was unabled to understand the name command referenced in our ACLs and it would show instead of properly resolving the name to IP (from the firewall configuration). It also has similar issues with Netscreen Addresses (when defined as names).

I hope this is on the feature roadmap.



zarathushtra Tue, 05/27/2008 - 04:53

>You post is a little cryptic, but I am assuming you are talking about the 'name' command in PIX/ASA/FWSM?

Yeap:)...exectly - you've got the msg. Hope this will be resolved next update))) Wouldn't it?

The reason why should it be fixed - becouse using CSM/ASDM/SDM you can easy manage (reuse) your named objects (like CheckPoint do). I also hate any GUI tools...but in enterprise environment it brings some benefits.

jeff_groesbeck Wed, 07/30/2008 - 09:43

I'm digging up an older post here, but this thread helped me resolve a problem I was having in MARS. I was starting to see the same messages with the src and dst events when they all used to read the correct IP addresses. Turned out that another admin had just 'named' all of the devices we had. I don't have the Topology/Monitored Device Update Scheduler configured to automatically update and was therefore not getting the current configuration of the ASA into MARS. Once I 'discovered' the ASAs again, the resolution worked properly and I had my IP addresses again. So, this can be remedied by 'discovering' the ASA again when a change is made to the names. It will also be applied during a scheduled Topology/Managed Device update.

Thanks again,


Farrukh Haroon Wed, 07/30/2008 - 15:23

Jeff, for us we never changed our name entries since months (since MARS was installed), yet it seems it cannot gather the entries properly from the FWSM.



jeff_groesbeck Wed, 07/30/2008 - 15:47

Hello. What versions of MARS and FWSM are you running? I can try to test it later to see if it's working against an FWSM I have access to.



Farrukh Haroon Wed, 07/30/2008 - 15:57

MARS 4.3.4

FWSM 3.1(4) (will check and update later, don't remember exactly)



i was wondering if this is related to name command in PIX/ASA/FWSM, then why am i getting the same as i have just added 2 4500 cat switches to MARS...I get this..

Session ID: S:272258477



Event Types:

Inactive CS-MARS reporting device

Pardon if this is ir-relavant to ongoing discussion.

Farrukh Haroon Wed, 07/30/2008 - 23:25

Dear Mohsin, it is not just the name command.

There are many other events that cause the 'zero' thing. For example summary events generated from IPS signatures also have no IPs. Similaly some PIX/ASA syslogs have port as 0. On this particular MARS, it was the name command (this can easily be veriifed by looking at the 'raw event' which is present in each inident).




This Discussion