Global Protect behind a firewall

[panos]

Hi,

PaloAlto firewall is behind another firewall(Firewall B).

This firewall B's port 443 busy with another app.So we have to use another port

How should we configure Paloalto portal and gateway.

we used port 18000.

Firewall B --- 2.2.2.2 port 18000 Nat to 10.1.1.5 443  which ise public ip of PaloAlto

when we configure portal and gateway as 10.1.1.5

and inside Global protect portal -- client configuration gateway address as public ip 2.2.2.2:18000

we can nonnect with GP but we cannot access anywhere .How can we fix this routing problem.

Thanks.

[hshah]

Hi Bulent,

I guess it may be configuration issue rather than routing issue. Following answer may be helpful to eliminate routing issue.

Client End Troubleshooting :

Please go to Global Protect Client > View > Advance View > Troubleshooting > Routing Table

Make sure routing entries are pushed at client end.

Server End Troubleshooting:

Try to access any Server, do wireshark to make sure traffic is coming.

Regards,

Hardik Shah

[knutelde]

hi Hardik

I am running into a routing issue with my global protect clients, how can I add routes in the ruting table ??

the route I need are not there

Knut

[kprakash]

Hi Knut,

Are the clients connected to the global protect gateway, but cannot access networks behind the PANFW? If the clients are connected to the gateway, there are 3 things that I would check

1) Check the access route configuration on the gateway. The access routes that you configure on the gateways get pushed to the clients routing table. You can change the access route from using a split tunneling to allowing all the routes ( 0.0.0.0/0 as the access route) to troubleshoot if you can reach the internet or internal networks. Plus if you are connecting from an Iphone/Ipad split tunneling doesn't work, because of a limitation of the apple devices

2)  ensure that the  IP address assigned to you does not overlap with the other IP addresses on your network adapters on your PC, where you are connecting from..

3) Verify the DNS settings being pushed from the gateway to the client.

BR,

Karthik

[knutelde]

Hi Krpakash,

and thank you for a quick and informative reply.

allow me to ellaborate \ specify the details in my setup :

I have one PA500, here in Norway, and we have a production office in finland.

all the users are connected to the same windows active directory domain, and there is a fixed IPsec vpn tunell between offices in norway and finland.

employees in both countries connect to the same global protect.

global protect users have their own IP range 192.168.120.0/24 and their own security zone.

in finland the local ip range are 192.168.1.0/24

I can connect from finland to global connect, for example ping from 192.168.1.4 to 192.168.120.12

but not the other way, the trafic mnitor shows the traficc beeing sent but no packets come back

to me it looks like a routing issue, and that machines in the Global protect zone does not know where the packets to the 192.168.1.4 range in finland should go.

but I may be wrong.

all input and ideas are appreciated

knut

[knutelde]

update, one thing works though - teamviewer, takes the route from tunel 1 (gp tunell) to tunell 15 (fixed ip sec vpn tunell norway-finland) - that I hope the rest of the trafic from gp protect would take, but I cannot succed in accheiving

[kprakash]

If the team viewer traffic works fine, I am assuming that there is an issue with the policy. Can you verify if

1) The client obtained the routing information from the gateway. You can look that up, by going under the troubleshooting tab of the global protect client, or typing 'route print' on the windows cmd.

2) Verify if the tunnel 1 is configured with a zone and a virtual router, and if there is a policy in place to allow traffic from the zone of the tunnel.1 interface to the internal networks.

3) If the internal network (192.168.1.0/24) is not connected directly to the firewall, and are a couple of hops away from the firewall, ensure that the hops know the route to 192.168.120.0/24. Or else you can Source NAT  the traffic (from the tunnel zone to internal zone), to the IP address of the interface from where the internal networks are reachable on the firewall.

4) When you mention that the pings work from 192.168.1.4 to 192.168.120.12, do you see both the echo responses come back from the 192.168.120.12?

5) Ensure that you do not have a route to 192.168.120.0 being pointed out via another interface on the PANFW.

6) Traceroute from 192.168.120.12 and find out at which IP address the pings die

Best regards,

Karthik

[knutelde]

hi

and again thanks for really good feedback !

comments on points above:

1)

i see the routing information, both in the GP client troubleshooting tab, and in windows cmd, and there are no specific route to the 192.168.1.0 range in finland. I could add a static route to test but I am not qiute sure what to set the gateway ip to. I have tried the gateway ip adress for finland 192.168.1.1 and the GP local gw IP 192.168.120.1 locally to a latop but both failed.

So I can find the routing information for a GP client, but I am not sure how I can verify if it is pushed by the gateway or not. And where can I add a route to be pushed from the gateway ?

2)

both tunels are configured with the same virtual router, and a security zone. there is a policy allowing traffic from the GP zone to the ip range in finland. I cannot choose a tunell interface as a destinaton in a policy, so i allow trafic from the gp zone to the ip range in finland

3)

where should I define next hop from GP range 192.168.120.0/24 - I will take a look at the Source NAT option you mantion, maybe this is the solution I am looking for. I will post back how that work out.

4)

there seems to be some missing repsonse packets yes, please see my attached pictures, showing ping test, session browser and trafic monitor for both ways, working one way but not the other way

5)

In PAFW we use 192.168.120.0/24 only as GP ip range, and there is one listing of this in the virtual router,

it looks to me like packets are going through the default route, because it finds no match to a specific routing rule,

6)

I do not get the information i need from tracert, it only shows start and end adress and start inbetween, I have attached pictures of ping and tracert tomillustrate my point.

[knutelde]

update

when running cli command show running routes i got a lot of routes for the 192.168.120.0/24 range, one that looks OK, and the rest of the rutes I am not sure if they should be there

(see attached screenshot)

I still cant quite figute out where I can set, edit or delete routes, like you would using add route in windows cmd shell, or route add in ,linux shell ??

[kprakash]

It doesnt make sense that you can ping in one direction, and indeed it is taking the default routes somewhere. More likely to be a routing or a policy issue. ( Cannot rule out proxy id issue as well )

From the output, I see that the 192.168.1.0/24 is reachable on the tunnel interface, ie tunnel.5. I am assuming that this is on the Noway firewall. Do you have a similar route on the Finland firewall, pointing out to 192.168.120.0/24 on its tunnel interface.

We would appreciate it, if you can attach the network diagram, about how the users are trying to connect from the global protect client to the users on 192.168.1.0/24 network.

Plus, please attach the screenshots of the tunnel interfaces and the zones on which they are configured,  the policies, the >show routing route command from both the firewalls,

Have you added mirrored image proxy ids on both the firewalls?

Best regards,

Karthik

[knutelde · Accepted solution]

CASE SOLVED !!

with the help from computerlinks excellent techn. we found that there was a error in a ip adress in the policy, allowing traffic back from finland 192.168.1.0/24 range

when I corrected the IP adress, it all started working

thanks for all good community support and feedback !!