Lose access to all LAN IPs when adding more br-lan IPs

systemcrash · August 27, 2023, 3:34pm

Is there a limit to how many static IPs one can assign to an interface? My understanding is that there isn't. Running 22.03.4

I have e.g.

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '64'
        list ip6class 'local'
        list ip6class 'wan6'
        list ipaddr '192.168.1.1/24'
        list ipaddr '192.168.1.21/24'

But for some reason, if I attempt to add any more list ipaddr in the same fashion (and apply config), I lose contact with the device on all of those lan IPs. The only way back is to revert adding new IPs via VPN via the WAN(!).

Alias interfaces might be the way to go, but that is not how luci is set up.

Interfaces > lan > general settings > IPv4 addresses...

I tried with the following and I completely lose access to the router

...
        list ipaddr '192.168.1.1/24'
        list ipaddr '192.168.1.21/32'

Seems like some more error checks should go in, but I don't know what is right or wrong here.

psherman · August 27, 2023, 3:53pm

Can you describe your use case? How many addresses do you want to add and why?

AFAIK, you can add multiple addresses to an interface, but I haven't tried it in a while. You might try doing it with the subnet mask syntax rather than CIDR syntax. In other words, if you set the subnet mask in its own line, then add the addresses

interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        list ipaddr '192.168.1.1'
        list ipaddr '192.168.1.21'
        option ip6assign '64'
        list ip6class 'local'
        list ip6class 'wan6'

or if that doesn't work, maybe change the list to option for the address lines.

If those don't help, I'll try to experiment if I have time later.

systemcrash · August 27, 2023, 4:11pm

I've a ton of space in the subnet to assign IPs which I use as aliases which forward ports. (These only work through tunnels since they are in different firewall zones. Seems not possible to forward local IP to IP in lan subnet when both in same zone).

ipcidr

I added CIDR format. Perhaps the error message needs updating. Esp when you change from separate subnet/IP format. Wiki even says>

config interface 'foo'
	option device 'eth1'
	list ipaddr '10.8.0.1/24'
	list ipaddr '10.9.0.1/24'
	list ip6addr 'fdca:abcd::1/64'
	list ip6addr 'fdca:cdef::1/64'

But does not state whether IPs must be separate subnets, or can be part of the same. Seems a bit unclear.

psherman · August 27, 2023, 4:41pm

I could be wrong here, but I am pretty sure that you can assign multiple addresses within the same subnet into a network interface, but you cannot assign addresses from different subnets in the same network interface. So that might suggest that the wiki is wrong, at least in that way.

With respect to the CIDR notation vs classical subnet mask, the wiki makes it look like you can (or maybe must) use CIDR notation. My idea, though, was to remove the CIDR notation from all of the addresses and include the subnet mask explicitly.

So... with a single address, a network interface can be defined like this:

interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.1.1'

or like this (the above and below are equivalent):

interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1/24'

If you take the former (explicit subnet mask), it might work with the multiple addresses... but I might need to experiment to know for sure.

jow · August 27, 2023, 4:42pm

In doubt use a.b.c.d/32 if bare IP notation is rejected. Overlapping subnets are allowed, but I would only declare the primary address with a /24 suffix and all others without or with an explicit /32 one.

list ipaddr '192.168.1.1/24'
list ipaddr '192.168.1.21'
list ipaddr '192.168.1.22'
list ipaddr '192.168.1.23'
…

Omit the netmask option when using the CIDR list notation.

psherman · August 27, 2023, 4:50pm

On these use-case scenarios, I'm not sure why you would use different addresses. Sure you have plenty of space in the subnet, but there is no security benefit to the different addresses. And if the connection requests are coming from the wan, you should be using traffic rules, not port forwarding.

I'm not following this at all. The lan is (usually) in the lan zone. This covers the entire subnet. A network cannot be in multiple zones. And individual addresses cannot be in different zones, either. You can make granular firewall rules to govern individual addresses, but it doesn't have much purpose when the addresses all belong to the router itself.

