Clearly, affected users might be much better off to use their own tests or setups that they can re-use for this. The following just tries to come up with something a third party could re-use to test this.
0. prep a VPN server/client setup with IKEv2 I used [1] to first get a server and client setup in two VMs. A wrapper to get this done via uvtool is attached as test-strongswan-bug-1772705.tgz Call it like: $ ./test.sh bionic Once the above is up and working continue 1. Install test system Those above are (in my case) using server images, but for Network Manager we need a Desktop. - Download a Bionic Desktop ISO and install it into e.g. using virt-manager - In addition to the default make the guest part of the network that the strongswan server is in 2. Make sure you have installed strongswan-nm $ apt install strongswan-nm 3. Setup a strongswan connection, e.g. follow [2] to do so. The actual check, when you connect to that VPN via NM the DNS servers that will be added are total garbage. Check this via e.g.: $ nmcli dev show | grep DNS [1]: https://code.launchpad.net/~ubuntu-security/qa-regression-testing/+git/qa-regression-testing [2]: https://wiki.strongswan.org/projects/strongswan/wiki/NetworkManager ** Attachment added: "test-strongswan-bug-1772705.tgz" https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1772705/+attachment/5304816/+files/test-strongswan-bug-1772705.tgz ** Description changed: + [Impact] + + * Due to a rework of libnm-glib to libnm there was an error in the + strongswan code. This error lead to pass garbadge (pointer instead of + string) to the parser that pushes new config to NM on connection. + + * Upstream had a fix for quite a while, it already is in Ubuntu since + Cosmic. But we should also backport it to Bionic. + + + [Test Case] + + * The test follows 4 rough steps, comment #15 has details about them + 0. prep a VPN server/client setup with IKEv2 + 1. Install test system + 2. Make sure you have installed strongswan-nm + 3. Setup a strongswan connection in NM GUI + + [Regression Potential] + + * Compared to accessing almost random data the new code seems much safer. + But let us be strict and anticipate regressions, I think in a setup + that was used to get "no valid" DNS carried over it might now actually + get proper DNS which might change name resolution for those clients. + I doubt this is too much of an issue, as the wrong DNS before would + already have added a delay forcing the user to debug and workaround, + but that is the one regression that comes to mind. + * This change only affects charon-nm which means + a) not the strongswan server + b) no systemd-networkd setups + c) no setups that didn't use the NM plugin + + [Other Info] + + * n/a + + --- + + Description: Ubuntu 18.04 LTS Release: 18.04 strongswan-nm: - Installed: 5.6.2-1ubuntu2 - Candidate: 5.6.2-1ubuntu2 - Version table: - *** 5.6.2-1ubuntu2 500 - 500 http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages - 100 /var/lib/dpkg/status + Installed: 5.6.2-1ubuntu2 + Candidate: 5.6.2-1ubuntu2 + Version table: + *** 5.6.2-1ubuntu2 500 + 500 http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages + 100 /var/lib/dpkg/status Expectation: Strongswan should actually receive and set the DNS server properly. What does happen: Strongswan-nm (charon-nm) does set a random DNS server which breaks the name resolution completely. The bug has already been reported for RedHat, and has been fixed in the strongswan upstream repo: https://bugzilla.redhat.com/show_bug.cgi?id=1574939 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1772705 Title: IKEv2 VPN connections fail to use DNS servers provided by the server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1772705/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
