Hi Arix,
I believe that the SRX is definitely dropping those packets, however Im not sure if you will see that in the flow traceoptions file. The SRX is reporting that in order to let the packets pass it needs extra configuration that is pretty much configuring the SRX to permit users connecting to UUIDs unknown to the SRX. You might configure MS-RPC traceoptions to dig further:
# set security alg ms-rpc traceoptions flag all
# set security alg traceoptions file MS-RPC-TRACE size 1g
# set security alg traceoptions level verbose
# commit
# run show log MS-RPC-TRACE
Also you could try using the flag "error" instead of the flag "basic-datapath" in the security flow traceoptions. You can upload the files when you post a coment.
First question: how is the security-policy, that is allowing the communications, configured? Are you specifically referencing the MS-RPC application or you are just using "application any"?
MS-RPC is used by windows devices to communicate processes running on different devices; these remote processes are identified by UUIDs.
The device acting as the client will first establish a connection via port 135 and will ask for the dynamic port on which a specific service (UUID) is listening on the remote end. The device acting as the server will provide this information and the client will open a new session on that dynamic port (a high random port). Ideally we dont configure security-policies that permit traffic on all ports so when you reference the ms-rpc application on a security-policy it only permits port 135 and the SRX listens to the communications between the client the server in order to determine what is the high random port that will be used next, and the SRX allows communications from the client on that port only, blocking traffic on any other non-negotiated port. Thats pretty much the funtionality of the MS-RPC ALG. However is very common that from specific zones we dont need that much of security and sometimes we can have a security-policy allowing all the traffic from a specific zone to another zone.
Second question: Can you disable MS-RPC ALG? If your security policy is configured for "application any" I believe there should not be any problem on disabling the ALG:
# set security alg ms-rpc disable
# commit
# run show security alg status
Based on the logs the UUIDs not being recognized are related to:
MS-NETLOGON: 12345678-1234-abcd-ef00-01234567cffb and 12345778-1234-abcd-ef00-0123456789ab
WMIC-Webm-Level1Login: f309ad18-d86a-11d0-a075-00c04fb68820
Refences:
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-rpc-alg.html
https://kb.juniper.net/InfoCenter/index?page=content&id=KB12057
Please share the following operational commands:
show security alg ms-rpc
show security resource-manager summary
show security resource-manager resource active
show security resource-manager group active
show security flow session resource-manger summary
If you can determine that the logs are cosmetic and that no packet drops are happening you could always avoid those logs from you being written to your log file:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB9382
Hope this helps. Please my mark my post a Solution if it applies.