About DongQu

DongQu · ‎02-21-2022

hello guys, Some of the users got the DNS issue for the external websites after globalprotect connected, the users are able to ping the external IP address but just the DNS does not work. There was no change applied to the Firewall recently and only a few users got this issue. not sure if someone else got the same issue and how did you fix that? Thanks

DongQu · ‎12-28-2021

I forgot to mention that the client is an Android Phone, the TAC told me that the "domain" based split does not support the mobile devices. I tested the settings on a laptop which was working well. Closing this case.

DongQu · ‎12-28-2021

yes, we have the license.

DongQu · ‎12-26-2021

Hello It was using the DNS provide by the tunnel.

DongQu · ‎12-26-2021

thanks for the reply but that does not work, I still cannot access to any google sites...

DongQu · ‎12-24-2021

hello everyone Merry Xmas, Our SSLVPN has tunnel split enabled, but I want to allow all my traffic or the *.google.com through the VPN, so I tried: 1. added 0.0.0.0/0 to here, does not work. 2. added *.google.com to here, does not work. Can please someone let me know do I still miss something? Thanks

DongQu · ‎09-07-2021

hello guys, Did some of your GP uses complain that they lost the internet after GP connected? It just happens recently and for some users only. GP version is 5.2.7 Thanks

DongQu · ‎07-09-2021

hello @Remo "unknown udp", so I defined an application and specified the "udp timeout", it worked. but I am not sure why the "session timeout" does not work in the global setting.

DongQu · ‎07-08-2021

Hi @Remo I've tried to increasing the session timeout, unfortunately it did not work. As I only have 1 public IP for natting, is it possible to create a separate nat policy for a particular traffic? Thanks

DongQu · ‎07-08-2021

Hello everyone The NAT type we are using is "Dynamic IP and Port", the Palo Alto Networks firewall translates the source IP address or range to a single IP address. for this conversion, when the packets arriving the FW, we can see the source port is all the same But while the packets leaving the FW, the source port was natted to multiple ports This brings a problem that the destination will close the conversion once it detects the source port changed. Is there any way to keep the source port is natted to a single port all the time? Thanks

DongQu · ‎06-10-2021

hello I am trying to enable the tunnel monitoring for an IPSec tunnel(not sure what device the other end is using) and got very interesting result. The proxy id config is local:172.16.17.3/32 remote: 146.48.211.0/24 My client subnet 172.16.2.0/24 will be natted to 172.16.17.3/32 while accessing to 146.48.211.0/24. I assigned an IP 172.16.2.222 to the tunnel interface and it is able to ping 146.48.211.163 before enabling the "tunnel monitoring" 146.48.211.163 is being used as the dest IP in the tunnel monitoring config. The result after enabling tunnel monitoring is really interesting and I cannot understand why. As long as I enabled the tunnel monitor, the tunnel status icon changes to "red" and the tunnel interface is not able to ping the dest IP. monitor: on monitor status: down monitor dest: 146.48.211.163 monitor interval: 2 seconds monitor threshold: 5 probe losses monitor bitmap: 00000 monitor packets sent: 118 monitor packets recv: 0

DongQu · ‎05-03-2021

As I cannot connect to the ASA to initial any traffic for testing purposes, so I simulated the settings on our 2 PAs. The diagram is 172.16.4.241 is natted to 123.103.202.111 192.168.55.250 is natted to 78.152.42.166 SYD-PA config is 1. static routing to 78.152.42.166 point to the tunnel interface 2. outbound security policy is from trust zone 172.16.4.241 to ipsec zone 78.152.42.166, allow any 3. Inbound security policy is from IPsec zone 78.152.42.166 to trust zone 123.103.202.111, allow any 4. NAT policy is from trust zone to ipsec zone, 172.16.4.241 source NAT to 123.103.202.111, bi-direction is yes LDN-PA config is 1. static routing to 123.103.202.111 point to the tunnel interface 2. outbound security policy is from trust zone 192.168.55.250 to ipsec zone 123.103.202.111, allow any 3. Inbound security policy is from ipsec zone 123.103.202.111 to trust zone 78.152.42.166, allow any 4. NAT policy is from trust zone to ipsec zone. 192.168.55.250 source NAT to 78.152.42.166, bi-direction is yes my testing result on syd sw, ping 78.152.42.166 from 172.16.4.241, ping failed. I can see the ping log on SYD-PA and the log detail shows the NAT was triggered. I cannot see any logs from/to 123.103.202.111 on ldn-pa I started a pcap on ldn pa and I can see the icmp packets in drp.pcap and rcv.pcap I've no idea where the issue is...

DongQu · ‎04-30-2021

DongQu · ‎04-30-2021

