[Solved] - IPv6 routes only working after edit on freebox

melmoth · May 5, 2020, 10:05pm

Hi !

I've finally updated my 18.06 to the latest 19.07 version. Unfortunately after that, a strange behavior began to occur: IPv6 connectivity was lost, kind of randomly. After some investigations, it happened that after a reboot, the default ipv6 route was not present anymore, a network restart would not event bring it back.

The only hack I've been able to use so far to make it usable is to fake an edit on a static route (eg changing mask back and forth) to be able to save and apply configuration from gui. I guess it has to deal with order of initialization of interfaces but I do not have any more idea to test a fix ..

here is the relevant part of my conf:
network:

type or paste code here
onfig 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 'fd74:XXXX:XXXX::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth1.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.42.1'
	option ip6assign '64'

config interface 'wan'
	option ifname 'eth0.2'
	option proto 'dhcp'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option reqprefix 'auto'
	option reqaddress 'try'
	list ip6prefix '2a01:XXXX:XXXX:XXX1::/64'

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

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

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 6t'

config route6
	option target '::0/0'
	option gateway '2a01:XXX0::1'
	option interface 'wan6'

config route6
	option target '2a01:XXXX:XXXX:XXX1::/64'
	option interface 'lan'

dhcp:

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option ra 'server'
	option ra_default '1'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

Thanks for your enlightened ideas ; )

Fred

mikma · May 6, 2020, 7:10am

Why do you need this route? Doesn't the upstream router provide a default route via RA? Your route might not be added to the routing table since you don't have a route to 2a01:XXX0::1. You may try to add an additional device route similar to the route on the lan with target 2a01:XXX0::1 and interface wan6.

trendy · May 6, 2020, 8:08am

ULA are private addresses, no need to mask them.

Unless your ISP told you to do that, remove this line.

These should not be necessary. Remove them for now.

In dhcp stanza, I don't see anything about ra_management, or dhcpv6.
Post again the configs as well as ifstatus wan; ifstatus wan6; ifstatus lan

melmoth · May 6, 2020, 11:16am

Hello, thanks for you answers.

To add some detail, I'm currently using "Free" as my ISP. Their router handles IP delegation, NextOp is configured accordingly. I've followed those guides to set up the connection (sorry, last link mainly in french but the final explanation is in english)

http://akconcept.epizy.com/website/ipv6?i=1
https://forum.archive.openwrt.org/viewtopic.php?id=53160&p=2

As the "free" router firmware is currently buggy (old version of bridge-utils leading to crashes needing router reboot) the router itself is currently in router mode with the openwrt router in dmz receiving all data stream.

@trendy after configuration update:

config:

	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd74:0ea1:5ef0::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth1.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.42.1'
	option ip6assign '64'

config interface 'wan'
	option ifname 'eth0.2'
	option proto 'dhcp'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option reqprefix 'auto'
	option reqaddress 'try'

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

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

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 6t'

ifstatus:

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 48198,
	"l3_device": "eth0.2",
	"proto": "dhcp",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		{
			"address": "192.168.0.1",
			"mask": 24
		}
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "0.0.0.0",
			"mask": 0,
			"nexthop": "192.168.0.254",
			"source": "192.168.0.1/32"
		}
	],
	"dns-server": [
		"192.168.0.254"
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		"leasetime": 43200
	}
}
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 1785,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "2a01:XXX:XXX:XXX:XXX:XXX:XXX:14f3",
			"mask": 64,
			"preferred": 86047,
			"valid": 86047
		}
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "2a01:XXX:XXX:XXX::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 86047,
			"source": "::/0"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::6aa3:78ff:fe6e:a5ba",
			"metric": 512,
			"valid": 1447,
			"source": "2a01:XXX:XXX:XXX:XXX:XXX:XXX:14f3/64"
		}
	],
	"dns-server": [
		"fd0f:ee:b0::1"
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		
	}
}
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 48200,
	"l3_device": "br-lan",
	"proto": "static",
	"device": "br-lan",
	"updated": [
		"addresses",
		"routes"
	],
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		{
			"address": "192.168.42.1",
			"mask": 24
		}
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		{
			"address": "fd74:ea1:5ef0::",
			"mask": 64,
			"local-address": {
				"address": "fd74:ea1:5ef0::1",
				"mask": 64
			}
		}
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		
	}
}

