Issue With GlobalProtect VPN

[Farzana]

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

[reaper]

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 ?

[Farzana]

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

[Farzana]

[reaper]

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)

[KotreshaMC]

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,

[reaper]

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

[aceandy79]

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

[Farzana · Accepted solution]

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

[pulukas]

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.