Cisco IOS FW on ipv6 tunnel - issues with Google Chrome?

[lobotiger]

Hey everyone.  I noticed this past week that I was having some issues in trying to get to some ipv6 related sites and didn't think much of it until I realized that it had been ongoing for more than a few days.

Problem I'm having is in trying to pull up websites like ipv6.google.com, ipv6.netflix.com, ipv6.cnn.com, etc while using Google Chrome.  Now I've been using Chrome for a while now and it has always worked perfectly fine with my ipv6 destinations and it seems like it's only something recent that's happened.

Now the weird part is this.  If I try a different web browser like IE or Firefox the websites come up super fast like normal.  Ok, so I figure it's Chrome then.  Well I decided to check on my 1811's config and to turn off the IOS firewall configuration on the Tunnel interface.  After doing that the websites come up perfectly fine in Chrome!   ???

So, any suggestions on how to proceed or has anyone noticed any issues with Chrome and ipv6 related sites?  I really hate going back to Firefox now since I've practically moved over entirely to Chrome and I don't like the fact of not having the firewall enabled on the tunnel.

Here is the configuration on my 1811 in case anyone sees something:

interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip flow egress
load-interval 30
ipv6 address 2001:470:1C:1C5::2/64
ipv6 enable
ipv6 traffic-filter IPV6_EXTERNAL_ACL in
ipv6 inspect ipv6-out out
tunnel source 68.179.104.125
tunnel destination 216.66.38.58
tunnel mode ipv6ip
tunnel bandwidth transmit 10000000
tunnel bandwidth receive 10000000
end

ipv6 inspect name ipv6-out icmp
ipv6 inspect name ipv6-out tcp
ipv6 inspect name ipv6-out udp
ipv6 inspect name ipv6-out ftp

ipv6 access-list IPV6_EXTERNAL_ACL
permit icmp any any nd-na
permit icmp any any nd-ns
permit icmp any any echo-reply
sequence 35 permit icmp any any echo-request
sequence 40 permit icmp any any hop-limit
permit icmp any any time-exceeded
permit tcp any host 2001:470:B081::2 eq 51720
permit udp any host 2001:470:B081::2 eq 51720
deny ipv6 any any log

Thanks.

Lobo

P.S. I can't even get to this site without either using one of the other browsers or disabling the FW on the 1811 for the ipv6 tunnel.

[pbrutsch]

What's your IOS version? I'm using an 1811 myself and am having no difficulty with IPv6 connectivity.

I'm running version 15.1.3T, ADVANCED IP SERVICES feature set.

The relevant parts of my config:

Code Select Expand

interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 address 2001:470:1F10:447::2/64
ipv6 enable
ipv6 inspect internetv6 in
ipv6 inspect internetv6 out
ipv6 traffic-filter in-from-wan-v6 in
tunnel source FastEthernet0
tunnel mode ipv6ip
tunnel destination 209.51.181.2

ipv6 inspect name internetv6 ftp timeout 300
ipv6 inspect name internetv6 tcp timeout 3600
ipv6 inspect name internetv6 udp timeout 300
ipv6 inspect name internetv6 icmp timeout 300

ipv6 access-list in-from-wan-v6
permit icmp any any nd-na
permit icmp any any nd-ns
permit icmp any any packet-too-big
permit udp any eq ntp any
deny ipv6 any any log-input


[lobotiger]

I'm running 12.4(24)T4 Advanced IP Services.  Was running T3 for most of 2010 and was having the problem with that version when I upgraded to T4 last night but still seeing the same issue.

BTW, I've noticed this issue on different machines running Windows 7 64/32 bit and Ubuntu but again only with Chrome and only when the firewall is enabled.

LoboTiger

[lukec]

LoboT
Do you see anything in the router logs?
Regards
lukec

[lobotiger]

No, I see no logs being generated from the firewall portion or the access-list.  Very odd.

Lobo

[pbrutsch]

I had written a post about avoiding all 12.4T releases newer than 12.4(15)T, but now I see that this is specific to a particular application. Your description indicates that something isn't handling PMTUD the way it should, although you would think it would affect all applications, not just one.

Capturing some packet traces with wireshark might shed some light on the issue. Next time I get a chance I'll load up Chrome and see if I can duplicate your problem.

[lobotiger]

Well, interesting turn of events.  IPv6 traffic is working normally again with Chrome and with the IOS FW enabled on the tunnel.   ???

The old, "I swear I didn't touch a thing" adage is true here.  I didn't make any changes at all and was using Firefox over the weekend instead.  I decided to try Chrome again the sites were coming up blazingly fast and not the trickle like a dialup account.  The speed that the sites load up is equivalent to what I had before.  Could there have been an update to Chrome over the weekend?

Lobo

P.S. Curious to hear about the drawbacks for versions greater than 12.4(15)T.

[antillie]

I am rather interested in the drawbacks for versions prior to 12.4(15)T as well.

I haven't seen any issues with Chrome or Firefox over my tunnel. Although I am running 12.4(25d) instead of a "T" release so that might have something to do with it. I also have an MTU limit set on my router's LAN facing interface in an attempt to prevent MTU issues due to the tunneling overhead:

ipv6 mtu 1480

Since the IPv4 header added by the tunnel is 20 bytes in length I figure that limiting the IPv6 MTU on the LAN facing interface to 1480 will cause my local hosts to fragment their outbound IPv6 traffic right off the bat instead of waiting for an ICMPv6 "packet too big" reply from some far away remote host. That way the resulting IPv4 encapsulated packet will be 1500 bytes and traverse the network to HE's tunnel server without any issues.

I haven't seen any problems yet but there aren't exactly zillions of IPv6 enabled sites out there to test with.

[pbrutsch]

antillie, The reason I'm specific about the IOS version is due to the bugginess and the availability of those bug fixes. IOS 15.0M fixed numerous bugs for me that were introduced after IOS 12.4(15)T and have not been fixed in the 12.4(20)T -> 12.4(24)T maintenance rebuilds. Heck, even 12.4(15)T introduced bugs that haven't been fixed.

Additionally IOS 12.4T releases are generally considered beta quality, or otherwise not production-ready. Your 12.4(25d) release is a MUCH better choice than any 12.4T release, provided you don't desire features that were introduced in the 12.4T releases.

Regarding the MTU issue, you should ALWAYS try to avoid sending internet traffic over any sort of tunnel that doesn't provide fragmentation. It's not just the hosts on your LAN that can be a problem, it's the ones out in the world that don't realize you have a smaller MTU and try to send you 1500-byte packets. PMTUD (path MTU discovery) is generally pretty broken in practice.

In the IPv4 Cisco world you can do TCP MSS adjustment (or TCP MSS clamping, as some operating systems call it), but that feature doesn't seem to have a IPv6 equivalent in Cisco-land.