diagnosing Airport Extreme problems

[RosettaStone]

I've set up IPv6 on my Airport Extreme.  I am able to resolve domain names to their IPv6 addresses (ipv6.google.com, etc).  However, pinging and browsing time out.

Additionally, the Airport reports that its having an "IPv6 Tunnel Error": "There was an error with teh IPv6 tunnel endpoint."

Further testing (using HE's Looking Glass tools) shows that while my IPv4 address is pingable, my IPv6 address is not.

What's going on here?  Any ideas for how to diagnose this further?

[jimb]

Impossible to say w/o more information, such as IP/IPv6 addresses, whether your airport is behind a NAT device, etc.

[cholzhauer]

Yep, need more info.  Also, check for an IPv6 firewall on the Extreme that could be blocking IPv6 ICMP

[lethe]

My AEBS running firmware 7.5 has held its IPv6 tunnel stable for several months.  Then today I rebooted the router after making some routine config changes, and I got the same message you mention.  "IPv6 Tunnel Error  There was an error with the IPv6 tunnel endpoint.  Wait for the service to be restored and try again. Contact your service provider if the problem persists."

There was nothing about it in the logs on the device about a tunnel error.  My airport is not behind a NAT.

Unlike RosettaStone, I cannot ping my IPv4 address (nor of course IPv6)

[jimb]

All I can say is double check your settings.  Make sure you're using the right IPv6 /64 on your tunnel interface, and the right IPv6 /64 on the LAN interface.  Make sure you're giving HE the correct IPv4 address for your AE's public IP.  Make sure the AE has either a default route pointing towards your upstream gateway, or a host route for the HE tunnel server (either will work).

Check your FW settings to make sure IP proto 41 is allowed through.

It's also possible that your ISP sucks and blocks proto 41, but that's less likely.

[lethe]

Check your FW settings to make sure IP proto 41 is allowed through.

It's also possible that your ISP sucks and blocks proto 41, but that's less likely.

jimb, your reply contained the clue which let me arrive at the answer.  thank you.

So, I changed none of my tunnel settings on my AEBS.  So none of them could be bad.  But I doublecheck them anyway.  And the settings on tunnelbroker.net.  Nothing. 

And of course, I do not run a firewall on any of my hosts.

But your reminder about needing incoming port 41 to be open gave away the answer: the so-called "routine" config change that I made which caused the config to fail was to make one of the hosts on my LAN into the DMZ host.  You probably shouldn't be allowed to call that "routine", I guess?  As Apple labels it: "Enable default host at".  The router has software to build the tunnel, based on incoming requests on port 41.  If you're router is configured to forward all incoming requests to a LAN host, then there's simply no chance of building the tunnel (unless the LAN host is configured, which of course it wasn't in my case).

So thank you, jimb.  It wasn't a firewall that was the issue, but something closely related.  You were close enough to tip me off.

I've turned off the DMZ, and the tunnel works great again.

[jimb]

Cool.

IMHO the DMZ function is fairly useless as well as a security issue.  I prefer to forward individual ports and protocols than wholesale forward all unsolicited traffic to a particular host.

Although with some consumer grade routers, and even big name equipment, there's no other way to do it since they don't allow forwarding of an individual layer 4 protocol.  My solution in those cases is to choose a different router, or use a linux or BSD box to do it.  :P

[lethe]

Cool.

IMHO the DMZ function is fairly useless as well as a security issue.  I prefer to forward individual ports and protocols than wholesale forward all unsolicited traffic to a particular host.

Wait, DMZ is a security issue???

Hang on.  The whole point of IPv6 is to restore the concept of end-to-end connectivity and addressability that we lost when NAT became prevalent when we started running out of IP addresses.  Every host on my LAN is addressable and you can attempt to open a socket on every port on every host on my LAN from anywhere else on the IPv6 internet.

The DMZ just does the same thing for the IPv4 internet, except it can only do it for a single host on my LAN.

The idea that NAT is a security feature is a step in the wrong direction, in my opinion.

[jimb]

Cool.

IMHO the DMZ function is fairly useless as well as a security issue.  I prefer to forward individual ports and protocols than wholesale forward all unsolicited traffic to a particular host.

Wait, DMZ is a security issue???

Hang on.  The whole point of IPv6 is to restore the concept of end-to-end connectivity and addressability that we lost when NAT became prevalent when we started running out of IP addresses.  Every host on my LAN is addressable and you can attempt to open a socket on every port on every host on my LAN from anywhere else on the IPv6 internet.

The DMZ just does the same thing for the IPv4 internet, except it can only do it for a single host on my LAN.

