Newbie - GP and NAT

Reply
Highlighted
L1 Bithead

Newbie - GP and NAT

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?


Accepted Solutions
Highlighted
L5 Sessionator

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


All Replies
Highlighted
Cyber Elite

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.

Highlighted
L1 Bithead

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)

Highlighted
L5 Sessionator

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.

Highlighted
L1 Bithead

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

 

 

 

PlexTV ServicePlexTV ServiceNAT ruleNAT ruleSecurity ruleSecurity rule

 

Highlighted
L5 Sessionator

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.

Highlighted
L1 Bithead

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

Highlighted
L5 Sessionator

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.

 

Highlighted
L1 Bithead

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?

Highlighted
L5 Sessionator

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.

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 Live Community as a whole!

The Live Community thanks you for your participation!