Do you have a rule in place to allow this protocol to pass?
If not then you will need to create a rule to allow the "RDP" application (which operates over the TCP port mentioned in the audit log - 3389) from Network A to the DMZ zone.
If so, is Remote Desktop enabled on the destination host?
Rather than being an outright "Deny", the audit log entry suggests that the connection has timed out. So the Firewall has allowed the request to pass but hasn't received a response from the destination in a suitable amount of time. If you do have a rule in place what is the NAT value set to. If it is "<None>" try changing it to "<Localhost>". It may be that the connection is making it through the Firewall, but the destination host doesn't know where to send the response back. By changing the NAT value of the rule to use the Firewall's localhost address, the destination host will believe that the request has come directly from the DMZ address on the Firewall (which is on the same subnet) and will send the reponse back to that host. The session tables on the Firewall will match this return traffic back to the original session and will then be able to send the response back to the client machine.
Hope that helps.
Yes I alread tried all the NAT settings. I already allow <Any> application but still I cannot connect from Network A to DMZ. I tried to allow external to DMZ RDP to the server and it did worked. I was wondering why Network A could not connect to the server on the DZM when it can ping it and telnet the ports I opened particularly 3389 for RDP.
Personally, I have never used <Any> for the application, I have always specified the protocols/services required. So even though you have this rule in place I would suggest trying to add an addition rule explicitly for the RDP application between these two networks.
The next thing I would try is to ensure that you can RDP to that machine from a client on the same network segment. If that doesn't work then it doesn't matter how you try to configure the Firewall. As previously mentioned, the log entry you have provided isn't a "deny", it is a time out - so the Firewall is trying to communicate with the destination, but doesn't appear to be receiving and appropriate response. What you could do is to establish 2 SSH connections to the Firewall and in each run a tcpdump for port 3389 on the two interfaces (Network A and DMZ).
If both tcpdumps show traffic on this port number passing from Network A to DMZ then the Firewall has allowed the connection through. If nothing comes back again, then you are dealing with a problem on the target server, or that network segment itself.
Allowing RDP was the first rule I created and changed it to <Any> to only check if I missed any port, anyway, I can RDP from the same segment which is internal zone and also from the external zone as well. I can ping and telnet any port that I allow to the rule but cannot RDP from Network A to the DMZ zone. I will try your suggestion to establish 2 SSH connnections thank you.
That is certainly what I would recommend. The log evidence you have provided so far suggests that the connection is timing out - so the Firewall is allowing the connection, but isn't necessarily receiving a reply from the destination host. The tcpdump output will confirm this.
If the tcpdump does show that the destination host is responding, but the Firewall isn't passing the response back to the other interface you could try replacing the RDP application entry in your rule with a custom entry running on port 3389. This will reduce the amount of involvment the Firewall has over the transaction and would then warrant raising a support request with McAfee support.
However, I don't believe I've encountered any issues with the RDP application in version 8 in any of the installations I have worked on.