Can you elaborate on the specifics of what you're trying to achieve.

_bernd · August 27, 2023, 5:19pm

I would second this. Either use the same subnet mask for all addresses on the same interface or use single addresses (/32 or /128) on loopback only.

systemcrash · August 28, 2023, 10:39am

This was a notation I explicitly tested and completely lost access to the router (see first message). So in this case, it "should" be as your /24 example, and the error message there needs reviewing.

Applying e.g.

list ipaddr '192.168.1.1/24'
list ipaddr '192.168.1.21'
list ipaddr '192.168.1.22'
list ipaddr '192.168.1.23'
…

Is interpreted as:

IPv4: 192.168.1.1/24
IPv4: 192.168.1.21/32
IPv4: 192.168.1.22/32
etc

Which also kills access on the lan.

I think you meant "define it separately". In this way it is possible to define only one address (at least according to how luci behaves).

ipplusnetmaskseparately

The wiki also says: If, instead of a list, several ipaddr are specified as options, only the last is applied. Seems like that won't work.

It's not about security for me, I'm in the LAN range. Guests access via wireguard tunnels, which use addresses also in the lan subnet range. I use extra IPs on the router, each of which forward e.g. port 80 to some other docker host service which shares multiple ports. Then I just define DHCP hostnames to said extra IPs, and everything is easy. I don't always remember ports for services, but I can remember names. ( I don't want more NAT to another docker network )

luci firewall won't forward a port from one extra LAN IP to another within the same zone (so this config is for use by vpn hosts, and not on the local lan, vpn hosts which are in a different zone, which means port forwards work). At least not when building rules from those defined in the GUI. A subnet can be in multiple zones - if you're using wireguard (which has a separate zone).

Please only 'second' something when we know the wisdom is gospel: that we know what we are saying to be fact, which ends up in the wiki. What is a "single address on loopback only"?

IPv6 notation we almost always have to spec the netmask. Given the tendency, I think we should add netmasks in IPv4 for consistency. But doing a /32 in IPv4 - total router lockout. Doing an additional /24.... lose access on all lan IPs.

jow · August 28, 2023, 12:00pm

This works just fine here. On a freshly booted x86 VM I did these uci commands and I can ping all IP addresses:

root@OpenWrt:/# uci set network.lan.ipaddr=192.168.1.1/24
root@OpenWrt:/# uci del network.lan.netmask
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.21
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.22
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.23
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.24
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.25
root@OpenWrt:/# ifup lan

There's likely something else in your setup causing the lockout, but simply assigning multiple addresses to an interface is no problem at all.

systemcrash · August 28, 2023, 12:29pm

Good. Thank you for confirmation, at least. I have considered that it could be something else.

jow · August 28, 2023, 12:30pm

I now also tried this and it works as well:

root@OpenWrt:/# uci set network.lan.ipaddr=192.168.1.1/24
root@OpenWrt:/# uci del network.lan.netmask
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.21/24
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.22/24
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.23/24
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.24/24
root@OpenWrt:/# uci add_list network.lan.ipaddr=192.168.1.25/24
root@OpenWrt:/# ifup lan

systemcrash · August 28, 2023, 12:47pm

OK, I shut down all wireguard tunnels and adding IPs in both formats works cleanly - although I guess the original question still stands. Maybe there is no realistic limit

But: at bootup with two IPs, and wg tunnels, start up and connectivity OK. Adding IPs after bootup is problematic.

The root of the problem is having a wg tunnel whose local endpoint IP is also in the LAN range. Adding LAN IPs: death. Booting up with multiple LAN IPs configured: OK.

Edit: stop wg tunnel with local endpoint lan IP, add more lan IPs to br-lan, start wg tunnel. Result: OK.

More than this I cannot debug. The logs show:

