Issue With GlobalProtect VPN

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

Issue With GlobalProtect VPN

L4 Transporter

Hi,

 

Can someone please point me at the right direction?

 

2 PA-500 devices are in active-passive configuration. When connected via global connect, getting IP address in the correct range but cannot reach any internal address and trace route does not proceed beyond the first hop of the gateway on the Firewall.

 

However, from a PC behind the firewall on the network, we can ping the GlobalProtect PC connected over the internet.

 

Thanks in advance

Farzana

1 accepted solution

Accepted Solutions

L4 Transporter

Hello All,

 

Thank you for taking your time out and replying. I had to log a support call for this and TAC engineer solved the issue.

 

From the Traffic monitor logs, we ran show session id. It showed the session was using pbf rule: No_PBF_rule which had 'Enforce Symmetric Return' ticked. Once it was disabled, issue was fixed.

 

Thanks

Farzana

View solution in original post

9 REPLIES 9

Cyber Elite
Cyber Elite

Hi Farzana

 

are you seeing any packets being blocked in the traffic log? Did you make sure to create a security policy that will allow sessions from the GP gateway zone (the zone attached to the interface the GP clients connect to) to the trusted zone?

 

in the GP gateway settings, did you happen to set an access route? if so, can you verify the subnet is accurate ?

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Hello Reaper,

 

Thank you for taking your time out and replying.

In the traffic log, I can see packets sent=packets received...only season end reason showing aged-out.

Security policy is allowed from LAN (interface tunnel1) to LAN (interface Eth1/4).

GP gateway settings has access route setup.

 

Configs | User/User group | OS | IP pool |                         Access Route

--------    -------------------    ---    --------                            ----------------

Default        Any                    Any  10.20.30.0/24             192.168.1.0/24

                                                                                              192.168.2.0/24

                                                                                              192.168.10.0/24

                                                                                              192.168.100.0/24

                                                                                              192.168.101.0/24

routingtable.jpgforwardingtable.jpg

Hi Farzana

 

session end reason aged-out means the session came to a natural end, which means it went as expected

 

did you create a security policy from LAN to LAN zone ? (i would recommend changing the zone of the GP tunnel interface so you have more control over what goes in and out of the tunnel)

Due to both interfaces being in the same zone, you may be missing some logs

 

did you make sure the GP Client Network settings contain the appropriate access routes to reach all of your subnets (or is left empty for a 0.0.0.0/0 default route into the tunnel)

2016-08-17_11-27-50.jpg

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Hi Reaper,

 

i don't think aged-out is the naturall way of seeion end,

  • Aged out - Occurs when a session closes due to aging out 

I'm sorry if i'm worng,

Kotresha
ACE

hi

 

you are right! i wanted to argue that the session end would be 'unknown' but aged-out works just as well for a half open session

 

so please disregard that comment until you have verified the bytes sent and bytes received 

if both are populated with plenty of bytes, the aged-out simply means both sides stopped sending packets without forcibly terminating the session by FIN or RST, if you see bytes sent but none received, there is likely a problem with returning packets (routing, NAT, ...)

 

sorry for the confusion

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Was going to say something similar. Does your internal network have a route for 10.20.30.0/24 for the returning packets?

L4 Transporter

Hello All,

 

Thank you for taking your time out and replying. I had to log a support call for this and TAC engineer solved the issue.

 

From the Traffic monitor logs, we ran show session id. It showed the session was using pbf rule: No_PBF_rule which had 'Enforce Symmetric Return' ticked. Once it was disabled, issue was fixed.

 

Thanks

Farzana

This is a fine temporary solution.  But this solution is showing you that the previous comments about asymmetrical routing in your network here are correct.

 

The best permanent solution is to identify how to get the return traffic from these internal hosts to use the same path that the outbound traffic from the vpn hosts are using to reach those hosts.  As noted above this is likely a missing route somewhere.

 

Or it could be the need to create a routed link into the internal zone instead of connecting multiple routers to the same subnet.

 

PA firewalls can best protect against threats only when they see the full flow of the traffic both inbound and outbound in a symetrical routing setup.  This is why the default behavior is the block asymmetrical flows to help you see that this path is not optimal and can allow some threats to go undetected.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center
  • 1 accepted solution
  • 5396 Views
  • 9 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!