- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-24-2018 10:05 AM - edited 02-25-2018 07:36 AM
1) this is for a home use environment.
2) I have successfully configured Global Protect to work external.
3) I have PLex running and need to get it communicating to the world. Was able to do this before GP by setting "Service" to "any" in the NAT rules, but this broke GP, and not to even say isnt very secure.
Anyone have suggestions?
10-04-2018 07:04 AM
Ah, that's where the issue lies then. The destination IP address in the security policy needs to be the public IP (70.224.89.53). Give that a change and let me know how it goes.
Then, I think you may find this a useful resource 🙂
02-25-2018 10:35 AM
Hi @ckg1999
With "I have Plex running and I ned to get it communicating to the world" you mean that you want to connect to your Plex server over the internet, right?
In case my assumtion is correct, you can change the service in your NAT rule to 32400/tcp (if you are using the Plex default port). This way GP should work again and also the direct connection to Plex.
Regards,
Remo
PS: I would recommend that you place your Plex server in a separate zone. From this zone configure the rules as restricted as posssible towards the rest of your home network. Or even more secure would be if you access Plex only through a GP vpn connection without the direct access over the internet.
10-02-2018 12:08 PM
Bringing this back up. I have a Plex server sitting inside the network, which needs inbound connectivity over 32400. No other ports are needed. Here are my current settings:
NAT:
Source Zone: Internet (Untrust)
Destination Zone: Internal (Trust)
Dest. Interface: Any
Source Addy: Any
Dest. Address: Any
Service: Plex (Source Port: Any, Dest. Port: 32400)
Source Translation: None
Dest. Translation: Plex server IP (i.e. 192.168.1.x)
10-02-2018 03:08 PM - edited 10-02-2018 03:09 PM
Hey @ckg1999
There are two things that need amending with your NAT rule.
1. The destination zone is going to be "Untrust" since you'll be connecting to a public IP which resides on the outside interface/zone
2. You cannot have "Destination: Any" if you are doing a destination translation, add the public IP of your untrust interface, or if feasible, the public IP specific for Plex - I imagine if this is a home network you're only dealing with one public IP.
You will then need a security policy to allow the traffic which would then be
Src Zone: Untrust
Src IP: Any
Dst Zone: Internal
Dst IP: Public IP
etc.
10-03-2018 07:26 AM
Thank you for the feedback. I have attached my config below for further investigation.
10-03-2018 07:31 AM
Looks how I would expect. Is it still not working?
Are you seeing any denied traffic against the "interzone-default" rule? You may have to override this rule and turn on logging at session end to help further troubleshoot and in which case, you might need to amend your security policy depending on what's being blocked.
10-03-2018 07:42 AM
I am not seeing any deny traffic from the interzone rule. However, when i look at the logs, I see a lot of tcp-rst and aged-out (attached)
10-03-2018 08:25 AM
Hey @ckg1999
This looks to be outbound traffic, what about in the other direction? Do we see the destination NAT being correctly applied? "Bytes received" value is not 0? If you do a pcap on the plex server do you correctly see the packets ingressing and egressing correctly? You may need to modify inbound firewall rules on the plex server if you see bytes received "0" on the firewall.
Cheers,
Luke.
10-03-2018 08:51 AM - edited 10-03-2018 09:20 AM
Luke,
I do show that the NAT rule is being hit, but not the Security rule. Where would be a good place to look for that?
10-04-2018 01:34 AM
Hi @ckg1999,
You can use the traffic log filter ( addr.dst in IP ) and ( port.dst eq 32400 ) to see the traffic for this flow and confirm what policies its hitting. Again you may need to enable logging on the "interzone-default" rule to see denied traffic if you haven't already.
Another filter to use would be and ( addr.dst in IP ) and ( action neq allow ) to see any denied traffic going to that IP address. In this case, you would replace "IP" with your public IP and not the private IP since we wish to confirm inbound traffic.
10-04-2018 06:31 AM
I think I found it - but now how to fix it 😉
10-04-2018 06:45 AM
One step closer 🙂
Your security policy references destination address object "Plex" does this object have the IP "70.224.89.53"? If it doesn't, you can try setting the source port in your rule to blank (source port isn't required)
Cheers,
Luke.
10-04-2018 07:02 AM
The destination of "Plex" is the internal ip (192.168.x.x) of my plex server. I don't have anything configured for source port. Not sure what else I can do to change it.
10-04-2018 07:04 AM
Ah, that's where the issue lies then. The destination IP address in the security policy needs to be the public IP (70.224.89.53). Give that a change and let me know how it goes.
Then, I think you may find this a useful resource 🙂
10-04-2018 07:23 AM
@LukeBullimore wrote:Ah, that's where the issue lies then. The destination IP address in the security policy needs to be the public IP (70.224.89.53). Give that a change and let me know how it goes.
Then, I think you may find this a useful resource 🙂
https://www.youtube.com/watch?v=Ahrao6kBg8w
Just a quick note to this, just so you don't break your NAT rule: leave your old address "Plex" object as it was, and add a new object for the public IP. Add the newly created object as the destination IP for your rule.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!