Newbie - GP and NAT

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Newbie - GP and NAT

L1 Bithead

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?

1 accepted solution

Accepted Solutions

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

View solution in original post

15 REPLIES 15

L7 Applicator

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.

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)

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.

Thank you for the feedback. I have attached my config below for further investigation. 

 

 

 

PlexTV ServicePlexTV ServiceNAT ruleNAT ruleSecurity ruleSecurity rule

 

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.

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)traffic.png

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.

 

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?

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.

I think I found it - but now how to fix it 😉

 

interzone-default denyinterzone-default deny

@ckg1999

 

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.

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.

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


@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.

  • 1 accepted solution
  • 6116 Views
  • 15 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!