topic Issue With GlobalProtect VPN in General Topics

Issue With GlobalProtect VPN

Farzana — Tue, 16 Aug 2016 05:08:09 GMT

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

Re: Issue With GlobalProtect VPN

reaper — Tue, 16 Aug 2016 09:37:07 GMT

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 ?

Re: Issue With GlobalProtect VPN

Farzana — Wed, 17 Aug 2016 00:03:53 GMT

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

Re: Issue With GlobalProtect VPN

Farzana — Wed, 17 Aug 2016 04:00:00 GMT

Re: Issue With GlobalProtect VPN

reaper — Wed, 17 Aug 2016 09:29:39 GMT

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)

Re: Issue With GlobalProtect VPN

KotreshaMC — Wed, 17 Aug 2016 12:50:35 GMT

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,

Re: Issue With GlobalProtect VPN

reaper — Wed, 17 Aug 2016 13:21:53 GMT

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

Re: Issue With GlobalProtect VPN

aceandy79 — Tue, 23 Aug 2016 08:12:41 GMT

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

Re: Issue With GlobalProtect VPN

Farzana — Tue, 23 Aug 2016 23:13:50 GMT

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

Re: Issue With GlobalProtect VPN

pulukas — Sat, 27 Aug 2016 12:22:57 GMT

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.