Questing:
Tested on ASUS ROG Zephyrus G15
Control tests:
- Confirmed that internet sharing does not work
- Confirmed that all regression tests in test plan work as described, as a
baseline.
Regression tests:
- Confirmed that with the version in questing-proposed, all regression tests
described above behave the same as with the prior version
New functionality tests:
- Confirmed that internet sharing works correctly with the questing-proposed
version when tested as described above
❯ apt policy network-manager
network-manager:
Installed: 1.52.0-1ubuntu3.2
Candidate: 1.52.0-1ubuntu3.2
Version table:
*** 1.52.0-1ubuntu3.2 100
100 http://us.archive.ubuntu.com/ubuntu questing-proposed/main amd64
Packages
100 /var/lib/dpkg/status
1.52.0-1ubuntu3.1 500
500 http://us.archive.ubuntu.com/ubuntu questing-updates/main amd64
Packages
1.52.0-1ubuntu3 500
500 http://us.archive.ubuntu.com/ubuntu questing/main amd64 Packages
** 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
+ 1. `docker run --rm -ti busybox ping -c4 1.1.1.1`
2. Ensure that the pings are successful
3. Start the hotspot
4. Ensure that the pings are still successful when running (1)
+ 5. Also check `docker run --rm -ti busybox ping -c4 google.com` to ensure
there are no DNS issues
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.
** Tags removed: verification-needed-questing
** Tags added: verification-done-questing
--
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
