About PKCCommsTeam

PKCCommsTeam · ‎12-23-2020

Hi there, I managed to work this out but forgot to reply. I had to set up an internal gateway operating in "no tunnel" mode to allow the client to pass traffic as normal when on the internal LAN. I previously did not have an internal gateway set up, things are now working as desired. Thanks,

PKCCommsTeam · ‎08-11-2020

Hi there, I have a question on the correct use of internal host detection and internal/external gateway config. The behaviour I want to achieve is when a client is internal to the LAN GlobalProtect will detect this and not bring up the tunnel and pass all network traffic transparently out the LAN connection, as if it wasn’t there. When external, the client tries to establish the tunnel. I have no requirement to tunnel internal traffic, it needs to traverse the LAN as if GlobalProtect wasn’t there. I have an external gateway & portal configured, there is no internal gateway. A “no NAT” rule and policy are set up so the client machines can communicate with the external gateway, even if they are internal. I understand this is best practise so clients will get config changes from the firewall regardless of where they are connecting from. The NAT & policy that allow this are working as I can communication in the logs from internal clients. No direct access to the local network is enabled and app is in “always on” mode as I want all traffic to be forced down the tunnel if the client is external to the LAN. When clients are external to the network, everything works fine and as designed. However with internal clients, there can be a delay in connecting, sometimes 30 seconds or longer before it realises it is on the internal LAN, and GlobalProtect backs off. Sometimes the yellow “connecting” message appears, asking you to be patient. Some clients are fine, and immediately detect the internal LAN and back off. A small number of clients will not detect they are on the internal LAN at all. After the user authenticates, the GlobalProtect client tries to do something, then falls back to disconnected state. Firewall logs show the authentication and client configuration was successful, so something strange is happening on the client side. In this situation the app appears to be allowing some outbound network traffic from the device to the local LAN, but no inbound, resulting in an internal client that is orphaned from the network. Clearly something isn’t quite right, how can I achieve the behaviour I want? On internal host detection the documentation says “The GlobalProtect app connects to the internal gateway after performing internal host detection to determine the location of the endpoint.” What is the client behaviour once it detects it is internal to the network? I don’t have an internal gateway configured, could this be the problem? Is the client looking for an internal gateway? Many thanks,

PKCCommsTeam · ‎03-23-2020

Hi there, I have multiple client authentication configurations set up on my GlobalProtect portal which use the same OS type. Order is as follows: 1 - Windows OS with local auth on the firewall. 2 - Windows OS with LDAP auth. What i want to achieve is if authentication fails with local auth, it tries LDAP auth and keeps going down the list until it matches. Both my local auth and LDAP auth profiles work fine, but the first one always takes precedence. It appears that if a config matches and fails, it does not try the next in the list. I want users who perform local auth to have a different IP range assigned to users that perform LDAP auth. How could i address this problem, or achieve the desired outcome another way? Many thanks,

PKCCommsTeam · ‎11-23-2015

