GlobalProtect clients need to talk to each other

[serge.kovalev]

All remote computers are connected via GlobalProtect single subnet. Let's say 172.16.1.0/24. This subnet is configured on the Palo as an IP Pool. Clients can successfully connect to GlobalProtect and access non-GP internal resources located in different local subnet (servers, other PC's). Internal subnet is 192.168.1.0/24. But... Computers on the GlobalProtect need to talk to each other - ping, RDP, SSH, HTTPS while on the GlobalProtect VPN. Example: 172.16.1.1 should be allowed to communicate 172.16.1.2 and vice versa.

So, there is a question if it is possible at all with Palo?

[BPry]

@serge.kovalev,

This would be allowed by default through the intrazone-default policy without any modifications being made to the default GlobalProtect app settings or security rulebase. A common security lapse that I see from people when it comes to BYOD zones with GlobalProtect is actually when they don't modify this default behavior and allow BYOD endpoints to communicate to any other BYOD endpoint. 

[serge.kovalev]

I would not ask this question if there is no issue and everything works by default. We have multiple sites deployed and neither allowed BYOD to BYOD communication by default since installed to itself. It was not a problem until we were asked to allow such communication. One of the offices does not have site-to-site VPN with the main office. All computers are joined via GlobalProtect from remote office to the HQ Palo. Now we have to allow one remote office computer (name it 'Client') connect to another remote office computer (name it 'Server') in the same location. The overall route looks like RemoteOffice -> GlobalProtect -> HQ Palo -> GlobalProtect -> RemoteOffice. Please, keep in mind this is same remote office. Intrazone to intrazone is allowed, traffic leaves 'Client', goes to the VPN and disappears somewhere on the firewall. No rules are hit. I assume it is a routing issue, not firewall.

Palo issues P2P addresses to GlobalProtect clients aka 172.16.1.1/32 and 172.16.1.2/32. Receiving the traffic from GlobalProtect client it can successfully route it to any external location in accordance with its routing table but never diverts it back to the same tunnel of what I found.

If you have any experience with the above situation, please, share your routing table.

[TomYoung]

Hi @serge.kovalev ,

Yes, it is possible.  Are you using full-tunnel or split-tunnel?  If split-tunnel, ensure 172.16.1.0/24 is part of the split-tunnel access route.

Thanks,

Tom

[aleksandar.astardzhiev · Accepted solution]

Hey @serge.kovalev ,

By default GlobalProtect will add host route /32 for the IP assigned from the GP IP pool and one for the DNS server (if GP is configured to assign any). As @TomYoung suggest it seems you are using split-tunnel so the GP connect machines doesn't actually have routes for the GP network and don't know how to reach the other GP clients. This would different story if you are using full-tunnel, in this case GP will install default route poiniting to the tunnel so will not matter that there is no specific route for GP pool.

You should be able to confirm this by:

- Connect the 'client' machine to GP VPN

- Check host routing table (assuming it is Windows) by running "route print" in cmd/powershell prompt.

- On the firewall you should see specific routes for each IP assigned from the pool pointing to the tunnel associated with the GP gateway.

[serge.kovalev]

Gents, it works, thanks. I was confused as I added routes manually to two client PC's before with 'route add' command. I assumed that split tunnel does this simple thing only. Obviously it did not work. I guess that Palo adds some internal logic when you add split on the firewall in addition to the injecting routes to the clients.

[aleksandar.astardzhiev]

Hi @serge.kovalev ,

Glad to hear it is working.

I am assuming manually adding the route with "route add" is not enough, because you only point the traffic to the tunnel, but it still needs to be part of the encryption domain. I would assume when configuring the split tunnel GP is automatically adding the route to the IPsec negotiation, while adding it manually  on the host doesn't.

[EWhitmore]

I have a similar question. but i would like to know if it is possible to ssh into a computer working remotely?  

[TomYoung]

Hi @EWhitmore ,

Absolutely!  You would need (1) a NGFW rule that allows the traffic and (2) the computer accepting the connection.

Thanks,

Tom

[EWhitmore]

so i would like to be able to shh into a computer working remotely in case they need assistance. how would i configure my pa firwall to do this?