DCE-RPC Session Helper Breaks Remote DCOM / WMI

[#1]

I am a Sr. Systems Engineer with a large hosting company. We use Fortigate firewalls extensively and recently ran into a strange issue invovling remote WMI monitoring of Windows servers behind Fortigate devices. The monitoring product we are using leverages WMI to collect performance statistics from remote instances. The connection is made from a single monitoring server across the public Internet (no VPN). In each case we had firewall policies configured to allow ANY traffic from the monitoring server to the target server. Ping, telnet, RDP, and Remote Procedure Calls (tested via " net use \\<target>\IPC$) all connect successfully. When connecting to WMI remotely to monitor performance, the error " RPC_SERVER_UNAVAILABLE" was fired on the monitoring server. WMI tools such as WBEMTest reported the same error. I verified DCOM permissions (remote WMI calls are made through DCOM) and confirmed that the Windows Firewall was disabled. After extensive troubleshooting, we realized that we only devices experienced this issue when connecting to customers who are behind Fortigate devices. We had no problems with customers behind other firewall products. We took network captures on the source server and target servers in working and non-working environments. What we found was that following the successful RPC Bind, the source server calls the ServerAlive2 method and DCOM on the target instance responds with a list of string and security bindings followed by a result code. On working servers, the string bindings for DCOM include the internal IP addresses for binding to DCOM interfaces. On the servers that were not working, the ServerAlive2 response returned the external IP address for all bindings and no result code. This caused the DCOM interface bind to fail. The packet sniffer on the Fortigate showed that the target server was returning the internal IP addresses, but the external interface was sending the external ip addresses, indicating some type of translation to the outbound packets. We came across documentation for the DCE-RPC Session Helper which states the following: " To accept DCE-RPC sessions you must add a firewall policy with service set to any or to the DEC-RPC (sic) pre-defined service (which listens on TCP and UDP ports 135). The dcerpc session helper also listens on TCP and UDP ports 135" This would seem to imply that adding the service set to ANY would allow for the packets simply to be passed using dynamic ports. This is not the case. We disabled the DCE-RPC Session Helper and were able to connect via remote DCOM / WMI without issue. Network caputures showed the proper bindings being returned from the target server. Is it expected behavior that the Session Helper make changes to outbound traffic? I' m sure this type of issue is not isolated only to the Fortigate devices (I remember similar issues with the Cisco PIX FIXUP protocols). Hopefully, this will save somebody a bunch of troubleshooting. Best, D. McDowell Charlotte, NC

[doshbass]

I would say that the behaviour would be expected, but only if you were using NAT translation. I don' t confess to know the workings of RPC, but would have thought that returning an internal IP address across the Internet would in most cases not make sense, but clearly in this case it does. Good debugging BTW

[#3]

Thanks for the reply. I agree that it is likely to be expected. In cases such as this, the RPC bind succeeds using the external IP, but the DCOM method returns internal IP addresses mapped to COM interfaces. These are translated on their way out and cause DCOM to fail. My goal was to point it out in case anyone other admins run into it. Finding a solution in a user forum would have saved a lot of time. We' ve simply updated our internal procedures to disable the DCE-RPC Session Helper if external WMI connectivity is required. Best, Denis