Mon Aug 28 14:54:59 2023 daemon.notice netifd: Interface 'lan' is now down
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.339384] br-lan: port 4(wlan1) entered disabled state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.345005] br-lan: port 3(wlan0-1) entered disabled state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.350768] br-lan: port 2(wlan0) entered disabled state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.356287] br-lan: port 1(eth1.1) entered disabled state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.482100] device eth1.1 left promiscuous mode
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.487023] device eth1 left promiscuous mode
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.492351] br-lan: port 1(eth1.1) entered disabled state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.572147] eth1: link down
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.612364] device wlan0 left promiscuous mode
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.617150] br-lan: port 2(wlan0) entered disabled state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.658973] device wlan0-1 left promiscuous mode
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.664123] br-lan: port 3(wlan0-1) entered disabled state
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 0 addresses
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.733097] device wlan1 left promiscuous mode
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.738252] br-lan: port 4(wlan1) entered disabled state
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 0 addresses
Mon Aug 28 14:54:59 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 14:54:59 2023 daemon.notice netifd: Interface 'lan' is disabled
Mon Aug 28 14:54:59 2023 daemon.notice netifd: Interface 'lan' has link connectivity loss
Mon Aug 28 14:54:59 2023 daemon.notice netifd: Interface 'lan' has link connectivity
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.811438] eth1: link up (1000Mbps/Full duplex)
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.816246] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.850240] br-lan: port 1(eth1.1) entered blocking state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.856113] br-lan: port 1(eth1.1) entered disabled state
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.862121] device eth1.1 entered promiscuous mode
Mon Aug 28 14:54:59 2023 kern.info kernel: [168944.867116] device eth1 entered promiscuous mode
Mon Aug 28 14:55:00 2023 kern.info kernel: [168944.922744] br-lan: port 2(wlan0) entered blocking state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168944.928376] br-lan: port 2(wlan0) entered disabled state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168944.934165] device wlan0 entered promiscuous mode
Mon Aug 28 14:55:00 2023 kern.info kernel: [168944.995347] br-lan: port 3(wlan0-1) entered blocking state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.001046] br-lan: port 3(wlan0-1) entered disabled state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.007071] device wlan0-1 entered promiscuous mode
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.080085] br-lan: port 4(wlan1) entered blocking state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.085574] br-lan: port 4(wlan1) entered disabled state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.091563] device wlan1 entered promiscuous mode
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.142316] br-lan: port 4(wlan1) entered blocking state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.147857] br-lan: port 4(wlan1) entered forwarding state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.153658] br-lan: port 3(wlan0-1) entered blocking state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.159345] br-lan: port 3(wlan0-1) entered forwarding state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.165242] br-lan: port 2(wlan0) entered blocking state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.170747] br-lan: port 2(wlan0) entered forwarding state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.176482] br-lan: port 1(eth1.1) entered blocking state
Mon Aug 28 14:55:00 2023 kern.info kernel: [168945.182075] br-lan: port 1(eth1.1) entered forwarding state
Mon Aug 28 14:55:00 2023 daemon.notice netifd: Interface 'lan' is enabled
Mon Aug 28 14:55:00 2023 daemon.notice netifd: Interface 'lan' is setting up now
Mon Aug 28 14:55:00 2023 daemon.notice netifd: Interface 'lan' is now up
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 addresses
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 addresses
Mon Aug 28 14:55:00 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
* Mon Aug 28 14:55:01 2023 daemon.err odhcpd[1900]: Failed to send to ff02::1%lan@br-lan (Address not available)
Mon Aug 28 14:55:02 2023 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)

An interesting row is starred (*) - but no behaviour difference when stopping or disabling odhcpd during experiments.

Everything else is OK but for total connection loss on LAN. Then I stop the vpn interface via wan vpn

Mon Aug 28 14:55:36 2023 daemon.notice netifd: Network device 'wg2' link is down
Mon Aug 28 14:55:37 2023 daemon.notice netifd: Interface 'wg2' is now down

Then everything comes back. Nothing else is logged.

When I stop wg tunnel with local endpoint lan IP, add more lan IPs to br-lan, start wg tunnel. Result: OK. Here is the equivalent log:

(manual stop of wg2)
Mon Aug 28 15:05:26 2023 daemon.notice netifd: Network device 'wg2' link is down
Mon Aug 28 15:05:26 2023 daemon.notice netifd: Interface 'wg2' is now down
Mon Aug 28 15:05:45 2023 daemon.notice netifd: Interface 'lan' is now down
Mon Aug 28 15:05:45 2023 kern.info kernel: [169589.972649] br-lan: port 4(wlan1) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169589.978287] br-lan: port 3(wlan0-1) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169589.984038] br-lan: port 2(wlan0) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169589.989566] br-lan: port 1(eth1.1) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.114429] device eth1.1 left promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.119242] device eth1 left promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.124090] br-lan: port 1(eth1.1) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.204396] eth1: link down
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.250160] device wlan0 left promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.254891] br-lan: port 2(wlan0) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.300188] device wlan0-1 left promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.305091] br-lan: port 3(wlan0-1) entered disabled state
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 0 addresses
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.359981] device wlan1 left promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.364758] br-lan: port 4(wlan1) entered disabled state
Mon Aug 28 15:05:45 2023 daemon.notice netifd: Interface 'lan' is disabled
Mon Aug 28 15:05:45 2023 daemon.notice netifd: Interface 'lan' has link connectivity loss
Mon Aug 28 15:05:45 2023 daemon.notice netifd: Interface 'lan' has link connectivity
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 0 addresses
Mon Aug 28 15:05:45 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.439916] eth1: link up (1000Mbps/Full duplex)
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.470115] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.479019] br-lan: port 1(eth1.1) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.484802] br-lan: port 1(eth1.1) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.490838] device eth1.1 entered promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.495799] device eth1 entered promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.553955] br-lan: port 2(wlan0) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.559442] br-lan: port 2(wlan0) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.565269] device wlan0 entered promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.627724] br-lan: port 3(wlan0-1) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.633530] br-lan: port 3(wlan0-1) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.639602] device wlan0-1 entered promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.717103] br-lan: port 4(wlan1) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.722781] br-lan: port 4(wlan1) entered disabled state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.728572] device wlan1 entered promiscuous mode
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.790260] br-lan: port 4(wlan1) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.795783] br-lan: port 4(wlan1) entered forwarding state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.801598] br-lan: port 3(wlan0-1) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.807259] br-lan: port 3(wlan0-1) entered forwarding state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.813186] br-lan: port 2(wlan0) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.818670] br-lan: port 2(wlan0) entered forwarding state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.824421] br-lan: port 1(eth1.1) entered blocking state
Mon Aug 28 15:05:45 2023 kern.info kernel: [169590.829990] br-lan: port 1(eth1.1) entered forwarding state
Mon Aug 28 15:05:46 2023 daemon.notice netifd: Interface 'lan' is enabled
Mon Aug 28 15:05:46 2023 daemon.notice netifd: Interface 'lan' is setting up now
Mon Aug 28 15:05:46 2023 daemon.notice netifd: Interface 'lan' is now up
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 addresses
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 addresses
Mon Aug 28 15:05:46 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 15:05:48 2023 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Mon Aug 28 15:05:51 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 15:05:51 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 15:05:51 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 addresses
Mon Aug 28 15:05:51 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 15:05:53 2023 authpriv.info dropbear[2440]: Early exit: Terminated by signal
Mon Aug 28 15:05:53 2023 authpriv.info dropbear[6329]: Not backgrounding
Mon Aug 28 15:06:01 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Mon Aug 28 15:06:01 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Aug 28 15:06:01 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 addresses
Mon Aug 28 15:06:01 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Aug 28 15:06:01 2023 user.notice pbr: Reloading pbr due to includes of firewall
Mon Aug 28 15:06:02 2023 user.notice pbr: Reload on firewall action aborted: service not running.
Mon Aug 28 15:06:04 2023 daemon.notice miniupnpd[6835]: HTTP listening on port 5000
Mon Aug 28 15:06:04 2023 daemon.notice miniupnpd[6835]: Listening for NAT-PMP/PCP traffic on port 5351
(manual start of wg2)
Mon Aug 28 15:06:06 2023 daemon.notice netifd: Interface 'wg2' is setting up now
Mon Aug 28 15:06:07 2023 daemon.notice netifd: Interface 'wg2' is now up
Mon Aug 28 15:06:07 2023 daemon.notice netifd: Network device 'wg2' link is up
Mon Aug 28 15:06:09 2023 user.notice firewall: Reloading firewall due to ifup of wg2 (wg2)

