Problems getting native IPv6 to work with LUCI

Wow...

  • Hummmm, then it worked, correct?
  • What's your LAN DHCPv6 config? (I assume the "client" is in LAN???)
  • What is the config for forwarding from LAN to WAN?
  • What is Interface PRIO? (is that where the client is!?!?)
    • What is the PRIO to WAN Zone forwarding setting?

OK...be clear:

  • are you referring to the ECHO-REQUEST from the client; or
  • an ECHO-REPLY from WAN
  • where are you monitoring this/how did you determine that?

(I assume the former.)

  • :bulb: Definitely tell is what zone the client's in; and show us the: Local, DHCPv6 and Zone to WAN settings
  • depending on how you monitored, did you get any corresponding ICMP error messages to this traffic :wink:

Client is in Zone PRIO. PRIO->WAN settings above. DHCPv6 for PRIO was in the initial posting.

Not sure what you mean by Local...?!

depending on how you monitored, did you get any corresponding ICMP error messages to this traffic

When the Client sends ICMP Echo Request then OpenWRT replied with Destination Unreachable to the client. This happens on Interface PRIO. Nothing is seen on WAN6 about this transaction.

Disregard, I see the settings. PRIO does not have a static IPv6 address, nor one assigned from WAN6 in its active status...

You need to add in /etc/config/network under PRIO:

option ip6class 'wan6'

I don't need WAN setting above, I need you to screensot PRIO on the General Firewall page, so I can see if you allowed forwarding from PRIO to WAN. Example using "guest":

screen80

You should have one for PRIO.

This exists for PRIO. I also wrote that in my last post:

PRIO is allowed to forward to destination WAN6
PRIO is NOT allowed to foward from source WAN6

The screenshot in the above post was NOT for WAN, it was for PRIO (see covered interfaces: PRIO)

Do you know what setting in LUCI is responsible for setting ... accept_ra to 2 for a given interface?

On OpenWrt we handle RAs in userspace (odhcpd for emitting, odhcp6c for receiving). The Kernel mechanisms (accept_ra & friends) are disabled on purpose.

Could you share the output of ifstatus wan6, ifstatus prio as well as uci export network and uci export dhcp ? You might need to redact IPs.

1 Like

I see. Then why did it start to work when I used sysctl to ser accept_ra to 2?

Because the kernel started processing RAs and adding IPv6 prefixes etc, something which odhcp6c is supposed to do in the normal case. You either experience a bug (less likely) or there's a small configuration flaw somewhere (more likely)

1 Like

OK I am happy you guys are taking care. I really appreciate that.

I'd rather not. It would be a lot to redact. Is there something you are looking out for and I give that particular pieace o check it myself. Or we go closed, but out here its too much detail.

network:

config interface 'wan6'
	option ifname '@wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option auto '0'

config interface 'prio'
	option proto 'static'
	option ifname 'redacted'
	option ipaddr 'redacted'
	option netmask '255.255.255.0'
	option ip6assign '64'

dhcp:

config dhcp 'wan6'
	option interface 'wan6'
	option ignore '1'

ifstatus prio:

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 9141,
	"l3_device": "redacted",
	"proto": "static",
	"device": "same as I3_device",
	"updated": [
		"addresses"
	],
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		{
			"address": "redacted",
			"mask": 24
		}
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		{
			"address": "xxxx:yyyy:zzz:aaaa::",
			"mask": 64,
			"preferred": 2941,
			"valid": 2941,
			"local-address": {
				"address": "<above-address>::1",
				"mask": 64
			}
		},
		{
			"address": "fdaa:dead:babe:a::",
			"mask": 64,
			"local-address": {
				"address": "fdaa:dead:babe:a::1",
				"mask": 64
			}
		}
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		
	}
}

