CSM, ASDM & FWSM versions

[Mel Popple]

Hi,

Can anyone explain the interaction between CSM, ADSM & the FWSM I'm trying to work out if there are incompatible combinations with various versions.?

It is my understanding that the CSM server makes a connection to port 443 on the FWSM so must be communicating with the installed ASDM version. We have a CSM 3.1.1 server & FWSM 3.1(4) installed, is there a specific ASDM version that should be installed on the FWSM when using CSM or can we just upgrade to the latest - the 6.1(x)F ASDM release notes says it is compatable with FWSM 3.1(4).

One of the reasons I am checking is that we recently had an issue where an ACL entry was not being match correctly and the packets were being discarded by an entry further down the list. Originally the offending entry had the subnet referenced by IP/netmask, we changed the entry in CSM to use an object group for the same subnet and pushed the policy, the ACL then behaved as expected. We then changed the ACL back to IP/netmask in CSM, pushed the policy and it carried on matching correctly.

During these changes the ACL order was identical and it wasn't anything complicated - the mask was a simple /24 subnet being referenced to allow a well known service port. We even have a test FWSM that is configured identically to the live one and the ACL worked fine on that during testing, the rules were copy & pasted from the test FWSM to the live FWSM in CSM.

We are upgrading CSM to 3.3.1 next week so hopefully won't see this issue again.

Regards

Mel

[Jennifer Halim]

ASDM and CSM are two different configuration GUI for FWSM.

1) ASDM can only manage 1 FWSM at a time, and configuration is pushed live from FWSM towards the ASDM GUI as you connect via ASDM. When you make changes on the ASDM, and click on "Apply", the configuration changes are pushed down to FWSM straight away.

2) CSM can manage multiple devices, ie: it can manage FWSM, PIX, ASA, IPS, router, switch, etc. It is a repository of all configurations. CSM works differently to ASDM. With CSM, configuration already exists in CSM, and when you make configuration changes on CSM, it does not get pushed down straight away to FWSM. It only gets pushed down, when you hit the "Submit and Deploy" and it compiles a configlets and pushes them down to the FWSM. CSM is out of band configuration deployment.

You can't use ASDM and CSM in paralel, because if you make changes in ASDM, the change got pushed directly to the FWSM. CSM will not have the configuration change that was performed through ASDM because CSM configuration is offline from the FWSM.

If you are managing configuration changes through CSM, you should only use CSM, and never make any changes through ASDM or FWSM CLI. If you make changes via ASDM or FWSM CLI, you would need to rediscover the policy on your CSM so CSM will have the latest configuration.

Hope that answers your questions.

[Mel Popple]

Thanks for the response.

I fully understand the differences between ASDM & CSM and how they should be used. As it is, we only use CSM to configure the FWSM but we log in using CLI for troubleshooting.

The question was asking how CSM talks to the FWSM using port 443. I presumed that when you upgraded the ASDM image on the FWSM this contained updates to the code that manages the incoming web connections on the FWSM i.e. fixed bugs, added functionality etc as well as updates to the software client that you can download.

If I connect to my FWSM from my desktop using https://myfirewall/admin/index.html I get a choice of downloading and installing the ASDM GUI or running the ASDM as a java applet. Either way there is some code installed on the FWSM that these connect to i.e. a server process listening on port 443. I presumed that CSM would use the same management connections to the FWSM that the ASDM GUI does, the only difference being that CSM is intelligent enough to connect to multiple security devices at once. Whether you hit 'Submit & Deploy' or 'Apply' in your chosen GUI front end, the changes are pushed as a group of CLI commands in one go.

Hence the original question about compatible code versions throughout the whole management chain. We have the FWSM software, we have the installed ASDM image on the FWSM module and we have the CSM software itself. All of which can be various versions and will contain capabilities and bugs pertaining to whatever version they are.

With the ACL issue that we experienced we probably would not have had an issue if we had used just the CLI to input the changes, or if we used just the ASDM GUI, but a combination of all 3 factors may have created the issue with the dodgy ACL. Currently our FWSM web interface states it has 6.1F installed (since we are due to upgrade to CSM 3.3.1 I will leave it be) but if we were staying at CSM3.1.1 I would probably look at reverting the ASDM image to an earlier version on the FWSM, the FWSM image itself will stay at 3.1(4) and hopefully with that combination not see the ACL issue again.

Hope that is a little clearer of what I am trying to understand.

[Jennifer Halim]

No, there is no connection between ASDM image (version) and CSM. CSM is not dependant on ASDM version at all. The only similarity between CSM and ASDM is both of them uses HTTPS (TCP/443) to communicate with the FWSM.

Again with your changes not done solely on CSM, the following might happen:

Assuming we have the following configuration on:

FWSM: access-list 101 permit tcp any any eq 80

CSM: access-list 101 permit tcp any any eq 80

Then, you made changes via FWSM CLI, or ASDM as follows:

FWSM/ASDM: no access-list 101 permit tcp any any eq 80

At this stage, CSM does not know about the above change. CSM still has "access-list 101 permit tcp any any eq 80" eventhough it has been removed through FWSM/ASDM.

Then, you decided to make the configuration changes on CSM now:

CSM: access-list 101 permit tcp any any eq 1200

When you hit "Submit and Deploy", it will push the whole access-list 101, and since "access-list 101 permit tcp any any eq 80" is still on CSM, it will get repushed to the FWSM along with the new access-list "access-list 101 permit tcp any any eq 1200"

So, now on the FWSM - you would have the following lines:

access-list 101 permit tcp any any eq 80

access-list 101 permit tcp any any eq 1200

while in fact, you already remove "access-list 101 permit tcp any any eq 80" through FWSM/ASDM earlier.

[Mel Popple]

Thanks for your help on this but as I state previously we ONLY use CSM to do configuration changes, we don't use the CLI or ASDM for this so we don't suffer the issues you describe. We do log on to the FWSM via CLI to issue debug, show commands etc. because you can't do this via the CSM interface.

I'm reasonably convinced that the ASDM version is irrelevant to my equations in figuring out why the ACL wasn't matching traffic correctly, hopefully we won't see it again after next weeks CSM upgrade to 3.3.1