Traversing Site-To-Site Tunnel via GlobalProtect

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

Traversing Site-To-Site Tunnel via GlobalProtect

L1 Bithead

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!

 

1 accepted solution

Accepted Solutions

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...

View solution in original post

7 REPLIES 7

L7 Applicator

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?

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

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.

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.

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...

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

"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 ...

  • 1 accepted solution
  • 2183 Views
  • 7 replies
  • 0 Likes
  • 47 Subscriptions
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!