I'm running 3.2(6) and having the same problem.

I've just added "inspect dcerpc" to the default inspection class map.

sh service-policy lists:

"Inspect: dcerpc, packet 17017069, drop 11825, reset-drop 0"

I really don't want to have to open all the ephermal ports to the server.

Anyone have a fix or workaround (I've tried using an established command but no luck there)?

CSCsx26083 resolved in 4.1 ENH: FWSM DCERPC inspection doesn't support 'Remote Create Instance' msg

4.0.1 release notes:

I am not sure what the reason is to see the drop in the sh service-policy.

If you are open to upgrade I'd suggest an upgrade to 4.0.8 and test otherwise,

we need to collect debug dcerpc packet

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/d1.html#wp1722034

If you could open a TAC case that would be better for this issue.

-KS

kusankar wrote:
CSCsx26083 resolved in 4.1 ENH: FWSM DCERPC inspection doesn't support 'Remote Create Instance' msg
CSCsk34368
#
Inspect DCERPC failure. Packet too small error - resolved in 3.2.3
4.0.1 release notes:
DCERPC inspection enhancements
#
Numerous enhancements were added.
#
You can now use an inspection policy map to configure special actions for inspection traffic; this method replaces the application map.
I am not sure what the reason is to see the drop in the sh service-policy.
If you are open to upgrade I'd suggest an upgrade to 4.0.8 and test otherwise,
we need to collect debug dcerpc packet
http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/d1.html#wp1722034
If you could open a TAC case that would be better for this issue.
-KS

Thanks,

I'm in dependancy hell right now as we're also starting to implement CSM so I have to ensure the code on my firewalls meet the supported versions in CSM.

Right now I'm just having problems with a Archiving service but we're staring to move Exchange 2007 mailbox and CAS servers behind this firewall so I really need to get this working as I'm not keen to open all the ephermal ports.

I'm a little leery of turning debug on on this firewall during working hours as it is in our data centre.  I'll run the "debug dcerpc events" and use "logging buffered" and "logging ftp-bufferwrap" so I can capture the output and see any error messages pertinant to the service we are having problems with then open a TAC case.

Regards, The Grumpy FW administrator

Yes. That is a better idea.

Remember they would need

debug dcerpc events

debug dcerepc error

debug dcerpc packets

-KS

Sigh,

I miss my direct TAC access.

Finally after three weeks of dealing with a PICA I was asked for a sh tech so I know they have finally escalated it to the TAC.

Latest suggestion is to try 4.1(1) but it seems to be reloading the FWSM every 15 minutes

Good thing my very nice Support Engineer at the local Cisco Office lent me a FWSM so I'm not irritating my clients using services in the Data Centre. - Thanks Louis!

I think we're getting closer ....

Sometimes you'd just like to meet these application developers and ask they just why, with 64534 ports available, they felt the need to use RPC.

The even Grumpier Firewall Administrator

I just got done decoding the crash.  Seems like a new one to me.

-KS

Hmm,

Perhaps I should sign a NDA and join the Beta Testing crew

Thanks for your help

Did 4.1.1 resolve the inspection issues and opens pin holes as expected?

-KS

We didn't have time to test that as the System Admin had to leave for a meeting.

I sent the syslog output (with the debug o/p from dcerpc) to the Partner and that looked promising with respect to other services (AD, Exchange & SQL) as I was seeing more pinholes for those than in the past but I'm getting weird IPv6 messages even though the Sys Admin assures me that the IPv6 Stack is disabled.

"DCERPC-ERR: Unrecognized address/port format. Supports only IPv4 address. Skipped pinhole creation and translation for this address"

Rumour has it that to completely kill IPv6 on Server 2003 you have to apply registry hacks.

God Bless Microsoft - they keep me employed.

There is also some RFC3550 addresses floating around so I'll have to have a look at the system further.

Yes,

I am happy to report that the bugfix 4.1(0) 18 code we received did open the Pinholes as expected for the Symantec eVault Archving service.

So the test was a sucess but we decided to stick with the 3.2 code for now and take other steps to mitigate the risk until the 4.1 is a little more mature and is supported by CSM.

Thanks to the TAC for all their help.

Glad to hear. Arturo relayed it to me yesterday.

Hope you are not "grumpy" any more

-KS

Well ...

I'm opening another TAC case.  Our Primary FWSM in the DataCentre spontaneously reloaded last week!

I know what triggered it (probably) - rolling out a new Nessus server on a dual quad-core processor with a GigE connection then pointing it at an Exchange server turned out to be bad for the Exchange Server and worse for the firewall.

Thank goodness the failover worked!

So we finally bit the bullet and upgraded to 4.1(7).  The DCERPC inspection appeared to work for that traffic which we noted previously was broken.  Only problem is that WMI queries which used to work are now broken.

Opened a case with our PICA back in December and still haven't heard back from them.  So we have DCERPC disabled and a buch of ephermal ports enabled.  Sigh.

Hopefully the support folks will eventually escalate this to the TAC so we can get some resolution.

Still Grumpy ...