APP-ID detection capabilities in IP64 tunnels

[wimjuste]

Hi,

I placed a PAN device in VWIRE mode on the WAN side of a internet connection.

I planned to test the APP-ID capabilities of detecting IP64 tunnels.

Over this WAN link, a 6-4 tunnel exists with Hurricane tunnel-brooker.

The APP-ID is able to detect the 6-4 tunnel and identifies it as IPV6 application.

But when a native IPv6 client is surfing the web to GOOGLE or FACEBOOK (IPv6 addresses), thus using this 6-4 tunn, the APP-ID does not preform continuous APP validation.

So, we lose application visibility within the 6-4 tunnel towards Hurricane.

Isn't PAN able to identify APPs within 6-4 tunnels? (ISATAP, TEREDO, GRE) (only tested the Hurricane tunnels)

Or once the protocol ID 41 is identified  (=6-4 tunnel), no more continuous is performed ?

Thanks,

Kind regards,

Wim

[jvalentine · Accepted solution]

As far as I know, Palo Alto Networks firewalls do not dig inside of 6-in-4 tunnels.  If you place the v-wire pre-6-in-4 tunnel, the Palo Alto can understand the native v6 applications and act on those appropriately. 

[mikand]

What do you think is the probability that PA can do this in near future?

Because I understand that a single session can only have one appid at a time but what if a subappid is added or something like that?

Like if youtube is identified you will have:

appid: youtube

subappid: none

But if youtube is identified within a 6in4 tunnel you will have (for example):

appid: 6in4 tunnel

subappid: youtube

This way appid is the outer identified appid (the tunnel itself) while subappid is the inner identified appid (the content of the tunnel).

Specially now when IPv6 will grow and the organisations who cannot convert to IPv6 for one reason or another but still need to access IPv6 hosts will in many cases use various 6in4 tunnels and by that the good stuff of PA regarding application identification will virtually be lost.

[jvalentine]

It will only be lost if you have the Palo Alto Firewall inspect the traffic after it has been encapsulated in a 6-in-4 tunnel.  I use a 6-in-4 tunnel through tunnelbroker.net in my Palo Alto Networks environment, but the Palo Alto sees the traffic before 6-in-4 happens.  The Palo Alto is also doing v4 firewalling/routing, but I'll radically simplify it for the purposes of this discussion.  The (simplified) architecture looks like this:

client ---(v6)--- palo alto firewall ---(v6)---  wan router  ---(6-in-4 tunnel)---  tunnelbroker.net

The client is native v6.  The Palo Alto Firewall has a v6 interface on the inside and a v6 interface on the outside.  I'm currently doing Layer-3/routing in the Palo Alto Firewall, but this would also work if the firewall were in v-wire mode.  The wan router's inside interface is v6 only, and it's external interface is v4 only.  The wan router is doing the 6-in-4 encapsulation. 

In this environment, the Palo Alto sees the traffic before encapsulation and app-id in the IPv6 environment works great.  Facebook, Youtube, DNS, whatever... it's all identified and controllable.  Palo Alto has done a great job with v6 feature parity when it comes to the app-id engine. 

You will have the same visibility issues with protocol 41 (6-in-4 tunnels) as you would with GRE, IPSEC, MPLS, PPTP, SSL (without ssl decryption) if you look at that traffic _after_ it's been encapsulated.  The key is to control it before.  So make sure the Palo Alto Firewall gets to the traffic before the tunnel does. 

One last thing...  it's not feasible to have a v6-only client today.  So you will either need to:

1.) dual-stack the client - which will also require v4 interfaces on the Palo Alto firewall (this is what I'm doing today)  

2.) use the new NAT64 feature in PAN-OS 5.0.  This will allow the client to stay native v6, and if it needs to go to a v4 destination, the firewall nat that from v6 to v4.  I haven't had the time to try this out, but it's definitely interesting!

[mikand]

What about Teredo and other similar tunneling protocols for using IPv6 through a IPv4-only network?

The example I had in mind was a IPv4-only network where the servers and clients themselfs do the 6-in-4 stuff.

[jvalentine]

It sounds like an interesting feature, but definitely not possible today.  You'd have to file an RFE with your local sales engineer. 

With that in mind, it would be better to take control of IPv6 now and not let the clients & servers do their own tunneling.  Block teredo (there's an app-id for it) at your borders, and then start working on dual-stack and/or native v6 w/ NAT64.  That way you still have full visibility and control for v4 and v6 traffic. 

Good luck!