hello @aleksandar.astardzhiev hello @AlexanderAstardzhiev "The PAN FW has nothing to do with 5.5.5.x addresses, isn't this the whole purpose of the GRE tunnel? - Packets from the client will enter the router - Which will add GRE encapsulation, which boilse down to a new IP header - Now the outer IP header (that is used for routing decisions) is has different source and destination addresses - more specifically your GRE tunnel addresses, right? - When the packet reaches the PAN FW and if you don't apply any tunnel content inspection it will see only the 3.3.3.3 and 192.168.55.250." ---------------This is exactly what I thought. When 192.168.20.34 sending a packet to the 5.123.111.144, the traffic flow should be (my understanding, please correct if anything wrong) Original packet send to GRE device S:192.168.20.34 D:5.253.111.144 GRE tunnel encapsulates the original packet by adding an extra header, so the source/destination IP in the packet changes to S: 192.168.55.250 192.168.20.34 😧 3.3.3.3 5.153.111.144 My firewall NAT the 192.168.55.250 to 4.4.4.4 then send the packet towards to the IPsec tunnel, ipsec tunnel add extra header S: 1.1.1.1 4.4.4.4 192.168.20.34 😧 2.2.2.2 3.3.3.3 5.153.111.144 The ASA removes the IPSec header and delivers it to the other side GRE device S: 4.4.4.4 192.168.20.34 😧 3.3.3..3 5.153.111.144 The other side GRE device removes the GRE header and delivers the original packet to the server S: 192.168.20.34 😧 5.153.111.144 I thought we should be able to see the log on PA from 192.168.55.250 to 3.3.3.3 but I cannot. Why? I took a pcap on the PA, the packet I got is, but cannot see it in the log

DongQu · ‎04-28-2021

hello @aleksandar.astardzhiev for stage 2, what I want to achieve is 1. the tunnel IP can ping each other, 5.5.5.6 <> 5.5.5.5 2. the client 192.168.20.34 is able to ping 5.123.111.144 for 1: I need to add static routing on PA for dest 5.5.5.5, point to the ipsec tunnel interface and add static for my side tunnel IP 5.5.5.6, point to internal interface, as before adding the routing entry, the PA goes to 5.5.5.0/24 via the default route to the internet So the outbound security policy should be trust zone > ipsec zone source 5.5.5.6 to dest 5.5.5.5 inbound security policy should be ipsec > trust zone source 5.5.5.5 to des 5.5.5.6 is this correct? for your question about stage2 Or your want to "hide" the client ip behind 5.5.5.6 and the server behind 5.5.5.5? --- exactly. I have static routing "ip route 5.123.111.144 255.255.255.0 tunnel 2" on my switch, so when my client 192.168.20.34 pinging 5.123.111.144, the GRE switch will add extra header S:5.5.5.6 D:5.5.5.5 before the raw packet header S:192.168.20.34 D 5.123.111.144 So I dont need to create policy for 192.168.20.24 <> 5.123.111.144 as the packet header has been changed after the packet leaving the tunnel towards to PA. I hope I am making sense(excuse for my bad English)

Member Since	‎04-21-2019 08:02 PM
Date Last Visited	‎03-11-2022 12:52 AM
Posts	24
Total Likes Received	4

Online Status	Offline
Date Last Visited	‎03-11-2022 12:52 AM

About DongQu

DNS resolution stops working as long as GlobalProtect connected

Re: GlobalProtect - failed to allow *.google.com through the VPN

Re: GlobalProtect - failed to allow *.google.com through the VPN

Re: GlobalProtect - failed to allow *.google.com through the VPN

Re: GlobalProtect - failed to allow *.google.com through the VPN

GlobalProtect - failed to allow *.google.com through the VPN

GlobalProtect breaks internet access

Re: The source port was natted to multiple source ports while the packets leaving the FW

Re: The source port was natted to multiple source ports while the packets leaving the FW

The source port was natted to multiple source ports while the packets leaving the FW

NAT over IPSec tunnel.

Re: GlobalProtect - failed to allow *.google.com through the VPN

Re: GlobalProtect - failed to allow *.google.com through the VPN

DNS resolution stops working as long as GlobalProtect connected

Re: GlobalProtect - failed to allow *.google.com through the VPN

Re: GlobalProtect - failed to allow *.google.com through the VPN

Re: GlobalProtect - failed to allow *.google.com through the VPN

Re: GlobalProtect - failed to allow *.google.com through the VPN

GlobalProtect - failed to allow *.google.com through the VPN

GlobalProtect breaks internet access

Re: The source port was natted to multiple source ports while the packets leaving the FW

Re: The source port was natted to multiple source ports while the packets leaving the FW

The source port was natted to multiple source ports while the packets leaving the FW

tunnel monitor works improperly

Re: GRE over IPSec with NAT

Re: GRE over IPSec with NAT

Re: GRE over IPSec with NAT

Re: GRE over IPSec with NAT

Unlock your full community experience!

About DongQu