Can't access http://ipv6.tunnelbroker.net/

[qrs]

Hi.
I've set up ipv6 tunnel on my cisco router.
Everything works fine, except of access to http://ipv6.tunnelbroker.net/ & http://ipv6.he.net

Even Ping works fine.
Answer from 2001:470:0:63::2: time=220мс
Answer from 2001:470:0:63::2: time=220мс
Answer from 2001:470:0:63::2: time=220мс
Answer from 2001:470:0:63::2: time=220мс

I'm using Windows 7. Lan adapter is configured with only IPv6. I can access google.com and other IPv6 web-sites, but not he.net
When I'm trying to access he.net connection is established, request is sent (I checked) but no response is returned...

What is wrong???

PS: I can't access www.ripe.net over ipv6... but http://ripe.net redirect me to www.ripe.net... so may be the problem in tunnel mtu?! But how to check this on ipv6?

[ratcheer]

I had the exact same thing on my Win7 host. Everything appeared to be configured correctly in the network setup and I could ping IPv6 sites, but could not surf to them. Then, I rebooted the PC, and it worked.

Tim

[cholzhauer]

I think you're right in the fact that it might be an MTU issue..what do you currently have it set to?  If you look around the message boards on here, you should be able to find a bunch of posts that talk about it

[SomeJoe7777]

- Which Cisco router are you using?
- What IOS version are you running?
- Please post your configuration from the Cisco.

I have a Cisco 2811 running IOS 15.0.1M4 with an HE tunnel endpoint, and I can access ipv6.tunnelbroker.net with no issues from Windows 7 machines.

[UltraZero]

Hi. Can you connect to Hurricane E by going to
ipv6.he.net and not he.net??

[qrs]

I'm using Cisco 1811, Cisco IOS Software, C181X Software (C181X-ADVIPSERVICESK9-M), Version 12.4(15)T9, RELEASE SOFTWARE (fc5)

Internet connection is PPPoE, so int's dialer ip mtu is 1492.
config is:

interface Tunnel99
description Hurricane Electric IPv6 Tunnel Broker
bandwidth 5120
no ip address
ipv6 address 2001:470:.../64
ipv6 enable
ipv6 mtu 1472
tunnel source myPublic_IPv4
tunnel destination 216.66.80.26
tunnel mode ipv6ip
end

I tryed with and without "ipv6 mtu" string, but no difference. On the forum I havn't found any solved mtu problem :( ... could you please give me a hint?

[qrs]

The only idea I've found out is to set mtu on the inside (routed interface):

int vlan200
ipv6 mtu 1472

so this wotks for me, but as far as I know "MTU-discovery process", this solution is not the best, because this means that mtu discovery doesn't work properly!?!

[SomeJoe7777]

I have not adjusted any MTU settings anywhere.  MTU shouldn't matter as much with IPv6 since routers no longer fragment.  I think your issue is something else, perhaps routing.

When you post, please do not obscure the IPv4 and IPv6 addresses, they are critical to ensure your tunnel is set up correctly.  Simply ensure that any passwords or other security options are removed.

Here are some excerpts from my configuration:

Code Select Expand


Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 15.0(1)M4, RELEASE SOFTWARE (fc1)
!
ipv6 unicast-routing
ipv6 cef
ipv6 inspect name fromLAN_ipv6 tcp
ipv6 inspect name fromLAN_ipv6 udp
ipv6 inspect name fromLAN_ipv6 ftp
ipv6 inspect name fromINet_ipv6 tcp
ipv6 inspect name fromINet_ipv6 udp
ipv6 inspect name fromINet_ipv6 ftp
!
interface Tunnel1001
description IPv6 Tunnel (Hurricane Electric)
bandwidth 3000
no ip address
ip virtual-reassembly max-reassemblies 64
ipv6 address 2001:470:1F0E:8C9::2/64
ipv6 enable
ipv6 inspect fromINet_ipv6 in
ipv6 traffic-filter internet_inbound_ipv6 in
ipv6 virtual-reassembly
tunnel source FastEthernet0/0.3
tunnel mode ipv6ip
tunnel destination 216.218.224.42
!
!
interface FastEthernet0/0.1
description VLAN 1 (Internal LAN)
encapsulation dot1Q 1 native
ip address 192.168.160.1 255.255.255.0
ip access-group internet_outbound in
no ip redirects
no ip proxy-arp
ip nat inside
ip inspect fromLAN_ipv4 in
ip virtual-reassembly max-reassemblies 64
ip ospf 1 area 0
ipv6 address 2001:470:1F0F:8C9::1/64
ipv6 enable
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
ipv6 inspect fromLAN_ipv6 in
ipv6 ospf 101 area 0
ipv6 virtual-reassembly
arp timeout 600
!
interface FastEthernet0/0.3
description VLAN 3 (ISP)
encapsulation dot1Q 3
ip address dhcp
ip access-group internet_inbound in
no ip redirects
no ip proxy-arp
ip nat outside
ip inspect fromINet_ipv4 in
ip virtual-reassembly max-reassemblies 64
no cdp enable
!
ip nat inside source list nat_eligible interface FastEthernet0/0.3 overload
!
ipv6 route ::/0 Tunnel1001
!
ipv6 access-list internet_inbound_ipv6
remark Permit IPv6 Link-Local & Multicast
permit ipv6 FE00::/7 any
remark Block IPv6 Bogons
deny ipv6 ::/3 any
deny ipv6 4000::/2 any
deny ipv6 8000::/1 any
remark Block own assigned IPv6 space
deny ipv6 2001:470:1F0F:8C9::/64 any
remark Block anything going to Windows RPC
deny tcp any any eq 135
remark Block certain IPv6 ranges and hosts for various reasons
remark Infected with a virus
remark Spammers
remark Hackers
remark Allow all ICMP traffic
permit icmp any any
remark Allow services to internal servers
permit tcp any host 2001:470:1F0F:8C9::14 eq www
permit tcp any host 2001:470:1F0F:8C9::14 eq 443
!
ipv6 access-list internet_outbound_ipv6
remark Prohibit any contact with Windows RPC-NetBIOS
deny tcp any any eq 135
deny tcp any any eq 137
deny tcp any any eq 138
deny tcp any any eq 139
deny udp any any eq 135
deny udp any any eq netbios-ns
deny udp any any eq netbios-dgm
deny udp any any eq netbios-ss
remark Allow traffic from own assigned IP space
permit ipv6 2001:470:1F0F:8C9::/64 any
!


[cholzhauer]

MTU shouldn't matter as much with IPv6 since routers no longer fragment.

MTU matters

[SomeJoe7777]

MTU matters

That's a rather vague statement.  Care to back it up with facts or at least examples?

I've shown a perfectly working configuration that has no issues with MTU.

If he is using PPPoE with an MTU of 1492 vs. using the standard 1500 on Ethernet, then there is the potential for IP fragmentation in IPv4.  In IPv6, there is no fragmentation done by routers.  The router will send the transmitting station an ICMPv6 packet-too-big response, and then the host is responsible for either fragmenting the IPv6 packet itself or notifying the upper layer protocols (i.e. TCP) of the smaller permissible datagram size.  The result will be smaller packets that fit (via PMTUD), or the packets will go ahead and be fragmented, which may be inefficient, but will still function properly.

My Cisco config operates identically even though I have no PPPoE.  The 6in4 tunnel adds 20 bytes of overhead to the packets, so my IPv6 MTU is less than 1500 bytes as well.  I can reach these sites with no problem.

I feel his issue has more to do with potential bugs in the implementation of the Cisco IOS 12.4.15T release or possible other config issues that he has not posted.  If he were truly having MTU problems, the issue would be more broad than just affecting ipv6.he.net.

[UltraZero]

This is a document from Cisco. I know it has to deal with PPPoe but, I think it still makes since.

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a0080093bc7.shtml

I'm not really up on this, but in general it does make since.  I did one time try playing with the MTU size and really killed the performance of my network, so, I left it at stock 1500.  I have had some websites not fully draw the site and when I lowered the number below 1475, it started to get really slow.  I went as low as 1400 just to see what would happen and my net connection crawled.

I didn't see this article reference specifically IPv4 or IPv6 so I don't know.  I would trust if someone has done their homework and has used this, that the 2 internet protocols might be different.

Maybe playing with this might be in order.

[SomeJoe7777]

The issue described in the article occurs as a direct result of a web server that is behind a firewall that blocks ICMP.  This is somewhat common under IPv4 even though it directly causes issues such as this.  Under IPv4, blocking ICMP can be worked around, as the article shows.

Blocking ICMP under IPv6 can basically break everything when MTU issues occur since IPv6 relies on ICMP to handle MTU issues.  Any IPv6 web site either needs to allow ICMP so that MTU issues don't impact the host-based fragmentation that will occur, or the web site needs to be permanently configured to always send the minimum guaranteed IPv6 packet size of 1280 bytes.

Since the sites that the OP is attempting to bring up are IPv6, and we can assume HE is not blocking ICMP for IPv6, this shouldn't be an IPv6 MTU issue.

It is possible that there might be an IPv4 MTU issue, which would block some packets at the tunnel level, but that should also end up blocking the IPv4 versions of the web site also, which is not happening.

At any rate, determining if the issue is indeed MTU-based is relatively easy.  Simply use Dr. TCP as suggested in the article to change the MTU size on the PC to 1492, reboot and see if the web sites come up.