The idea that NAT is a security feature is a step in the wrong direction, in my opinion.

The DMZ function typically bypasses both the NAT "layer" and network firewall security policy.  It opens up a host completely to the internet.  If that host is secure, then no worries really.  But if it's just some box that hasn't been properly secured and hardened, then you're asking for trouble.  Putting a system on the open internet completely unsecured is generally a bad idea whether one is running IPv4 or IPv6.  The DMZ function is the equivalent.

The idea of IPv6 and restoring end-to-end connectivity isn't about putting your machine on the open internet.  It's about getting rid of the problems which NAT causes.  This doesn't mean that one shouldn't have some sort of network firewall in place in front of your clients or servers.  It's really just like returning to the days where one ran publics on internal LANs.  We still had firewalls in front of our LANs and server farms as security policy enforcement points.  I run a network firewall for both my IPv4 and IPv6 LANs, as well as firewalls on my internal machines (defense-in-depth).  The only difference between the two is that for the IPv4 side, I need to have a NAT rule set up with port forwards, outbound NATs, etc.  The IPv6 side has only a security policy (the same policy as the IPv4 side).

What IPv6 will make far easier are apps like Skype (and other VOIP), p2p apps, etc, which require direct connectivity between clients.  Right now many of these apps work by going through a third party, a server on the internet which both can use as a go-between.  And/or by using techniques such as hole-punching.  In an IPv4/NAT world, doing so without this third party requires port forwards and such.  And such port forwards can get complicated when you're doing it for multiple inside machines with a single public IP (typical end user setup).  This is way beyond the knowledge and patience of the average user.  Not to mention the ALG nonsense needed for some protocols because of NAT (SIP/SDP and FTP comes to mind).

In an IPv6 world it will merely require adding a rule to your security policy saying "allow the internet to connect to this port on any host on my LAN (or an individual machine)".  And that's it.  Sure, certain protocols like FTP will still require stateful firewall stuff, but that's been the same since the beginning.

[cholzhauer]

And such port forwards can get complicated when you're doing it for multiple inside machines with a single public IP (typical end user setup).  This is way beyond the knowledge and patience of the average user.

Right.  My firewall config is about seven or eight pages long.  Three or four of those pages are dedicated strictly to NAT translations and configuration; to do the same thing for IPv6 requires half a page.

[jimb]

And such port forwards can get complicated when you're doing it for multiple inside machines with a single public IP (typical end user setup).  This is way beyond the knowledge and patience of the average user.

Right.  My firewall config is about seven or eight pages long.  Three or four of those pages are dedicated strictly to NAT translations and configuration; to do the same thing for IPv6 requires half a page.

Yep.  I've been doing IT and firewall stuff for long enough to remember when it was common to run public IPv4s on one's corporate LAN.  FW configs were waaay simpler in those days.  Need some service?  Open the port to that host and you're done.  

Plus, every host on your LAN could be addressed by the "normal" port on which the service listens.  Today, with the lack of IPv4s, it's considered pretty wasteful to not use a bunch of external ports to map to internal boxes on the same pub IPv4.  So then the users have to know/type in the port number if it was, say, a bunch of web servers.

IPv6 will be a return to that, with every device having its own unique address.  You won't have to "share" a small set of IPv4 publics for 100 different services behind the firewall or on the DMZ (If you're not running publics on the DMZ already.  A real DMZ, not the consumer grade router definition of a DMZ).  

This will probably also cause an increase in home users making use of more servers and services at home, since it will be far less complicated.  I predict that a lot of consumer devices, TVs, DVRs, etc, etc will start to have web interfaces to monitor and control them, etc, since it will be easy for home users to access them from the internet without doing port forwards or running a VPN client or doing some sort of tunneling.

Another huge benefit of going back to using globally unique addresses on the LAN will be the elimination of overlapping RFC-1918 private address space.  This is a real pain when say, two corporations need to establish a site to site VPN between them for some cooperative venture.  Or even more of a pain when one company acquires another.  In those situations I've had to employ confusing/annoying network NAT solutions temporarily, and ultimately renumber one of the company's entire corp network.  IPv6 won't have this problem.

And of course it will also allow IPSEC to work in transport mode on a host to host basis, allowing generic encryption to be used with just about any application or service without the need for per-application implementation of encryption.  Probably with very little set-up by the admin, if any (it'll probably be an OS install-time configuration).

Probably a bunch of other stuff I can't think of right now, but suffice to say, unique addresses == win.  NAT is and always was a kludge to temporarily alleviate IPv4 exhaustion.  :P