TO as lan dhcp client with ipv4 & stateful ipv6?

Trying to configure the TO as lan dhcp client to an upstream router (another TO) but fail to comprehend how to have both, ipv4 and ipv6, on the lan client.

Starting there is no iface option to have dhcp ipv4 and ipv6 on the same lan iface. The protocol that can be chosen is either DHCP client, which covers ipv4 only, or DHCPv6 client which then only covers ipv6.

Is there something I am missing that would enable dhcp ivp4 and ipv6 on the same lan face as opposed to the cumbersome 2 iface way?

If not then there would be indeed 2 lan ifaces, one for each protocol type. Say ipv4 would enslave eth0 and eth2 in a bridge what is left for ipv6 to connect with?

Surely it cannot be rocket science for a simple TO as lan client setup?

While I can not help you with your main request, please keep in mind that for the secondary TO to be able to hand out IPv6 addresses to connected clients, you will need either delegate prefixes from the primary TO. should be a decent starting point, if PD does not work you might need to use dhcp6/ra/ndp relaying see the section titled " Router Advertisement & DHCPv6" in the linked page.

That is no issue in general. And for this use case not applicable.

DHCP can be worked around with static ip but that requires setting the respective gateways manually and the the upstream dns server address

But working around (static does not require 2 ifaces) was not the point of this thread nor delegation but rather how to get ipv4/ipv6 dhcp on the lan client.

So you fail to automatically get an IPv6 address on the secondary TO?
Why are you using br-lan as the interface to uplink to the primary TO?

I believe that OpenWrt uses wan and wan6 automatically by default, so it seems the dual interface method is the “official” way.

But I guess, I really do not undersatand your exact problem and lack the knowledge to actually help you even if I undestood the issue, so I apologize for wasting electrons…

exchange is always good.

wan is likely a bit different than lan since the ISP commonly do not provide both ipv4 and ipv6 via DHCP but rather deploy some mechanism of packet encapsulation (ipv4 in ipv6 or vv) or stateless transition/mapping.
I do not see that the upstream TO can provide such mechanism to the downstream TO.

That might be an oddity particular to their netifd network manager. Haven’t looked into their recent developments and probably will see when TOS4.x based on then the next upstream branch (19.x) gets released and whether it might change then.

In common Linux distros it does not require 2 ifaces to facilitate ipv4/ipv6 connectivity simultaneously. And the curious thing is that static ip is happy just with a single iface.

Yeah, so I would use the secondary TO’s wan port to connect to one of the primary TO’s LAN ports, that way things should work out of the box in so far that the secondary TO should get both an IPv4 and an IPv6 address (at least that works with openwrt since a few years, nit sure though whether current turris os shows the same behavior). Well some years earlier I needed to proxy NDP IIRC to get IPv6 working on clients connected to a secondary router (but the primary was a rather in-configurable speedport-branded router from my ISP, not something as open as you are aiming at here).

I believe “design choice” is a better description :wink:

I guess this is not so much that OpenWrt can not deal with multiple IP addresses on a single interface but more of a logical way to reduce complexity of configuration or so. Or just a way to keep us users on our toes :wink:

Having to configure 2 ifaces instead of one adds complexity from my perspective.

Anyway it does not matter after having just now discovered

Firewall3 currently does not support config redirect for IPv6.

It does not look like it does judging by


My Omnia is DHCP client both for IPv4 and IPv6 (Orange France ISP)
I have two interfaces ‘wan’ and ‘wan6’ on physical ‘eth1.832’ i.e. WAN connector on VLAN 832

config interface 'wan'
    option ifname 'eth1.832'
    option proto 'dhcp'

config interface 'wan6'
    option ifname 'eth1.832'
    option proto 'dhcpv6'

So I tried:

the Omnia is connected as a secondary router to a relative recent OpenWrt aster build. In the Foris GUI under wan I set “IPv4 protocol” to DHCP and “IPv6 protocol” to DHCPv6, and the Omnia passes all tests:

Test type Status
IPv4 connectivity OK
IPv4 gateway connectivity OK
IPv6 connectivity OK
IPv6 gateway connectivity OK

On a client connected to the Omnia via WLAN I also get both working IPv4 and IPv6. What I have not tested is whether using the omnia as primary and the OpenWrt as secondary router…

So I am beginning to thin that the problem might not be the secondary Omnia being

Connecting the TO via WAN port to upstream or LAN?

I connect the Omnia’s WAN port to one of the wndr3700v2’s LAN ports. I did not disable the Omnia’s firewall, but the IPv6 addresses where from a /62 delegaton out of the /56 my ISP gave to my primary router. So in the limited testing the omnia was masquerading IPv4. Maybe not exactly the situation you want tested.

I do not want to bother your time. If you may however connect to one of the Omnia LAN ports instead and see whether it gets both ipv4 and ipv6?

Instead of WLAN I connected my laptop to one of the LAN ports of the omnia and still get both IPv4 and IPv6 addresses and connectivity.

Connecting the Omnia via one of its LAN ports to the wndr does not see like a good idea in my setup (unless I make sure that the omnia’s dhcp server is either completely disabled of does avoid the one switch port used for the uplink).

