Testing IPv6 using test-ipv6.com

[gfowler]

I'm unable to successfully complete test-ipv6.com (10 out of 10) without doing either 'Any' application or adding unknown-tcp as an application.

When I do just web-browsing, I get denies on 'unknown-tcp'.

Is there something different I can do without allowing wide open browsing for IPv6?   Is this a deficiency in the Applications list or the way web-browsing is detected over IPv6?

Is there a custom App-ID I can add?

Test completes 10/10:

Application: Any; Service: service-http

or

Application: web-browsing, unknown-tcp; Service: service-http

Test fails with 1/10:

Application: web-browsing; Service: application-default

Device is a 2020 running 4.1.7 standalone.

Anti-virus DB: 831-1143

Application and Threat DB: 327-1497

URL DB:  3936

[sdurga]

I have done this test on my device and it worked fine ( Test completed 10/10) with web-browsing and service: application-default. I have the same app version 327-1497, panos 4.1.7 and my sessions are getting identified as web-browsing, I am not sure what we are missing here.

[gfowler]

I'm using a Hurricane Electric tunnel for my IPv6 connectivity; terminated on a router on the public side of the 2020.

Tests Failed:

Test for Dual Stack DNS and large packet - blurb about sending and receiving large packets.

Test IPv6 large packet - blurb about PMTUD issues if the test fails

[gfowler]

Closer examination is pointing to the 2020 not properly processing ICMP6 packet too big messages.

[icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480

These ICMP6 messages are being generated by the router that handles the Hurricane Electric tunnel.

Even when I add a rule to explicitly allow "ipv6-icmp" for any/any source to any/any destination, they do not make it through the 2020.

I've also add a management profile to the external interface to allow ICMPs to the external interface.  The ICMP6 packets too big messages are, of course, destine to the global IPv6 address of the internal workstation, not the 2020's external IPv6 address.

Oddly enough, everything works when I allow pure port 80 traffic, or the unknown-tcp application.

[jvalentine]

I have a tunnelbroker.net IPv6 /48 routed through a Juniper router into my Palo Alto Networks firewall and can pass 10/10 every time using my Mac. 

I'll try it out with a PA2020 and 4.1.7 if I get some free time and see if the behavior is any different. 

[gfowler]

Plot thickens..

Thus far, I've been running these tests on a Windows 7 32-bit system using IE only.

Just installed Firefox 15.0.1.   When IE fails the tests, firefox succeeds and continues to succeed.

I conducted another packet capture and the capture clearly shows ICMPv6 Packet too big messages do not get through the 2020 when IE 8 is used.  But ICMPv6 Packet too big messages do get forwarded through when FF 15.0.1 is used.

The main difference seems to be in the order of the HTTP headers.  Below are the HTTP request headers with the Cookies removed.  These aren't necessarily from the same point in the test.

Firefox:

GET /ip/?callback=_jqjsp HTTP/1.1

Host: ipv6.test-ipv6.com

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1

Accept: */*

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip, deflate

Connection: keep-alive

Referer: http://test-ipv6.com/

Cache-Control: max-age=0

IE:

GET /ip/?callback=_jqjsp HTTP/1.1

Accept: */*

Referer: http://test-ipv6.com/

Accept-Language: en-US

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)

Accept-Encoding: gzip, deflate

Host: ipv6.test-ipv6.com

Connection: Keep-Alive

[gfowler]

Updated the Applications and Threat DB to 328-1503.   No change.

I have noticed that if I run the test (test-ipv6.com) on firefox and allow it to complete, and then immediately run the test on IE, IE will complete 10/10.

But if I wait some period of time, 30 second per se, IE will continue failing again.

[bpappas]

@Gary Fowler: out of curiosity, have you tried allowing ipv6-icmp as an application in your security policy? if so did it make a difference?

[gfowler]

Yes I did.  Details are in the #3 reply of this thread.

And It did not make a difference.  The application 'ipv6-icmp' does not appear to apply to the ICMPv6 service alone.

[gfowler]

Jvalentine,

Do you have the ability to spin up a Windows 7 VM and run the test again using IE 8? 

[gfowler]

Updated Applications and Threats DB to 329-1511.  No change.

[jvalentine]

I've got a Win7-x86 VM but it's running IE9.  With that in place, I am still passing 10/10.  Still not running a 2000-series box with 4.1.7, though.  It may be a little while until I can run a test with that specific firewall and version. 

[KP]

I've seen several times that on 4.1.x, with IPv6 traffic, application detection doesn't always seem to work correctly.

Youtube traffic is usually unknown-tcp, and may only be detected as youtube after several hundreds of MB's transferred.

Doesn't look like this will be solved with an application update and may need an OS update .......

Hopefully IPv6 will be better supported on Version 5 (application-id, user-id etc.)

[jvalentine]

Gary:

I spun up a Windows 7 x64 VM (completely unpatched) running IE8.

Tests run great.  I get 10/10 (and I ran it multiple times).  This is also from a 4.1.7 PAN-OS firewall, although not a PA2000.

I'm not sure when I'll have a chance to try this with a PA2000, but if the oppty comes up I'll give it a go. 

Good luck.   

[gfowler]

Updated PA-2020 to 4.1.8..   No change

Updated Windows 7 32-bit to Service Pack 1; No change

Updated IE8 to IE9; No change.

Installed Chrome.  Same effect as IE8/IE9.

If I run Firefox 15.0.1, the test succeeds.  If I run either IE8/IE9 or Chrome within 30 seconds, they pass the test.

I've shown that ICMPv6 Packet too big messages only pass though the 2020 when Firefox is used; and for about 30 seconds thereafter.   So I assume the issue is in the http decoder.