odhcpd
odhcpd copied to clipboard
openwrt
advertise ipv6 routes from OpenVPN
I have a 19.07.0 OpenWRT router, in which thewan interface does not have any IPv6 connectivity and so it makes no advertisement of any prefixes or routes to the lan hosts. Good so far.
But then an OpenVPN interface comes up and with it, tun0 is plumbed with a /64 IPv6 prefix, and OpenVPN also adds IPv6 routes for prefixes available on the other side of the OpenVPN tunnel to the OpenWRT router's routing table. This is all good, and fine and dandy for the OpenWRT router. It can now access the IPv6 networks on the other side of the OpenVPN tunnel.
The lan side of the OpenWRT router however knows nothing of any of this. This seems wrong. At minimum, hosts on br-lan should at least know of the IPv6 networks it can reach through the OpenWRT router and it's OpenVPN connection to the remote.
Shouldn't odhcpd be advertising these routes in it's RAs somehow?
Even forcing odhcpd to just advertise a default route in it's RAs and then let ICMP6 No route to host (113) tell the lan clients when other IPv6 hosts are not reachable would be better than it is currently.
Perhaps #74 is even a short-term workaround, but given that it's not implemented either, implementing automatic route advertisement for upstream routes would probably be the most effective use of time.
Thoughts?
The current problem with OpenVPN is the lack of proper integration in the OpenWrt network ecosystem; if OpenVPN would be integrated as a proto handler in netifd the IPv6 prefix would be picked up by odhcpd and advertised in RAs as every other protocol providing IPv6 connectivity. There have been several attempts to integrate OpenVPN (latest attempt https://github.com/openwrt/openwrt/pull/2186) as a protocol handler in netifd but no patch has yet been accepted
I have a similar problem (on 22.03 with a wireguard tunnel).
The problem is not missing integration, but that the RAs sent out on lan only handles routes for addresses that lan has an address in (plus some handling for the default route).
Actually it would need to iterate over all routes available on the router, filter out all interfaces that lan traffic isn't forwarded to and announce these on lan.
Fixing that would also somewhat lessen the pain that https://github.com/openwrt/odhcpd/issues/74 creates. I think the right thing would be to get the routes via ubus (instead of reading the routes from /sys) and advertise accordingly.