ALL_DCE_RPC behavior in R80.10

[Arthur_DENIS1]

Hi,

During my last upgrade from R77.30 to R80.10, I get a little issue with RPC ports.

My customer use a group called ALL_DCE_RPC, and Dynamic RPC port like tcp/49155 was allowed through this group on R77.30 version, but seems not in R80.10 take 103.

Solution was simple: add new service in the concerned rule.

However, for my personal information and next upgrade, I want to understand.

I have already double checked on release note and somes SK, but didn't find anything...

Someone have an explanation about this ?

Thanks in advance for your help.

Best regards,
Arthur

[G_W_Albrecht]

DCE_RPC has long been in  the middle of issues - but for both versions you do mention, there is sk65676 DCE-RPC traffic is dropped on High Ports and also sk44982. Mostly it is IPS that stops DCE_RPC (sk105405).

[Arthur_DENIS1]

Thanks for your update
Yes I know the sk65676, but the point is, on my particular environment:

- in R77.30,  DCE-RPC traffic on High Ports is not dropped

- in R80.10,  DCE-RPC traffic on High Ports is dropped: we need to add a specific rule for the service

So this is an unexpected behavior, isn't that ?

[G_W_Albrecht]

That would be a question for TAC - they know what is unexpected and what works as designed 😉

[Wolfgang]

Hallo Arthur,

we had  the same problem.

In R77.30 a rule exists with source, „ALL_DCE_RPC“ as service and a destination.

Everything was fine, dynamic high ports are allowed on request.

After upgrade to R80.10 the same traffic was blocked by the cleanup rule. Adding  the high-ports range as service allows the packets. A long debug session with Check Points support solved the issue.

All needed information comes from sk65676. 

You need only a rule with „ALL_DCE_RPC“ as service, no other services. And you have to delete all other service definition for TCP/135. You have to delete this from the object database, even if it not used.

This is important and solved our problem. Step 2 in sk65676 describe this.

with this the service ALL_DCE_RPC works like expected and you don‘t need to open special high ports.

best regards 

Wolfgang Becher

[Arthur_DENIS1]

Hi Wolfgang!
I'm not alone

This information should be included in the release notes IMHO...

I hope there is no other behavior like that for next upgrade.

Nice day,

Arthur

[Carsten_R]

Hi,

and NFS services are affected too! (NFS needs portmapper on 111, not 135), but if you have a tcp_135 services, the NFS service will not work.

Please be careful at which position you place your  RPC / DCE-RPC services rule, they will stop SecureXL at this rule to the end, perhaps a inline layer can prevent bigger performance issues...

[Timothy_Hall]

Use of a DCE/RPC service will stop SecureXL's Accept templating ability, but not influence which path (throughput acceleration) the traffic is handled in: SXL, PXL, or F2F.  SecureXL Accept templates are not nearly as important as they used to be for optimization in R80.10+ due to Column-based matching.

Edit: To clarify, I believe that the initial portmapper/RPC port 111 traffic is handled F2F to sniff the dynamic port allocated to the service being requested by UUID and pinhole it open through the firewall, but then the actual service traffic is eligible for throughput acceleration in a path more efficient that F2F.

--
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com