PDM vs ASDM

cisco_moderator · ‎10-23-2007

We previously used PDM for PIX version 6 to manage firewall NAT and access rules. From version 7 they introduced the ASDM interface and we would like to take advantage of the new features.

Previously in version 6 we would define a static (inside,outside) NAT and create a corresponding access rule to permit access from the outside (typically to permit remote support from a software supplier - RDP / pcAnywhere for example.)

This would result in the following config:

static (inside,outside) 10.20.30.111 192.168.1.1 netmask 255.255.255.255

The access rule entered into PDM would permit access to the inside address. (See attachment)

PDM with version 6 was intelligent enough to adjust the access-list command accordingly for the outside NAT address:

access-list outside_access_in extended permit tcp 10.20.30.0 255.255.255.0 host 10.20.30.111 eq 3389

Note the destination host has been replaced with the valid outside NAT address - even though the inside name was specified in PDM.

Unfortunately in version 8 this is not the case. If you permit access to an inside name via ASDM - even if a valid (inside,outside) NAT is present the access-list command it not adjusted:

access-list outside_access_in extended permit tcp 10.20.30.0 255.255.255.0 host 192.168.1.1 eq 3389

Any suggestions would be appreciated.

Paul

pjhenriqs · ‎10-23-2007

ASDM works a little differently (it's not that is not intelligent enough).

If you want to enable access to an internal host then you configure the access-list to allow access to its NATed address, not the internal.

For example:

instead of

access-list outside_access_in extended permit tcp 10.20.30.0 255.255.255.0 host 192.168.1.1 eq 3389

you have:

access-list outside_access_in extended permit tcp 10.20.30.0 255.255.255.0 host eq 3389

Is this what you mean?

cisco_moderator · ‎10-23-2007

Yes thanks - thats exactly right.

It just seems strange that such a handy feature has been removed. It seems a backwards step to me.

Unfortunately I have configured network groups containing inside addresses. It seemed logical to group inside and outside network groups...

So you would permit access from an "outside-group" to an "inside group"

It would then be PDM's job to recognise if an (inside,outside) NAT was in place an amend the config accordingly.

In fact PDM used to create reference groups to tie the two together...

For example, you permit access to an inside group:

object-group network INSIDE-SERVERS

network-object 192.168.1.1

network-object 192.168.1.2

network-object 192.168.1.3

And PDM automatically creates a "reference" (_ref) group that uses the valid outside NAT addresses:

object-group network INSIDE-SERVERS_ref

network-object 10.20.30.1

network-object 10.20.30.2

network-object 10.20.30.3

The group ending in "_ref" is the one used in inbound access-lists.

Thanks,

Paul

pjhenriqs · ‎10-23-2007

To be honest I have began learning these things with ASDM so I kind of got the inverse reaction to PDM.

For me it seems logical that you allow traffic to the outside address, because I see things as interface related. First you allow traffic to the outside interface then we translate it to the inside and that's it. It's just a matter of what you are used to I think.

I don't know if Cisco has some kind of translator for the configs, but it might be worth checking that out. I'll be honest, I have done all the migrations manually.

Regards,

Paulo

cisco_moderator · ‎10-23-2007

Many thanks Paulo,

I guess I have two choices - redesign my groups to focus on the outside NAT addresses - or stick with V6 and PDM. I guess I have just had it easy with V6! Another big concept change for me was the removal of the PDM location feature.

With PDM objects have a location associated - for example you define a host / group - and you are asked where it resides (inside or outside for example). With ASDM all object are placed in the same place. It has no concept of location. I guess this is the root cause of my problem.

Maybe I will stick with V6 after all...

Thanks for your time.

Paul