Opened 17 months ago

Closed 13 months ago

Last modified 5 months ago

#1041 closed request (wontfix)

Palo Alto SSL VPN does not work on nat64 ssid

Reported by: Bill Fenner Owned by: panda@…
Priority: tbd Milestone: ietf-097
Component: nat64 Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

My Palo Alto SSL VPN client fails to connect when using the nat64 ssid. This is not a surprise given all the "NO"s at https://live.paloaltonetworks.com/t5/tkb/articleprintpage/tkb-id/learning_tkb/article-id/46 on the line about SSL VPN.

Change history (5)

comment:1 Changed 17 months ago by Bill Fenner

Interestingly, wireshark does not think that it saw the whole TCP session. We can see the SSL handshake start, and then we see wireshark get upset about reassembly:

 25   8.282992 2001:67c:370:1998:ddcb:163b:2f07:d708 -> 64:ff9b::a2d2:8267 TLSv1.2 447 Application Data
 26   8.288365 2001:67c:370:1998:ddcb:163b:2f07:d708 -> 64:ff9b::a2d2:8267 TLSv1.2 159 Application Data
 27   8.464816 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TCP 74 443 → 55101 [ACK] Seq=3719 Ack=1017 Win=262140 Len=0
 28   8.471867 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TLSv1.2 799 Application Data
 29   8.471913 2001:67c:370:1998:ddcb:163b:2f07:d708 -> 64:ff9b::a2d2:8267 TCP 74 55101 → 443 [ACK] Seq=1017 Ack=4444 Win=261408 Len=0
 30   8.587074 2001:67c:370:1998:ddcb:163b:2f07:d708 -> 64:ff9b::a2d2:8267 TLSv1.2 447 Application Data
 31   8.587172 2001:67c:370:1998:ddcb:163b:2f07:d708 -> 64:ff9b::a2d2:8267 TLSv1.2 367 Application Data
 32   8.764831 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TCP 74 443 → 55101 [ACK] Seq=4444 Ack=1683 Win=262140 Len=0
 33   8.820807 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TLSv1.2 179 [TCP Previous segment not captured] Ignored Unknown Record
 34   8.820876 2001:67c:370:1998:ddcb:163b:2f07:d708 -> 64:ff9b::a2d2:8267 TCP 86 [TCP Dup ACK 29#1] 55101 → 443 [ACK] Seq=1683 Ack=4444 Win=262144 Len=0 SLE=5864 SRE=5969
 35   8.822085 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TCP 1494 [TCP Out-Of-Order] 443 → 55101 [ACK] Seq=4444 Ack=1683 Win=262140 Len=1420
 36   8.822089 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TLSv1.2 179 [TCP Previous segment not captured] Ignored Unknown Record
 37   8.822090 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TCP 1494 [TCP Out-Of-Order] 443 → 55101 [ACK] Seq=5969 Ack=1683 Win=262140 Len=1420
 38   8.822091 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TLSv1.2 179 [TCP Previous segment not captured] Ignored Unknown Record
 39   8.822091 64:ff9b::a2d2:8267 -> 2001:67c:370:1998:ddcb:163b:2f07:d708 TCP 1494 [TCP Out-Of-Order] 443 → 55101 [ACK] Seq=7494 Ack=1683 Win=262140 Len=1420

so this may not be *only* a software protocol support issue.

comment:2 Changed 17 months ago by Bill Fenner

It looks like wireshark's reassembly may be getting confused by the massive packet reordering. Check out the sequence numbers here.

15:52:29.522555 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 171:896, ack 747, win 65535, length 725
15:52:29.758493 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 2316:2421, ack 1413, win 65535, length 105
15:52:29.758701 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 896:2316, ack 1413, win 65535, length 1420
15:52:29.758703 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 3841:3946, ack 1413, win 65535, length 105
15:52:29.758703 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 2421:3841, ack 1413, win 65535, length 1420
15:52:29.758704 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 5366:5471, ack 1413, win 65535, length 105
15:52:29.758705 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 3946:5366, ack 1413, win 65535, length 1420
15:52:29.758752 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 5471:6164, ack 1413, win 65535, length 693
15:52:29.761715 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 7584:7689, ack 1413, win 65535, length 105
15:52:29.761717 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 6164:7584, ack 1413, win 65535, length 1420
15:52:29.761718 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 9109:9214, ack 1413, win 65535, length 105
15:52:29.761719 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 7689:9109, ack 1413, win 65535, length 1420
15:52:29.761720 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 10634:10739, ack 1413, win 65535, length 105
15:52:29.761844 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 9214:10634, ack 1413, win 65535, length 1420
15:52:29.761847 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 12159:12264, ack 1413, win 65535, length 105
15:52:29.761847 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 10739:12159, ack 1413, win 65535, length 1420
15:52:29.761848 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [P.], seq 13684:13789, ack 1413, win 65535, length 105
15:52:29.771230 IP6 64:ff9b::a2d2:8267.443 > 2001:67c:370:1998:ddcb:163b:2f07:d708.55149: Flags [.], seq 12264:13684, ack 1413, win 65535, length 1420

comment:3 Changed 17 months ago by Bill Fenner

I also see the reordering on IPv4, so it is a characteristic of our network here, not of nat64 in particular. Back to assuming that the failure is because the client explicitly doesn't support IPv6, even in the most recent software version.

comment:4 Changed 13 months ago by panda@…

Resolution: wontfix
Status: newclosed

Thank you for your report.

This may not the issue of the application but I would close this ticket now because the IETF 97 meeting was over and thus this is not reproducible on that infrastructure. Please create another ticket when the same issue occurs in the upcoming meetings.

Thank you.

comment:5 Changed 5 months ago by Rick Alfvin

Milestone: ietf-97ietf-097

Milestone renamed

Note: See TracTickets for help on using tickets.