thx

melmoth · May 6, 2020, 12:32pm

@mikma

I've just tested adding another route, It does not help either, thanks for the idea ; )

trendy · May 6, 2020, 12:35pm

Ok since the router is buggy, you can revert back the ip6prefix.
As for the route6, in the first one use the link local address, rather than the public.
The second route is not necessary, the network is directly connected.
DHCPv6 service can be enabled on OpenWrt. I am not sure why they have it disabled.

melmoth · May 6, 2020, 1:13pm

Ok so:

return of the ipv6 prefix
dhcpv6 back to server mode, (no ndp proxy ?)
removed the second route

But which link local address on the first route ? I m using the "free" router gateway address. I must miss something here.

As for the dhcpv6 disabling can it be related to the "free" router using mainly slaac ?

thx

trendy · May 6, 2020, 1:37pm

nope.

The ll address of the free router on the lan. Should be this one fe80::6aa3:78ff:fe6e:a5ba

No, they are not connected in any way.

melmoth · May 6, 2020, 1:56pm

Great it seems to work properly even after a reboot, thank you @trendy !

but i'd like to understand my mistake (yup ... )

I've not noticed this address so what I understand (and i'm not an ipv6 expert by any mean ... ), as I followed a guide where the "free" router was in bridge mode, I had to use the public router address, but as currently I had to set it to router mode, it uses the fe80::6aa3:78ff:fe6e:a5ba ip on its subnet.
Consequently, this ip should be used internally on the managed network (so only openwrt).

In this case why the openwrt router do not have on the wan6 iface an ip of the same fe80 class ?

Ho maybe incoming and outgoing settings in ipv6 should be considered really 2 different things and having a class of ip only for incoming access from the world to the subnet (the 2a01 class) and a fe80 routing from the inside to outside world ?

trendy · May 6, 2020, 2:49pm

The problem with public addresses (or GUA) is that they might change, so you'd better use something more stable, like a ULA (or private) or a link local. The link local is valid only on the link, every interface has one and it is created automatically. You can see the link local of OpenWrt on all interfaces with ip -6 addr

nope, this is not its purpose. You'll use the GUA for communication to the internet. For internal you can use the ULA or GUA, it's flexible. On the link only you can use the LL.

melmoth · May 6, 2020, 3:01pm

Ok so a better analogy is LUA is rougthly equivalent to the use of small ipv4 range like 192.168... (meaning usually in subnet) and the GUA the usual assigned external ip.

mmm but in this case why my first route referencing a GUA failed ?

trendy · May 6, 2020, 3:09pm

ULA is a private address, same as 10.0.0.0/24 or 192.168.1.0/24. You can have multiple networks with ULA addresses and communicate each other.
GUA is a public address, routable on the internet. In IPv6 you can have public IPs inside your LAN too. There is no need for NAT.
LL are addresses with local validity only, like 169.254.0.0/16. You cannot reach a host in a different broadcast domain using the LL.

Maybe the GUA you were using had changed from the ISP? The trick here is that you can use the LL address for nexthop even if it is meant for GUA addresses.

melmoth · May 6, 2020, 3:33pm

nop no change on the GUA. But yes obviously it's seems more logical to use address of the same class from inside the network.

Is the LL generated by the interface hardware ? (kind of a MAC address ?)

trendy · May 6, 2020, 6:49pm

Yes, more or less.

melmoth · May 6, 2020, 6:58pm

Ok I'll go to bed less stupid tonight

Again thanks for your help, the teaching and of course your time

system · May 16, 2020, 6:58pm

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