Ask Your Question

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

asked 2022-08-06 08:13:28 +0000

ajaznawaz gravatar image

updated 2022-08-06 13:26:25 +0000

grahamb gravatar image

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)

edit retag flag offensive close merge delete


I have query around tcp port 'reuse'.

we see a syn just above the first 'retransmission', nothing is received back so the client issues another syn and then another.

In terms of the IP header the ID increments by one after each packet ...

would i be right is asserting that the client is misbehaving, or am I missing something here ...

ajaznawaz gravatar imageajaznawaz ( 2022-08-09 21:25:14 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2022-08-09 22:13:15 +0000

André gravatar image

This looks like a firewall or alike is doing Deep Packet Inspection. For example for a web request the TCP connection is first set-up, then the request is send. But if that request is intercepted and an 'access denied' response is generated, you won't see that on the network level. After that the TCP connection is teared down normally. Exactly what the picture shows.

most GP connection attempts fail, that is most not all.

Maybe some request are allowed by DPI.

Regarding FIN:
Short answer: you can't have a FIN without an ACK.

Long answer:
When the ACK flag is set it means that the 'Acknowledgment Number' field (tcp.ack) is used and that field refers to a previous received segment to ACKnowledge it was received.
Obviously there is nothing to acknowledge on the very first packet, so the first SYN has no ACK.
Since you can only FINalize an active TCP connection, there is always something to ACK when using FIN.

But a RST can be without an ACK. RST-ACK is send when an active connection must be aborted. A RST without an ACK is send when the sender of the RST has no active connection when receiving a stray packet.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2022-08-06 08:13:28 +0000

Seen: 93 times

Last updated: Aug 09 '22