Thanks @Andreas! I updated the test plan as requested. Let me know if you need anything else changed before this can go into -proposed.
** Description changed: SRU Justification: [ Impact ] When a wi-fi hotspot is being broadcast, NetworkManager does not automatically configure all firewall rules as needed for clients to access the internet. [ Test Plan ] - Start wi-fi hotspot on device running ufw that is connected to the - internet + Hotspot internet sharing (new/fixed functionality test): + Start wi-fi hotspot on device running ufw that is connected to the internet + + Regression tests: + Before starting, ensure that UFW is enabled + LXD: Ensure containers can still reach the internet + 1. Create an LXD VM and container on your host + 2. With the hotspot off, `ping 1.1.1.1` on both the container and VM. Verify that it can reach the internet as expected. + 3. Turn the hotspot on on the host. + 4. Ensure that the LXD container and VM can both still `ping 1.1.1.1` (i.e., the guest networking hasn't been interrupted by the new hotspot-set rules) + + Docker: Ensure a basic (busybox) container can still reach the internet: + 1. `docker run --rm -ti busybox ping -c4`busybox + 2. Ensure that the pings are successful + 3. Start the hotspot + 4. Ensure that the pings are still successful when running (1) + + SSH: Ensure that a blocked SSH port remains blocked + 1. With UFW disabled, ensure that you can `ssh` into the host (to make sure there isn't a network issue) + 2. Enable UFW and ensure that ssh is blocked (either absent from `sudo ufw status` or marked as blocked). + 3. Ensure that you cannot `ssh` to the host anymore + 4. Start the hotspot + 5. Ensure that you still cannot `ssh` to the host + + Apache2: Ensure that a blocked HTTP port remains blocked + 1. With UFW disabled, ensure that you can access the http server running on the host from another host (to make sure there isn't a network issue) + 2. Enable UFW and ensure that apache2 is blocked (either absent from `sudo ufw status` or marked as blocked). + 3. Ensure that you cannot reach the http port on the host anymore + 4. Start the hotspot + 5. Ensure that you still cannot reach the http port on the host [ Actual result ] Clients cannot connect to the internet via the hotspot. Only after adding custom firewall rules such as those described above can the client connect to the internet. [ Expected result ] Clients can connect to the internet via the hotspot [ Fix ] At minimum, the following is needed to enable this: 1. Enable routing from wireless adapter to wired adapter (ex: sudo ufw route allow in on wlP9s9 out on enp1s0 (varies depending on adapter names)) 2. Set iptables forwarding rules correctly (ex: sudo iptables -P FORWARD ACCEPT) 3. If the host is running its own DNS / DHCP servers, those will also have to be allowed by the firewall This is already implemented by NetworkManager. However, since applications like UFW configure firewall rules directly through /etc/sbin/iptables, NetworkManager needs to be configured to do so as well. Since we don't explicitly set a firewall backend to use in our config, NM checks for the existence of nftables and uses it since it is installed on Ubuntu, which is not sufficient to override the rules set via iptables by UFW and Docker. Therefore, the most straightforward solution is to configure Ubuntu's NetworkManager to use iptables as its firewall backend, bringing it in line with how UFW orchestrates its firewall rules. (Apply this config change to set iptables as the default backend for NM: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/2128668/comments/6) [ Where problems could occur ] While NetworkManager should be configuring the same rules regardless of the firewall backend used, any differences that might exist between how /usr/sbin/iptables and /usr/sbin/nftables handles the setup could manifest as user-visible differences in firewall behavior. Additionally, since /usr/sbin/iptables is a symlink to /etc/alternatives/iptables, a user who has changed their /etc/alternatives/iptables target could also deviate from the behavior of a default Ubuntu configuration. With that said, keeping this configuration as-is may also have risks beyond the hotspot sharing use-case, since even the default firewall profiles in NM are currently set via the nftables interface, which I've observed is not always in sync with the UFW-enforced rules set via /usr/sbin/iptables. ** Description changed: SRU Justification: [ Impact ] When a wi-fi hotspot is being broadcast, NetworkManager does not automatically configure all firewall rules as needed for clients to access the internet. [ Test Plan ] Hotspot internet sharing (new/fixed functionality test): Start wi-fi hotspot on device running ufw that is connected to the internet Regression tests: Before starting, ensure that UFW is enabled LXD: Ensure containers can still reach the internet 1. Create an LXD VM and container on your host 2. With the hotspot off, `ping 1.1.1.1` on both the container and VM. Verify that it can reach the internet as expected. 3. Turn the hotspot on on the host. 4. Ensure that the LXD container and VM can both still `ping 1.1.1.1` (i.e., the guest networking hasn't been interrupted by the new hotspot-set rules) Docker: Ensure a basic (busybox) container can still reach the internet: 1. `docker run --rm -ti busybox ping -c4`busybox 2. Ensure that the pings are successful 3. Start the hotspot 4. Ensure that the pings are still successful when running (1) SSH: Ensure that a blocked SSH port remains blocked 1. With UFW disabled, ensure that you can `ssh` into the host (to make sure there isn't a network issue) 2. Enable UFW and ensure that ssh is blocked (either absent from `sudo ufw status` or marked as blocked). 3. Ensure that you cannot `ssh` to the host anymore 4. Start the hotspot 5. Ensure that you still cannot `ssh` to the host Apache2: Ensure that a blocked HTTP port remains blocked 1. With UFW disabled, ensure that you can access the http server running on the host from another host (to make sure there isn't a network issue) 2. Enable UFW and ensure that apache2 is blocked (either absent from `sudo ufw status` or marked as blocked). 3. Ensure that you cannot reach the http port on the host anymore 4. Start the hotspot 5. Ensure that you still cannot reach the http port on the host [ Actual result ] + For new functionality test: Clients cannot connect to the internet via the hotspot. Only after adding custom firewall rules such as those described above can the client connect to the internet. + (Regression tests should have unchanged behavior) + [ Expected result ] + For new functionality test: Clients can connect to the internet via the hotspot + + (Regression tests should have unchanged behavior) [ Fix ] At minimum, the following is needed to enable this: 1. Enable routing from wireless adapter to wired adapter (ex: sudo ufw route allow in on wlP9s9 out on enp1s0 (varies depending on adapter names)) 2. Set iptables forwarding rules correctly (ex: sudo iptables -P FORWARD ACCEPT) 3. If the host is running its own DNS / DHCP servers, those will also have to be allowed by the firewall This is already implemented by NetworkManager. However, since applications like UFW configure firewall rules directly through /etc/sbin/iptables, NetworkManager needs to be configured to do so as well. Since we don't explicitly set a firewall backend to use in our config, NM checks for the existence of nftables and uses it since it is installed on Ubuntu, which is not sufficient to override the rules set via iptables by UFW and Docker. Therefore, the most straightforward solution is to configure Ubuntu's NetworkManager to use iptables as its firewall backend, bringing it in line with how UFW orchestrates its firewall rules. (Apply this config change to set iptables as the default backend for NM: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/2128668/comments/6) [ Where problems could occur ] While NetworkManager should be configuring the same rules regardless of the firewall backend used, any differences that might exist between how /usr/sbin/iptables and /usr/sbin/nftables handles the setup could manifest as user-visible differences in firewall behavior. Additionally, since /usr/sbin/iptables is a symlink to /etc/alternatives/iptables, a user who has changed their /etc/alternatives/iptables target could also deviate from the behavior of a default Ubuntu configuration. With that said, keeping this configuration as-is may also have risks beyond the hotspot sharing use-case, since even the default firewall profiles in NM are currently set via the nftables interface, which I've observed is not always in sync with the UFW-enforced rules set via /usr/sbin/iptables. ** Changed in: network-manager (Ubuntu Jammy) Status: Incomplete => In Progress ** Changed in: network-manager (Ubuntu Noble) Status: Incomplete => In Progress ** Changed in: network-manager (Ubuntu Questing) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2128668 Title: Wi-Fi hotspot startup does not configure firewall as needed for internet sharing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2128668/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
