Unable to reach branch office's network (an S2S VPN) when connected via GlobalProtect, only when inside corp. network

VPN
1

Hello! I’ve set up an S2S VPN tunnel with our branch office and HQ PA firewalls. All internal LAN subnets at HQ and the branch office, there is communication. Meaning HQ’s LAN subnet 10.10.10.0/24, can talk to the branch’s LAN subnet 10.10.20.0/24. I can ping hosts, and I can RDP from the branch office to a server at the HQ location and vice versa but when using GlobalProtect VPN at my home, I cannot ping anything at the branch office LAN subnet. The GlobalProtect VPN configuration is on the HQ firewall.

Please advise.

Thanks!

2

Do you have a rule to allow traffic between the zone of GlobalProtect and the zone of your S2S?

3

You need to check if your gp split tunnel config allows the branch office network to be injected on the gp client. Global Protect / Gateways / agent config i believe.

Then you also need to have a route on branch office pa to reach you gp subnet via the tunnel interface. If you get a 10.10.30.x ip via global protect branch pa needs to know where to send return traffic.

Finally you need to have a security policy on both sites to allow the traffic.

Check the logs on both fws specially the column “bytes received” that will tell you if the pa is getting return traffic.

4

Hello u/fmaster007 I imagine as you say, that you connect via GP to the headquarter.

Now a question, are you forwarding all your traffic via global protect ? or have you configured split tunnel, to only use GP for the traffic going to the internal networks and systems of the head office but not to forward the traffic to the Internet ?

If you are forwarding all traffic e.g. 0.0.0.0.0/0 it would not be a routing issue at least from the Global Protect config. Now if you are using split, make sure all the networks you intend and need to reach are configured.

Now, as mentioned by the other colleague, remember that the client and/or the Global Protect zone also has or should have defined access rules, validate that the correct rules exist from Global Protect to the Site to Site VPN(s).

Now, and no less important, assuming you have a Site to Site VPN and at the level of encryption domains you have:

10.10.10.10.0/24 and 10.10.20.0/24 in both directions, which is the standard, the expected, for the correct Site to Site VPN configuration. Now why do I point this out, because Global Protect, GP VPN clients, when they connect have or will have a network range such as 172.16.1.0/24 to give a simple example. When the client connected to GP tries to go to one of the Branch office IPs, it will of course use the IP 172.16.1.0/24 but this IP is not allowed in the VPN Site to Site tunnel, in the encryption domains, therefore it will not allow the traffic.

Now you have a couple of options:

The simple one is to create a NAT rule, exactly source NAT, that when the source connection is the Zone and the network range of the endpoints that use Global Protect and the destination is the Bran-Office, it uses an IP within the range of the central house, that is to say an IP in the range 10.10.10.0/24. With this, when applying a NAT source, the traffic will pass without problems, as long as the corresponding rules exist, since the peer, the branch office, will recognize this traffic as within the range 10.10.10.0/24 and this range already allows it and is part of the encryption domain/Proxy ID of the Site to Site VPN, between the head office/HQ and the BranchOffice.

Now the most complex, add the GP range to the encryption domain / VPN Site to Site in both peer and branch, generate a return route, a return route, for example, from the Branch office, create a static route so that it knows that the GP range is routed back through the VPN Site to Site tunnel interface.

Regards

5

First of all do you have routes for the vpn subnet at the branch office (ospf/static/bgp)?
Secondly do you have security policy allowing the gp vpn zone to go to the remote office vpn zone?

These are the first two to check.

Also, is gp vpn split tunnel or full? If split tunnel, is it injecting routes for the remote site.
If yes to the above then do pcap on the gp vpn anchor firewall and look to see for drops etc.
Also if you haven’t already, enable session end logs on the interzone deny policy so you can see if you’re hitting that.

6

Hey u/C3-PIO0ps That’s correct, the GP is configured at the HQ’s Palo Alto firewall. In GP, we are using split tunnel and not a full tunnel configuration.

The GP IP address is 172.16.20.0/24 assigned to the GP Clients.

So I have not created a NAT policy, only a security policy allowing “S2S-Out-VPN” - Source Zone → “Trust” to Destination zone → “S2S VPN”, AND “S2S-In-VPN” Source Zone → “S2S VPN” to Destination zone → “Trust”.

Based on what you said, should I create a NAT rule? If so, how?

Do this on both Palo Alto firewalls?

Thanks!

7

This is the way. You would see your traffic blocked in logs

8

You should make sure that your policy are logging in session end . Check the default rules to make sure they are set to logs .
Also check the routing .
It sounds like your only routing routes you need to your clients . So make sure your remote sites network is sent to the gp clients. Also make sure you route your gp network back from the other side

If zone protection is enabled the firewall might drop traffic with out logging if you don’t have the routing correct .

The traffic always needs to be aloud (policy) and it has to have a reason to go from one zone to another (routing)

9

172.16.20.0/24

Hi u/fmaster007 , all this you have to configure in the HQ.

If it is a Source NAT like this:

Source: The specific Zone you defined for “Global Protect/User Remote GlobalProtect” (you can add the network to Source 172.16.20.0/24).

Destination Destination: Site to Site VPN Zone, i.e. I understand in your case it would be the Branch Zone and the range 10.10.20.0/24.

Now in the traslate-Source Address Trasnalation section:

It would be dynamic-ip-and-port select the LAN or trust interface of the network HQ 10.10.10.0/24 and select the LAN Trust IP or if you want to use another IP within the range 10.10.10.0/24 dedicated to the Source NAT, example 10.10.10.100 you can in the Address Type section, in the Source Address Trasnalation section, put Translated Addres and enter example 10.10.10.100. (Do not put anything in Destination Address Translation since it is only a source NAT).

Now make sure that there are “the security policy or policies” that allow traffic from the Global Protect/Global Protect Network zone ( 172.16.20.0/24 ), to the VPN Site to Site zone of the Branch-Office range ( 10.10.20.0/24 ).

Important: At the Global Protect level, in the GP Split level configuration, add the Branch Office network segment.

Best regards