ifstatus wan6:

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 898,
	"l3_device": "redacted",
	"proto": "dhcpv6",
	"device": "same-as-I3_device",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "redacted",
			"mask": 128,
			"preferred": 2702,
			"valid": 2702
		}
	],
	"ipv6-prefix": [
		{
			"address": "redacted::",
			"mask": 56,
			"preferred": 2702,
			"valid": 2702,
			"class": "wan6",
			"assigned": {
				"vlan1": {
					"address": "<redacted address of vlan1 interface>::",
					"mask": 64
				},
				"vlan2": {
					"address": "<address for interface vlan2::",
					"mask": 64
				},
.
.
.
				"vlan-n": {
					"address": "redacted vlan n interface address::",
					"mask": 64
				},
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::redacted",
			"metric": 384,
			"valid": 1616,
			"source": "redacted delegated prefix::/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::redacted-provider-device-address",
			"metric": 384,
			"valid": 1616,
			"source": "redacted/128"
		}
	],
	"dns-server": [
		"redacted",
		"redacted"
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		"passthru": "001700202a022457030c010100000000000000112a022457030c01010000000000000012"
	}
}

Short of increasing ip6assign to something larger (try e.g. 60) I don't have any specific ideas on what might be wrong in your case.

You said clients receive ULAs as well as GUAs from your delegated space, so that part appears to work fine.

What kind of Operating system is running on the client? Also how did you determine that ICMPv6 echos are not forwarded? Through tcpdump?

1 Like

Well you can't assign it statically since your ISP changes it...

I know of no way to configure option ip6class via LuCI.

  • Step 1 -The command to enter the editor is: vi /etc/config/network
  • Step 2 - move down to PRIO interface
  • Step 3 - hit INSERT to edit and enter on the last line to insert
  • Step 4 - add option ip6class 'wan6' line
  • Step 5 - hit ESC to stop editing
  • Step 6 :wq to save and quit
  • Step 7 - /etc/init.d/network reload
    • or just go back to LuCI and (Stop/Start) the interface

(The Kernel is smart enough to know it doesn't have a corresponding [Public] IP on that interface...yet :wink:)

wrote it in detail further up. short: tcpdump on interfaces wan6 and prio.

/64 is OK and normal for a LAN, unless I'm missing something....?

Thanks for the details on VI editing. This is not a problem for me.
Look at the ipstatus output. class is already wan6. so would I need to set it anyway?

Was the source address correct in the ICMPv6 echo requests you captured or was OS X trying to send packets using an ULA IP as source address?

1 Like

macOS uses the public temp address, should be correct

its even weirder now:

16 bytes from 2a00:1450:4016:806::200e, icmp_seq=0 hlim=118 time=16.595 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=1 hlim=118 time=17.643 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=2 hlim=118 time=15.781 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=3 hlim=118 time=18.801 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=12 hlim=118 time=1704.060 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=13 hlim=118 time=701.133 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=14 hlim=118 time=16.303 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=15 hlim=118 time=16.116 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=16 hlim=118 time=154.538 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=17 hlim=118 time=92.502 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=18 hlim=118 time=139.088 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=19 hlim=118 time=17.193 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=20 hlim=118 time=19.156 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=21 hlim=118 time=19.894 ms
^C
--- google.com ping6 statistics ---
25 packets transmitted, 14 packets received, 44.0% packet loss
round-trip min/avg/max/std-dev = 15.781/210.629/1704.060/449.513 ms

Then I tried again:

--- google.com ping6 statistics ---
58 packets transmitted, 0 packets received, 100.0% packet loss

SO sometimes the forwarding works, sometimes it does not.

More:

16 bytes from 2a00:1450:4016:806::200e, icmp_seq=132 hlim=118 time=1434.988 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=133 hlim=118 time=431.995 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=135 hlim=118 time=72.817 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=136 hlim=118 time=69.173 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=137 hlim=118 time=75.593 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=138 hlim=118 time=80.792 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=139 hlim=118 time=70.163 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=140 hlim=118 time=254.585 ms
^C
--- google.com ping6 statistics ---
156 packets transmitted, 8 packets received, 94.9% packet loss
round-trip min/avg/max/std-dev = 69.173/311.263/1434.988/441.984 ms

Maybe it helps to understand what happens:

ip -6 route:

...
default from <public-wan-interface-address> via fe80::<provider-device-address> dev <wan(6)> proto static metric 384 pref medium
default from <delegated prefix>::/56 via fe80::<provider-device-address> dev <wan(6)> proto static metric 384 pref medium
...

ip -6 neigh:

...
fe80::redacted-provider-device dev <wan(6)>  router INCOMPLETE
...

I found the culprit, it was well hidden in LUCI:

You need to enable both, correct?

The usual test pages run positive for me now, but here I am less successful:

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.