{"id":17683,"date":"2013-12-22T00:23:33","date_gmt":"2013-12-22T05:23:33","guid":{"rendered":"https:\/\/nuxx.net\/blog\/?p=17683"},"modified":"2013-12-22T14:07:10","modified_gmt":"2013-12-22T19:07:10","slug":"apple-airport-extreme-7-6-4-bridged-but-not-really","status":"publish","type":"post","link":"https:\/\/nuxx.net\/blog\/2013\/12\/22\/apple-airport-extreme-7-6-4-bridged-but-not-really\/","title":{"rendered":"Apple AirPort Extreme 7.6.4: Bridged, but Not Really"},"content":{"rendered":"

\"\"<\/a><\/p>\n

I like having an IPv6<\/a> connection at home, but after running into some weirdness with pfSense 2.1-RELEASE<\/a>\u00a0that seems correlated with having the pfSense box as the GIF endpoint \/ IPv6 router (things would kinda get slow, then eventually sort-of fail) I started looking for other options. I have an Apple AirPort Extreme<\/a>\u00a0running in bridged mode which I use to provide wireless access to the LAN, and it has the ability to tunnel out to an IPv6 network, so I decided to set that up\u2020.<\/p>\n

However, in the midst of getting this setup I ran into a very frustrating problem: only wireless clients connecting via the AirPort could use IPv6; wired clients wouldn’t work. The problem was my previous observation (and expectation), that turning the AirPort into a bridge would make all ports on the back of the device equal. It does not, and thus I needed to move the wired network connection from the WAN Internet port<\/em> to one of the three Ethernet<\/em> ports to have IPv6 work on the wired side.<\/p>\n

Contrary to what it says, turning\u00a0Router Mode<\/em> to\u00a0Off (Bridge Mode)<\/em> doesn’t actually fully bridge; the WAN Internet<\/em>\u00a0port remains different from the internal ports. Specifically, the AirPort won’t service Neighbor Discovery Protocol<\/a>\u00a0(NDP) requests on the WAN Internet<\/em> port when in bridged mode. Thus when I had the switch connected to this port wired clients couldn’t get an IPv6 address, couldn’t find the router, and wouldn’t configure IPv6 stack. I suspect that when Apple addressed\u00a0CVE-2008-2476<\/a>\u00a0via 7.4.1<\/a>\u00a0they did so by wholly blocking NDP on the WAN Internet<\/em> port and didn’t take Bridge Mode<\/em> into account.<\/p>\n

For reference, here’s the ipconfig output from a Windows 7 client on wired vs. wireless when the wired side was connected to the WAN Internet<\/em> port:<\/p>\n

Ethernet adapter Local Area Connection:<\/span><\/p>\n

\u00a0 \u00a0Connection-specific DNS Suffix \u00a0. : home.nuxx.net<\/span>
\n\u00a0 \u00a0Link-local IPv6 Address . . . . . : fe80::3d96:1dd5:728c:fde3%12<\/span>
\n\u00a0 \u00a0IPv4 Address. . . . . . . . . . . : 192.168.0.162<\/span>
\n\u00a0 \u00a0Subnet Mask . . . . . . . . . . . : 255.255.255.0<\/span>
\n\u00a0 \u00a0Default Gateway . . . . . . . . . : 192.168.0.1<\/span><\/p>\n

Wireless LAN adapter Wireless Network Connection:<\/span><\/p>\n

\u00a0 \u00a0Connection-specific DNS Suffix \u00a0. : home.nuxx.net<\/span>
\n\u00a0 \u00a0IPv6 Address. . . . . . . . . . . : 2001:470:1f11:d43:ddca:22b9:af55:639e<\/span>
\n\u00a0 \u00a0Temporary IPv6 Address. . . . . . : 2001:470:1f11:d43:e82f:53dc:7af4:940b<\/span>
\n\u00a0 \u00a0Link-local IPv6 Address . . . . . : fe80::ddca:22b9:af55:639e%13<\/span>
\n\u00a0 \u00a0IPv4 Address. . . . . . . . . . . : 192.168.0.147<\/span>
\n\u00a0 \u00a0Subnet Mask . . . . . . . . . . . : 255.255.255.0<\/span>
\n\u00a0 \u00a0Default Gateway . . . . . . . . . : fe80::216:cbff:fec5:162f%13<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0192.168.0.1<\/span><\/p>\n

This can be seen in these two network captures: airport_bridged_lie_wired.pcap<\/a> and airport_bridged_lie_wireless.pcap<\/a>. These were recorded on OS X using tcpdump<\/a> when the respective interfaces were down (either unplugged or with the internal wireless disabled), then brought up, then the capture stopped. Captures were then filtered with\u00a0icmpv6.type == 133 || icmpv6.type == 134<\/span> to show only Router Solicitations (133) and Router Advertisement (134) then exported to these libpcap-format<\/a> files.<\/span><\/p>\n

In these captures one can clearly see that the wired connection (c4:2c:03:2e:5d:cf) makes some Router Solicitation requests but doesn’t receive a reply, while the wireless connection (d8:30:62:64:f4:ff) receives a Router Advertisement reply to its Solicitation.<\/span><\/p>\n

After digging into all of this and initially declaring the problem to be wholly with the wired side I thought maybe there’d be a differentiation between the WAN Internet<\/em> and\u00a0Ethernet<\/em> ports. I then tried moving the wired connection to one of the internal \/\u00a0Ethernet<\/em> ports I was able to get IPv6 NDP responses to wired clients. Thus, Bridge Mode<\/em> on the AirPort Extreme isn’t quite as bridged as the selection would imply: the bridge is a lie.<\/p>\n

A bug (15716120)\u00a0has been submitted to Apple on this issue.<\/p>\n

—<\/span><\/p>\n

\u2020 With an AirPort Extreme serving as an IPv6 tunnel endpoint behind a pfSense NAT device two settings need to be changed in pfSense to get it working. First,\u00a0<\/span>System<\/em> \u2192\u00a0<\/span>Advanced<\/em>\u00a0\u2192\u00a0<\/span>Networking<\/em> and check\u00a0<\/span>Enable IPv4 NAT encapsulation of IPv6 packets<\/em> and set the IPv6 router’s IP address. This is needed because it’s not possible to add a NAT forward for <\/span>IP protocol 41<\/a>. Second, add an inbound firewall rule allowing <\/span>TCP\/IP Version IPv4<\/em> and\u00a0<\/span>Protocol IPV6<\/em>. This will allow the tunnel on the AirPort to work.<\/span><\/p>\n

The IPv6 tunnel is then configured as per the tunnel provider’s directions, which is well-documented elsewhere.<\/p>\n

I don’t like opening up all the IPv6 wireless clients on my network to direct connections from the outside, and Apple seems to have figured that others don’t want this as well. By going into the AirPort Extreme configuration in AirPort Utility<\/em>, selecting\u00a0Network<\/em> then\u00a0Network Options…<\/em> and checking\u00a0Block incoming IPv6 connections<\/em>, all inbound IPv6 connections are blocked and a\u00a0Port Settings<\/em> option becomes available allowing individual ports to be unblocked.<\/p>\n","protected":false},"excerpt":{"rendered":"

I like having an IPv6 connection at home, but after running into some weirdness with pfSense 2.1-RELEASE\u00a0that seems correlated with having the pfSense box as…<\/p>\n

Continue readingApple AirPort Extreme 7.6.4: Bridged, but Not Really<\/span><\/a><\/div>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-17683","post","type-post","status-publish","format-standard","hentry","category-computers","entry"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts\/17683","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/comments?post=17683"}],"version-history":[{"count":12,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts\/17683\/revisions"}],"predecessor-version":[{"id":17695,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts\/17683\/revisions\/17695"}],"wp:attachment":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/media?parent=17683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/categories?post=17683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/tags?post=17683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}