"dumb" OpenWrt Wireless Access Point w/ IPv6 need help

Installing and Using OpenWrt Network and Wireless Configuration
1

I have a few 'dumb' Wireless APs around the office. They are set up to provide wireless access to main LAN, guest wifi, and several of them have access to additional VLAN in that area.

All that works fine in IPv4. However, I noticed that it doesn't past IPv6 addresses that are connected to these wireless APs. Not to the main LAN, not to the guest network, not to the additional VLANs.

Everything that is wired works perfectly. I have a Global /48 from HE. I just can't seem to figure out why the OpenWRT wireless APs won't "passthrough" the IPv6 address to the wireless clients.

What I do notice is that wireless clients that are connected to the OpenWRT APs CAN ping local-link IPv6 address. But none of the clients can ping6/ping -6 to google.com (or anything beyond the WAN router)

Any advice would be greatly appreciated.

2

are the clients getting global addresses but can't use them, or they don't even get global addresses. also can you clarify do your wired clients connected to these APs work fine?

3

My bad, I don't have any wired clients connected to the OpenWRT APs. They are strictly Wireless APs

All these OpenWRT APs is single wired via CAT6 back to the closet. Each AP is VLAN tagged and trunked.

Doing a ipconfig /release6 and ipconfig /renew6 seem to give the IPv6.

I SSH into one of the OpenWRT APs and did a ping6 google.com and I get this

root@owrt-n750:~# ping6 google.com
PING google.com (2607:f8b0:4007:801::200e): 56 data bytes
ping6: sendto: Permission denied
4

did you set up the openwrt lan as ipv6 client? did it get a global ipv6 address?

5 
root@owrt-n750:~# ifconfig
br-Guest  Link encap:Ethernet  HWaddr 00:90:A9:11:6A:C6
          inet6 addr: fe80::290:a9ff:fe11:6ac6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:136 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:28650 (27.9 KiB)  TX bytes:738 (738.0 B)

br-lan    Link encap:Ethernet  HWaddr 00:90:A9:11:6A:C6
          inet addr:192.168.1.21  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::290:a9ff:fe11:6ac6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4678 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1961 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:532989 (520.4 KiB)  TX bytes:483978 (472.6 KiB)

as you can see I don't get any global addresses on this particular OpenWRT AP.

How do I configure the AP as a client?

I see these entries for my LAN interface

IPv6 assignment length

IPv6 assignment hint

IPv6 suffix

But I don't see anywhere else

I honestly just thought the RA would take care of all the assignments

6

I think the APs don't listen to RA by default. create a lan6 interface and set it up as protocol dhcpv6 client similar to want interface that comes out of the box.

or what I do is use static ipv6 assignments

1 Like
7

That is so weird because at home I have a wireless AP (AsusWRT/Merlin) and clients connected to it just automatically get IPv6 and get routed

8

yes it's normal that the clients do, but the AP itself might not, there are good reasons why an infrastructure device might not listen to RA, including DoS/security reasons.

2 Likes
9

if you agree that the clients do... shouldn't this be the same scenario? I don't really care if the AP itself gets a global ipv6 address. I only care that the wireless clients connected to the AP gets it and get routed.

10

yes clients should have working ipv6 if the AP is wired to a network that has RAs and a dhcpv6 server

my impression was your clients were working based on this

11

If the wireless is bridged to the Ethernet, there is no functional reason for the AP to have any address at all, IPv6 or IPv4. It's just passing packets, not sourcing or sinking them.

Yes an IP address of some sort is convenient for management, but not needed for function.

Edit:

If I were debugging this, I'd first confirm that the bridges were set up properly as that should be all that is needed, assuming that the upstream router is properly sending them. If the bridges looked OK, I'd then install tcpdump-mini and look for the RA packets.

1 Like
12

Can you post the contents for the config files?
cat /etc/config/network ; cat /etc/config/firewall

13 
root@owrt-n750:~# cat /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fe80::/16'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option gateway '192.168.1.1'
        option dns '192.168.1.98'
        option ifname 'eth0.1 eth1'
        option ipaddr '192.168.1.21'
        option ip6assign '64'
        option delegate '0'
        option ip6ifaceid 'eui64'

config device 'wan_dev'
        option name 'eth0.2'
        option macaddr '00:90:a9:11:6a:c5'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '0t 1'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option vid '3'
        option ports '0t 1t'

config interface 'Guest'
        option type 'bridge'
        option proto 'none'
        option ifname 'eth0.3'
        option auto '1'
        option delegate '0'
        option stp '1'

root@owrt-n750:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config include
        option path '/etc/firewall.user'

config zone
        option input 'ACCEPT'
        option output 'ACCEPT'
        option name 'LAN'
        option forward 'DROP'
        option network 'lan'

config zone
        option input 'ACCEPT'
        option output 'ACCEPT'
        option name 'Guest'
        option network 'Guest'
        option forward 'DROP'

root@owrt-n750:~# cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.

# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.


iptables -I FORWARD -i br-lan -o br-Guest -j DROP
iptables -I FORWARD -i br-Guest -o br-lan -j DROP

As I mentioned before. IPv4 is routing properly. This AP is the simplest of them all, just the main LAN and a guest LAN.

14

All the APs needs to be managed since I have trunked VLANs. With multiple VAPs

15

Since you're comfortable with VLANs, you can put an IP on a management VLAN and don't need one on any other interface (unless you need connectivity off that VLAN).

16

So I went back to the WIKI and saw this part

IPv6

If you would like your AP to receive IPv6 as a host only and not for routing you have to tell dhcp6c not to request prefix deligation. If you do not do this the AP will reject basic IPv6 addresses. If you want to still be able to use ipv6 on the Router itself change the wan6 to lan6 and @wan to @lan

config interface 'lan6'
option proto 'dhcpv6'
option ifname '@lan'
option reqprefix no

Trying to make sense of that.

If you would like your AP to receive IPv6 as a host only and not for routing you have to tell dhcp6c not to request prefix deligation

So I shouldn't need to do this right? I don't care if the AP to have an IPv6 address, just routing IPv6. Or I am not understanding that sentence correctly....

17 
uci -q delete network.lan.ip6assign
uci -q delete network.lan.ip6ifaceid
uci -q delete network.lan.delegate
uci set network.lan6="interface"
uci set network.lan6.proto="dhcpv6"
uci set network.lan6.ifname="@lan"
uci set network.lan6.reqprefix="no"
uci commit network
service network restart
ifstatus lan
ifstatus lan6
18

Was searching for exactly the same issue today and stumbled on this fresh topic. I tried the suggestion of vgaetera but it does not seem to have any effect. The dumb AP does not get an ipv6 ip either.
I did notice that wired users on the dumb AP get an IPv6 address, but no gateway information. Wireless users on the dumb AP get neither IPv6 nor gateway information.
Edit: It seems most likely to me that the problem is upstream and not at the AP. Will check the RA tomorrow.

19

This is redundant, if you don't specifically allow forwarding between zones they are denied by default.

Other than that, you have static protocol on lan interface, so you have to either assign the IPv6 manually or create a DHCPv6 interface as @vgaetera suggested.

I don't think it is connected, but you can also try to 'ACCEPT' the forward in lan and Guest firewall zones.

If it still doesn't work you need to run tcpdump and check if the RAs are getting to the AP correctly.

1 Like