topic Re: Traversing Site-To-Site Tunnel via GlobalProtect in GlobalProtect Discussions

Traversing Site-To-Site Tunnel via GlobalProtect

JaredBaglietto — Tue, 01 Aug 2023 08:44:08 GMT

Hi everyone,

See if you can give me some insight here as I've exhausted all my options.

Scenario

I have a client who has two branch offices, each one with a PA-440 installed. Both these PAs are linked together via IPSec tunnel. I can confirm that between both these LAN subnets, there is harmonious communication.

At the same time, I have created a GlobalProtect gateway to primary office's PA-440, in the hopes I could reach both office PA's MGMT interfaces.

Problem

The problem, I can reach primary office MGMT just fine via GlobalProtect, but not the secondary office's.

I have checked logs on both PAs and can see that traffic is allowed, and that the traffic knows to travel across the relevant tunnels. But I'm getting constant age-outs on both PA logs. So I can see traffic from my GP address to the secondary PA is arriving and permitted, but just doesn't know how to translate to its MGMT interface for the standard port 443. I've also checked the permitted IP ranges for the second PA's MGMT interface, and all seems ok as it includes the GP subnet.

Look forward to hearing your thoughts. Many thanks!

Re: Traversing Site-To-Site Tunnel via GlobalProtect

Mick_Ball — Tue, 01 Aug 2023 10:49:00 GMT

Are you seeing anything on the remote sites traffic logs? If not then perhaps add a policy on them to deny “any source” to “management destination” and log session start to see if at least routing is as expected… perhaps you already said it was getting there…. If so then do the management interfaces know how to get back to you?

Re: Traversing Site-To-Site Tunnel via GlobalProtect

JaredBaglietto — Wed, 02 Aug 2023 07:24:34 GMT

Hi Mick_Ball,

Thanks for your swift response.

Traffic logs are indeed reaching the branch office firewall, just timing out like in the first office PA logs.

I've checked your suggestion of MGMT interface routing back to the GlobalProtect subnet I'm accessing through. I can see there's a static route set on the PA's virtual router to go via the Site-to-Site tunnel to reach the primary PA, which is where I connect to for GlobalProtect.

Please let me know if I may be missing something.

Thanks again,

Jared

Re: Traversing Site-To-Site Tunnel via GlobalProtect

Mick_Ball — Wed, 02 Aug 2023 12:23:09 GMT

if you can see your traffic on other devices does that mean you can connect to them via another source or are they log forwarding to Panorama... if you can access them then perhaps it may be worth testing a ping locally....

ping source "internal interface address" host "management interface address"

if all is good then perhaps also try ...

traceroute source "management interface address" host " GP Client address" to just see if it knows how to get back...

The reason i suggest this is because the management interface is not inlfuenced by the virtual router as it has it's own default gateway...

also... QQ.. are management and trusted on different subnets???? I assume not but not confirmed...

HTH.

Re: Traversing Site-To-Site Tunnel via GlobalProtect

JaredBaglietto — Wed, 02 Aug 2023 12:51:25 GMT

Hi Mick_Ball,

Confirmed ping tests between PA hosts directly linked within Site-to-Site tunnel were successful.

Traceroute from secondary PA MGMT interface to GP client fails completely. So it's definitely an issue of communication between GP and Site-to-Site zones.

MGMT and trusted zones are on same subnet for both PAs.

Many thanks.

Re: Traversing Site-To-Site Tunnel via GlobalProtect

Mick_Ball — Wed, 02 Aug 2023 13:16:16 GMT

on the remote firewall did you add a policy to deny all traffic from management to trusted interface and log session start.. then you could see if pings from management were hitting the interface...

also.. can the management interface ping it's own gateway...

save troubleshooting... if same subnet,, just add management to trusted interface...

Re: Traversing Site-To-Site Tunnel via GlobalProtect

JaredBaglietto — Wed, 02 Aug 2023 15:07:09 GMT

Mick_Ball,

You're a star! The ping test you suggested highlighted an issue. Whereas when pinging to the secondary PA MGMT interface from the primary showed source zone as S2S-VPN, the secondary MGMT ping to GP client address showed destination zone as GlobalProtect and not S2S-VPN.

Then came to realise GlobalProtect was setup on secondary PA with exact same subnet as the primary. D'OH!

Anyway, killing GlobalProtect on secondary has now resolved issue. I can reach secondary PA via GlobalProtect.

Thank you so much once again for your help!

Kind Regards,

Jared

Re: Traversing Site-To-Site Tunnel via GlobalProtect

Mick_Ball — Wed, 02 Aug 2023 16:02:51 GMT

"Then came to realise GlobalProtect was setup on secondary PA with exact same subnet as the primary. D'OH!"

you is fik innit...... lol...

Nice one and good you kept at it... so much easier someties to do it a different way rather than to find a resolution ...

NP and anytime ...