How do I complete my WLAN configuration?

[tsmx0182]

Here's my /etc/network/interfaces:

auto lo
iface lo inet loopback

iface enp2s0 inet manual

allow-hotplug whistle0
iface whistle0 inet dhcp

auto vmbr0
iface vmbr0 inet static
    address 192.168.100.2/24
    gateway 192.168.100.1
    bridge-ports enp2s0
    bridge-stp off
    bridge-fd 0

auto vmbr1
iface vmbr1 inet static
    address 192.168.101.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s '192.168.101.0/24' -o whistle0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '192.168.101.0/24' -o whistle0 -j MASQUERADE

source /etc/network/interfaces.d/*

Right now I'm configuring my Proxmox box via Ethernet: vmbr0 and enp2s0 correspond to a physical Ethernet port, an Ethernet cable connects this port to my PC, my laptop's Ethernet card is configured by systemd-networkd to have a static IP address 192.168.100.1/24, masquerading is also enabled in order to provide Internet access to the box.

The plan is to get rid of the wired connection (leave it for emergencies) and provide internet access to VMs and containers using a USB WiFi adapter (yeah I know). I'm also planning to create a Zerotier container which will be used for accessing and configuring the box when I'm not home.

The WiFi adapter is represented by the interface whistle0. The WiFi link itself is managed by the iwd service, the rest (DHCP in particular) is left to ifupdown as usual. Currently it's able to receive the address:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether 90:8d:6e:8d:d9:b8 brd ff:ff:ff:ff:ff:ff
4: whistle0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:e1:b0:18:69:46 brd ff:ff:ff:ff:ff:ff
    inet 192.168.30.158/24 brd 192.168.30.255 scope global dynamic whistle0
       valid_lft 6031sec preferred_lft 6031sec
    inet6 fe80::2e1:b0ff:fe18:6946/64 scope link
       valid_lft forever preferred_lft forever
5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 90:8d:6e:8d:d9:b8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::928d:6eff:fe8d:d9b8/64 scope link
       valid_lft forever preferred_lft forever
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 12:fb:f8:cc:61:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.1/24 scope global vmbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::10fb:f8ff:fecc:61fb/64 scope link
       valid_lft forever preferred_lft forever

I have a test container, it is connected to vmbr1 and has an IP of 192.168.101.2/24. The next step is to somehow connect vmbr1 and whistle0 so that the container can ping some external IPs. How do I do that?

• AFAIU currently all packets from the container get routed to vmbr0 because it has the default gateway (they also don't get responses because my PC doesn't properly masquerade packets that come from 192.168.101.0/24), and that's why my iptables rules don't make sense (they only match for packets that specifically go to wifi network). Is that right?
• What about creating some sort of routing rule that sends all packets from vmbr0 to whistle0, is that possible without knowing any addresses for whistle0 beforehand?
• What about default gateways, why doesn't dhcp method for whistle0 create a default gateway? I tried commenting out the gateway line and executing ifreload -a; ifreload --allow hotplug but it just deleted the default route without adding a new one:
  

  192.168.30.0/24 dev whistle0 proto kernel scope link src 192.168.30.158
  192.168.100.0/24 dev vmbr0 proto kernel scope link src 192.168.100.2
  192.168.101.0/24 dev vmbr1 proto kernel scope link src 192.168.101.1

• I also thought about leaving host configuration as it is and set up a passthrough for the WLAN whistle directly into a container but I didn't find any way to reliably identify a USB device between reboots/unplugs so I scratched that idea. But maybe it is, in fact, *the* right solution, and I just missed some simple way to do USB passthrough for a specific single port (not an entire hub)? Any thoughts on that?

It seems to me like it should be an easy setup: just send everything coming from this group of VMs to that interface and masquerade it. There's no way it's that hard, I must be missing something, right?

UPD:
I saw an answer that says it isn't possible to use WLAN on Proxmox (not sure where it went) so I just wanted to clarify: I know this usecase is "officially" not supported, but I know it's possible and the wiki page agrees with me: https://pve.proxmox.com/wiki/WLAN
I understand the risks and tradeoffs of using WLAN as the main access channel to the box. I'm okay with masquerading everything because I don't really need direct access to every VM from the rest of the WLAN, I'm going to use VPN for that anyway.

 

[tsmx0182]

The solution was to simply comment out the gateway line and reboot the node. After that the DHCP is able to create a default route for whistle0 and the masquerading seems to work as intended. At least for now...

 

[tsmx0182]

Update: it wasn't the solution. There's no feedback between iwd and ifupdown/dhclient, so if any change in physical/link-level config is initiated by iwd (e.g. switching to another network when the current one goes offline), the standard Proxmox tooling is not able to detect it and handle it correctly, and the whole network breaks down because the old addresses and routing tables are still being used. That is, it works, but only until someone breathes on it.

Using iwd in fully managed mode (https://wiki.debian.org/WiFi/HowToUse#iwd) seems to be a slightly better solution. It definitely can handle connecting to another network without completely losing connectivity. I will try using it a bit more and see if it always works. Proxmox wiki does say "please don't use advanced network daemons for wlan or everything might break" but maybemaybemaybe that's not the case?...