Finally IPv6 over GlobalProtect, or should i say v6IP?

[P.Braat]

About 2 months ago I was thrilled to hear that PANOS 8 was coming out and that it would bring us IPv6 inside a Globalprotect VPN. After fixing the "licence issue", i finally came arround to doing the upgrade and eagerly started to configure a tunnel for IPv6. To my regret it did not work. As I figured it, it would probably be some remote setting somewhere, so I soldiered on and tried just about everything. I was really getting frustrated. I had IPv6 running through the firewall itself and it was going through ipsec site2site tunnels. Eventualy i started to do some packet captureing. I noticed soming really odd... my packets coming from the firewall were nicely marked as ipv6 but the packets from my client weren't. After looking into the hex i think i have the answer, packets from the firewall are marked with 0x86dd (IPv6) and packets comming from the client are marked with 0xdd86 (???)

So i guess that this is a bug, or can someone tell me otherwise...

If someone else is having the same problem, now you know. I will be starting a ticket for this and maybe this can be fixed soon.

[bgmncwj]

What was the license issue? I'm hoping to use IPv6 over GlobalProtect soon and am just licensed for Support, URL, Threat prevention and Wildfire.

[P.Braat]

Sorry for the late reply. The only "issue" is that, as stated here, you will need a global portect licence to be able to use ipv6 in a remote access tunnel at this moment. So with only the licences you mensioned it will not work. I have tried it in a lab and i beleave you don't even get an ipv6 address assigned on the client side when you don't heve the licence.

But besides that, it doesn't even work now because of the byte swap. (but I do expect that that will be fixed soon)

[bgmncwj]

No problem, thanks for replying. I was afraid of that. I even checked with my SE right after 8.0 was released and he assured me that I would in fact not need that license to enable IPv6 for remote access. Oh well, time to see what that'll run us.

[jvalentine]

It's documented here:

 - https://www.paloaltonetworks.com/documentation/80/pan-os/newfeaturesguide/globalprotect-features/ipv...

[P.Braat]

I started to do some extra analysis on th packets and it seems there is more that does not seem correct:

ping initiated from the firewall:

Frame 429: 118 bytes on wire (944 bits), 118 bytes captured (944 bits)
Ethernet II, Src: PaloAlto_fb:40:04 (00:1b:17:fb:40:04), Dst: 00:70:76:69:66:00 (00:70:76:69:66:00)
    Destination: 00:70:76:69:66:00 (00:70:76:69:66:00)
    Source: PaloAlto_fb:40:04 (00:1b:17:fb:40:04)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fdff:ff::998, Dst: fdff:ff::136
Internet Control Message Protocol v6

0000   00 70 76 69 66 00 00 1b 17 fb 40 04 86 dd 60 00
0010   00 00 00 40 3a 40 fd ff 00 ff 00 00 00 00 00 00
0020   00 00 00 00 09 98 fd ff 00 ff 00 00 00 00 00 00
0030   00 00 00 00 01 36 80 00 9a 7a da 45 00 00 a5 25
0040   ff 58 00 00 00 00 9e a7 00 00 00 00 00 00 10 11
0050   12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21
0060   22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31
0070   32 33 34 35 36 37

ping reply initiated from the client:
Frame 430: 118 bytes on wire (944 bits), 118 bytes captured (944 bits)
Ethernet II, Src: 00:00:00_00:00:00 (01:00:00:00:00:00), Dst: 3c:4d:86:dd:68:00 (3c:4d:86:dd:68:00)
    Destination: 3c:4d:86:dd:68:00 (3c:4d:86:dd:68:00)
    Source: 00:00:00_00:00:00 (01:00:00:00:00:00)
    Type: Unknown (0xdd86)
Data (104 bytes)

0000   3c 4d 86 dd 68 00 01 00 00 00 00 00 dd 86 60 00
0010   00 00 00 40 3a 80 fd ff 00 ff 00 00 00 00 00 00
0020   00 00 00 00 01 36 fd ff 00 ff 00 00 00 00 00 00
0030   00 00 00 00 09 98 81 00 7a 59 9e 4d 00 86 4f 27
0040   ff 58 00 00 00 00 44 39 0b 00 00 00 00 00 10 11
0050   12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21
0060   22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31
0070   32 33 34 35 36 37

##############
different
##############
dstmac: 00 1b 17 fb 40 04 --> 3c 4d 86 dd 68 00
srcmac: 00 70 76 69 66 00 --> 01 00 00 00 00 00
protocol: 86 dd --> dd 86

data, first part: a5 25 ff 58 00 00 00 00 9e a7 00 --> 4f 27 ff 58 00 00 00 00 44 39 0b

(i left out stuff that should be changeing. The last part seems some sort of counter and is probably something custom from paloalo itself.)

so it seems there is more going on.

[P.Braat]

Ok, this is getting interesting, i have just deployed a fresh 8.0.0 firewall in azure and upgraded to 8.0.2, and as of yet ipv6 in both ssl and ipsec is working. I also did a wire capture there an it the anomaly of the ipv6 byteswap did not occur (off course, otherwise it would not work).

So why is it happenning in my other setup. There is a possability that azure is different, and ther is also the posability that it's because of the upgrades of my original firewall. I did not get arround to upgrading my original firewall to 8.0.2, so that could also have an effect.

If i ever figure out what this is i'll be sure to post it here. For now i'm just happy it's working.