Having the same scenario. My Turris MOX shall be a host computer behind another router (some call this mode ‘IP client’ or ‘bridge’) to play just Ethernet switch, Wi-Fi access point, and/or a NAS. Especially the latter two scenarios should not be uncommon.

Consequently, I have no WAN in Foris → Network interfaces. The section Foris → WAN should do nothing. Instead, Foris gives me LAN → Mode: Computer → IPv4: Automatic Configuration. That is just about IPv4. However, my Turris MOX does enable IPv6 on that very same LAN interface. I see that via SSH and ifconfig. Nevertheless, it is only a link-local address. Even worse, my Turris MOX advertises itself as IPv6 router and DNSv6 provider; Turris OS is still in router mode when it comes to IPv6.

I digged deeper into that thanks to Wireshark and via sysctl -a. Compared to a client computer with the Debian based Ubuntu 18.04 LTS, the following is different: = 1 = 0 = 0 = 0

The forwarding is set for all interfaces on default via the file /etc/sysctl.d/10-default.conf (since the year 2013). That is nice for router scenarios but not if I want a host. Should that value not be changed when I do not want ‘Router’ but select ‘Computer’ as LAN mode in Foris? So, this is a bug report to the Turris team.

Furthermore, OpenWRT disables accept_ra via the file /etc/init.d/sysctl (since the year 2013 as well) without getting into detail what exactly the problem was. I am not sure whom to blame for /report that.

After fixing those values myself (the other two change the default accordingly) via the file /etc/sysctl.conf: = 0 = 1

I see a working dual-stack single interface (even without needing a DHCPv6 server thanks to SLAAC). Now, on the SSH interface, ifconfig gives a 2000::/3 and check_connection does not give UNKNOWN for the IPv6 Gateway anymore. Instead, I get a OK for every subtest.

All this should be done automatically. However, as there is no IPv6 test in the Foris interface, I wonder if LAN/Computer/IPv6 is a supported scenario at all. Here in Germany, at least for DSL providers like Telekom Deutschland, United Internet (1&1), and Telefónica (O₂) offer IPv4/IPv6 Dual Stack. Their CPEs come configured my way. Therefore, if that scenario is not supported by Turris OS, yet, I would prefer = 1

Once again: With the default (non-router) configuration, I see unroutable DNS traffic from my home network being sent to my Turris MOX.

If your upstream router acts as DHCPv4|6 server it would be logical to turn that functionality off in the M and let it be a DHCP client only in order to avoid duplication and potential network issues.

If your upstream router acts as DNS server a/o DNS query forwarder it would be logical to turn that functionality off in the M and let it be a DNS client only in order to avoid duplication and potential network issues.

That said, setting the M as Computer via Foris it would probably be expected to be done so automatically.

Whilst SLAAC probably works around the need for creating two logical interfaces, one for DHCPv4 and one for DHCPv6, it does not if stateful DHCPv6 is to be deployed.

However, that is broken right now (tested current HBS, HBT, and HBK), because those four (default) parameters are not changed by Foris.

Mhm, you are about stateful and pretend on it. I tested only stateless IPv6. If you really need stateful IPv6, I have a look into that again. However I am curious, what is your use-case for DHCPv6? Here in Germany, DHCPv6 is a dead horse since Microsoft added support for RDNSS. As of today, I am aware of only one use-case and that is Windows 8.1 (or Windows 10 Version 1507 LTSB or Windows 10 Version 1607 LTSB) in a IPv6-only scenario. I thought, you were looking for a Dual-Stack connectivity while your Turris device is a host client, in general.

Well, there is a complete different use case, at least here: You have several Wi-Fi access points in your LAN and the user roams between them, for example a Wi-Fi phone while being in a call. In that case, the Wi-Fi access point must be configured as bridge without NAT. In my case, the Turris MOX(es) are Wi-Fi access points. If there is a DHCP server in one of the access points does not matter actually. Actually, right now my DHCP server is not my router (and my DNS server not my router and not my DHCP server). So the idea is, to have no NAT. My use-case is just about NAT. Again, I am curious, what is your use-case to run Turris OS as host computer?

What is to pretend on it?

not necessary, stateful DHCPv6 along with DHCPv4 requires two virtual interfaces.

You lost me there since this thread never been a IPv6-only scenario but indeed

How so not? It will listen to DHCP ( and DNS if enabled) queries from the downstream client and respond accordingly, as you asserted

Not sure how that relates to your initial post in this thread?

Upps. I meant ‘persist’. I am asking about your use-case for DHCPv6 because I am curious.

I was telling you about my use-case: I want my Turris device to be a Wi-Fi bridge and being able to configure it, whether the existing network is IPv4-only or IPv6-only. For this, NAT must be disabled (Foris → LAN → Mode: Computer) and an IPv6 must be derived somehow. In my case, SLAAC+RDNSS is sufficient. And because that does not work out-of-the-box, I had to make it happen (see initial post). By this, I noticed that its default IPv6 configuration even bogs down an IPv6 enabled network. Therefore, I posted the alternative to disable IPv6 completely.

Which is not necessary at all if you just disable the DHCP and DNS servers on the AP, which I would do in any case to avoid potential duplication if there is already another node in the network providing DHCP and DNS servers. But that is just me then.

I am not using Foris really, thus not sure what happens (or not) there. But of course it makes sense to disable masquerading in that scenario.