Hi there, thanks for the reply. Debug is set up as follows, (session offload is turned off): PA-3050-A(active)> debug dataplane packet-diag show setting -------------------------------------------------------------------------------- Packet diagnosis setting: -------------------------------------------------------------------------------- Packet filter Enabled: yes Match pre-parsed packet: yes Index 1: 10.20.11.173[0]->0.0.0.0[0], proto 0 ingress-interface any, egress-interface any, exclude non-IP Index 2: 0.0.0.0[0]->10.20.11.173[0], proto 0 ingress-interface any, egress-interface any, exclude non-IP -------------------------------------------------------------------------------- Logging Enabled: no Log-throttle: no Sync-log-by-ticks: yes Features: flow : basic Counters: -------------------------------------------------------------------------------- Packet capture Enabled: no Snaplen: 0 -------------------------------------------------------------------------------- PA-3050-A(active)> I clear the logs, then verify nothing is there: PA-3050-A(active)> debug dataplane packet-diag clear log log dataplane debug logs cleared PA-3050-A(active)> less dp-log pan_packet_diag.log 0% PA-3050-A(active)> I then enable the flow debug, make some traffic, disable debug, wait a while then aggregate logs: PA-3050-A(active)> debug dataplane packet-diag clear log log dataplane debug logs cleared PA-3050-A(active)> less dp-log pan_packet_diag.log PA-3050-A(active)> debug dataplane packet-diag set log on Packet log is enabled PA-3050-A(active)> debug dataplane packet-diag set log off Packet log is disabled PA-3050-A(active)> debug dataplane packet-diag aggregate-logs packet-diag.log is aggregated PA-3050-A(active)> Then have a look at the logs, which are many hundreds of lines long matching traffic completley unrelated to the filter: 2015-11-23 13:17:55.332 +0000 debug: pan_cfg_nat_ruledata_lookup(pan_cfg_nat_policy.c:252): Rule: index=106 name=Default Outbound, cfg_pool_idx=53 cfg_fallback_pool_idx=0 2015-11-23 13:17:55.332 +0000 debug: pan_flow_nat_setup_session(src/pan_flow_nat.c:2128): NAT Rule: name=Default Outbound, cfg_pool_idx=53; Session: index=491969, nat_pool_idx=53 2015-11-23 13:17:55.332 +0000 Error: pan_cfg_app_policy_lookup_i(pan_cfg_policy.c:323): no rule is matched 2015-11-23 13:17:55.333 +0000 Error: pan_cfg_app_policy_lookup_i(pan_cfg_policy.c:323): no rule is matched 2015-11-23 13:17:55.333 +0000 Error: pan_appid_finish(pan_appid_proc.c:2454): pan_appid_policy_lookup() failed == 2015-11-23 13:17:58.024 +0000 == Packet received at fastpath stage Packet info: len 64 port 48 interface 256 vsys 1 wqe index 223936 packet 0x0x800000003228b0e2 Packet decoded dump: L2: 20:b3:99:57:98:f5->00:1b:17:00:01:30, VLAN 110 (0x8100 0x006e), type 0x0800 IP: 192.168.69.149->192.168.215.14, protocol 17 version 4, ihl 5, tos 0x00, len 45, id 3483, frag_off 0x0000, ttl 126, checksum 37168 UDP: sport 49336, dport 47808, len 25, checksum 15361 Flow fastpath, session 161631 Forwarding lookup, ingress interface 256 L3 mode, virtual-router 8 Route lookup in virtual-router 8, IP 192.168.215.14 Route found, interface ae2.1, zone 18, nexthop 192.168.249.142 Resolve ARP for IP 192.168.249.142 on interface ae2.1 ARP entry found on interface 260 Transmit packet on port 49 However i do actually find what i'm looking for: == 2015-11-23 13:18:10.113 +0000 == Packet received at ingress stage Packet info: len 66 port 49 interface 292 vsys 1 wqe index 222463 packet 0x0x80000000344ce0e2 Packet decoded dump: L2: 20:b3:99:57:98:f3->00:1b:17:00:01:31, VLAN 135 (0x8100 0x0087), type 0x0800 IP: 10.20.11.173->*.*.*.*, protocol 6 version 4, ihl 5, tos 0x20, len 48, id 7477, frag_off 0x4000, ttl 127, checksum 51783 TCP: sport 51822, dport 443, seq 686207197, ack 0, reserved 0, offset 7, window 8192, checksum 43334, flags 0x0002 ( SYN), urgent data 0 TCP option: 00000000: 02 04 05 74 01 01 04 02 ...t.... Flow lookup, key word0 0xca6e01bb000a0600 word1 0 Session setup: vsys 1 No active flow found, enqueue to create session == 2015-11-23 13:18:10.113 +0000 == Packet received at slowpath stage Packet info: len 66 port 49 interface 292 vsys 1 wqe index 222463 packet 0x0x80000000344ce0e2 Packet decoded dump: L2: 20:b3:99:57:98:f3->00:1b:17:00:01:31, VLAN 135 (0x8100 0x0087), type 0x0800 IP: 10.20.11.173->*.*.*.*, protocol 6 version 4, ihl 5, tos 0x20, len 48, id 7477, frag_off 0x4000, ttl 127, checksum 51783 TCP: sport 51822, dport 443, seq 686207197, ack 0, reserved 0, offset 7, window 8192, checksum 43334, flags 0x0002 ( SYN), urgent data 0 TCP option: 00000000: 02 04 05 74 01 01 04 02 ...t.... Session setup: vsys 1 PBF lookup (vsys 1) with application none Packet matches PBF policy (vsys 1) rule idx 3 (id 15) for c2s. 67%PBF policy rule 3 is NO-PBF. Packet dropped, no route during session setup Packet dropped, forwarding info unavailable for policy lookup Packet dropped, Session setup failed So this is great, but why do i get hundreds of lines in the log relating to packets that don't match the filter? I can't find a way to SCP this log file off the box either - you only seem to be able to output it to the screen. Many thanks, Mark.

PKCCommsTeam · ‎10-30-2015

Hi there, We have just moved from a Juniper SSG-550 with around 700 policies to a PaloAlto 3050. Naturally this has thrown up a few issues! Can anyone explain how to do the equivalent of a Juniper “debug flow basic” on the PaloAlto? On the Juniper, this would all you to follow the journey of a packet from ingress to egress, through the entire decision making progress of the firewall as it processed the packet making troubleshooting very simple. I’m finding that packet captures, “test” commands and “debug dataplane packet-diag set log feature flow basic” on the PaloAlto a little erratic. To do the dataplane flow debug I’m following instructions here: https://live.paloaltonetworks.com/t5/Management-Articles/Packet-Capture-Debug-Flow-basic-and-Counter-Commands/ta-p/66224 However, i'm finding that filters do not appear to be getting applied correctly. More often than not the logs appear to show no traffic filter is in effect and everything is being logged, yet "debug dataplane packet-diag show setting" shows that the packet filter is enabled, and correctly configured. Can anyone help? We are running v7.0.3. Many thanks, Mark.

Member Since	‎04-09-2015 01:58 PM
Date Last Visited	‎06-02-2022 05:12 AM
Posts	5

Online Status	Offline
Date Last Visited	‎06-02-2022 05:12 AM

About PKCCommsTeam

Re: Internal Host Detection Issue

Internal Host Detection Issue

GlobalProtect Gateway with Multiple Client Authentication Config

Re: Debugging packet flow.

Debugging packet flow.

Re: Internal Host Detection Issue

Internal Host Detection Issue

GlobalProtect Gateway with Multiple Client Authentication Config

Re: Debugging packet flow.

Debugging packet flow.