About noviceuser

Ok so we are testing a way to transcode some videos to distribute to remote users and Plex is working well internally.  I am now trying to set this up so that we can use externally as well.  Here is what I have done. 1)  Created the Object Address for the Plex Server 2)  Created a Security Policy to allow inbound access to the Application "plex" 3)  Created a NAT Policy for the Plex Service to push 32400 to the Plex Server 4) Cmmitted the changes (this is what usually gets me the most) So I try it out and nothing.  Check the logs and I see: To Port:  32400 Application:  Not-Applicable (My understanding is that this is showing this because the traffic was matched to a "Service Policy" instead of one defined by an application) Action:  Deny Rule:  Block Bad Apps So I went and moved all of my Plex related policies and rules to the top of every list because my understanding is that it checks from top down to decide which policy to apply and when it matches it's done checking.  Commit again....  same result. So I looked at the "Block Bad Apps" Security Policy (because that is what it means by "rule"?).  This policy has two application groups to block:  "Avoidance" and "peer-2-peer".  Neither of those contain anything about plex OR port 32400 from what I can tell.  Sure there are applications underneath that say "variable port" or something like that however it just doesn't make sense to me: 1)  Why traffic for port 32400 OR Plex is not being picked up by the rule for such      Quick note on this...  I have played around with taking out the application and just using port 32400 however that doesn't seem to change anything 2)  Why this policy is blocking the traffic when there is nothing in there about port 32400 from what I can see. So then I went and disabled the "Block Bad Apps" policy and then I got nothing...  no logs... NOTHING.  Apparently the traffic was not passing through NOR was it logging anything at this point.  So I'm not really sure what is going on. Anyone have any advice please? Thank You, Ryan Hall ... View more