_bernd · August 28, 2023, 1:14pm

Multiple addresses on an interface is not that uncommon. See, for instance if you run 2 routers in a high-availability setup. One router uses (as an example) 192.0.2.2/24 and the other 192.0.2.3/24, and the active one gets in addition the 192.0.2.1/24 assigned.
Or you have some shity left-overs from the dudes before your time and you have to run multiple addresses on a server to support a broken network "design"... How ever: Seen this many times. Done this plenty of times... Source? I get money on my day job to do "networking" with "linux". And I didn't get fired yet

What is an address on loopback?
You see 127.0.0.1/8 on loopback (lo)? That's the "localhost" address on loopback. For routers it is not uncommon that have additional addresses on loopback.
But mostly as a host address, so either a /32 or a /128.
Linux will by default answer an ARP request for address on any interface even if that address is not assigned to this particular interface.
Like on eth0 you have 192.0.2.17/24 but the ping comes in (for some reason) on eth1, then eth1 will answer. With loopback its the same. In networks / on routers you use addresses on loopback, because this interface (mostly and normally) will never go down, so the router will never loose this address. That's why you can and should assign certain addresses to the loopback interface.

I second not specifically the syntax jow has used, and stated that how ever the same netmask should be used to prevent certain fukkups.

psherman · August 28, 2023, 3:24pm

This doesn't sound right... because they are routed interfaces, WG and lan should have different subnets. Can you share your complete network config file (obviously with keys and such redacted)?

If the service is hosted on the router itself, forwards should not be necessary since it is governed by the input rule.

I'm pretty sure that this isn't true... but I'd have to see your firewall config, too. Can you post that?
The system will allow you to put a single network into multiple firewall zones, but that actually is not the correct approach -- it is an undefined behavior. A given network should never be assigned to more than one firewall zone.

systemcrash · August 28, 2023, 4:00pm

Off-device, on a NAS. So... port forwards

I route me/wg2/192.168.1.0/24 <-> them/wg0/192.168.178.0/24. Such that 192.168.1.0/24 and 192.168.178.0/24 reach each other, the me/wg2 has IP 192.168.1.5 (for local tunnel endpoint).

The problem in this whole scenario was that I had 192.168.1.5/24 instead of 192.168.1.5/32. Changing it to 192.168.1.5/32 fixed the problem of losing access via lan on config apply.

Bad:

...
config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '64'
        list ip6class 'local'
        list ip6class 'wan6'
        list ipaddr '192.168.1.1/24'
        list ipaddr '192.168.1.21/24'
        list ipaddr '192.168.1.22/24'
...


config interface 'wg_uk'
        option proto 'wireguard'
        ...
        list addresses '192.168.1.5/24'


config wireguard_wg_uk
        ...
        list allowed_ips '192.168.178.0/24'

Good:

...
config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '64'
        list ip6class 'local'
        list ip6class 'wan6'
        list ipaddr '192.168.1.1/24'
        list ipaddr '192.168.1.21/24'
        list ipaddr '192.168.1.22/24'
...


config interface 'wg2'
        option proto 'wireguard'
        ...
        list addresses '192.168.1.5/32'


config wireguard_wg2
        ...
        list allowed_ips '192.168.178.0/24'

In any case, respect for helping out @psherman, we got there in the end.

psherman · August 28, 2023, 4:20pm

The wireguard interface that is overlapping with the lan subnet is wrong. It must be a different subnet than your lan.

systemcrash · August 28, 2023, 5:13pm

True, I probably could/should add a link net IP...

system · September 7, 2023, 5:14pm

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