Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Global Protect VPN Client - 3day bridge running Sev-A

Users recently migrated FROM Cisco Anyconnect VPN client -TO- Palo Alto Global Protect (GP).

This case is not for faint hearted.

Remote working end-user can connect with GP to local wifi hotspot using mobile date, no problems at all.

But when connecting to local 'home router' with either wired or wireless, most GP connection attempts fail. Looking at capture below (had to cut out IPs), I see a fundamental problem with the GP application. Essentially I am observing a series of the following:

  1. syn
  2. syn-ack
  3. ack
  4. fin-ack (client)
  5. fin-ack
  6. ack

Regarding FIN, this is just something general, I have always see FIN-ACK, but never a FIN, I suspect that is TCP standards, but it would be nice to see FIN handshake is the same fashion as we see SYN start-up. Both use three packets to complete so I don't see the need for only FIN-ACKs.

Turning now back to the original problem here is the packet capture snippet:

(You need onedrive account I think) 1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN

https://![1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN]

Global Protect VPN Client - 3day bridge running Sev-A

Users recently migrated FROM Cisco Anyconnect VPN client -TO- Palo Alto Global Protect (GP).

This case is not for the faint hearted.

Remote working end-user can connect with GP to local wifi hotspot using mobile date, no problems at all.

But when connecting to local 'home router' with either wired or wireless, most GP connection attempts fail. Looking at capture below (had to cut out IPs), I see a fundamental problem with the GP application. Essentially I am observing a series of the following:

  1. syn
  2. syn-ack
  3. ack
  4. fin-ack (client)
  5. fin-ack
  6. ack

Regarding FIN, this is just something general, I have always see FIN-ACK, but never a FIN, I suspect that is TCP standards, but it would be nice to see FIN handshake is the same fashion as we see SYN start-up. Both use three packets to complete so I don't see the need for only FIN-ACKs.

Turning now back to the original problem here is the packet capture snippet:

(You need onedrive account I think) 1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN

https://![1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN]

Global Protect VPN Client - 3day bridge running Sev-A

Users recently migrated FROM Cisco Anyconnect VPN client -TO- Palo Alto Global Protect (GP).

This case is not for the faint hearted.

Remote working end-user can connect with GP to local wifi hotspot using mobile date, no problems at all.

But when connecting to local 'home router' with either wired or wireless, most GP connection attempts fail. fail, that is most not all.

Looking at capture below (had to cut out IPs), I see a fundamental problem suspect problems with the GP application. Essentially I am observing a series of the following:

  1. syn
  2. syn-ack
  3. ack
  4. fin-ack (client)
  5. fin-ack
  6. ack

Regarding FIN, this is just something general, I have always see FIN-ACK, but never a FIN, I suspect that is TCP standards, but it would be nice to see FIN handshake is the same fashion as we see SYN start-up. Both use three packets to complete so I don't see the need for only FIN-ACKs.

Turning now back to the original problem here is the packet capture snippet:

(You need onedrive account I think) 1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN

https://![1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN]

Global Protect VPN Client - 3day bridge running Sev-A

Users recently migrated FROM Cisco Anyconnect VPN client -TO- Palo Alto Global Protect (GP).

This case is not for the faint hearted.

Remote working end-user can connect with GP to local wifi hotspot using mobile date, no problems at all.

But when connecting to local 'home router' with either wired or wireless, most GP connection attempts fail, that is most not all.

Looking at capture below (had to cut out IPs), I suspect problems with the GP application. Essentially I am observing a series of the following:

  1. syn
  2. syn-ack
  3. ack
  4. fin-ack (client)
  5. fin-ack
  6. ack

Regarding FIN, this is just something general, I have always see FIN-ACK, but never a FIN, I suspect that is TCP standards, but it would be nice to see FIN handshake is the same fashion as we see SYN start-up. Both use three packets to complete so I don't see the need for only FIN-ACKs.

Turning now back to the original problem here is the packet capture snippet:

(You need onedrive account I think) 1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN

https://![1drv.ms/u/s!ApSvUszXYued30wmdByb2zPbJYNq?e=FaVhYN]think)