From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Feedback on WG Date: Sat, 07 Sep 2024 16:21:39 +0200 Message-ID: <6798285f-8b29-4040-b6c9-c9eb258443b4@ipfire.org> In-Reply-To: <68C1404A-2023-4E82-AD49-F067B258E8A7@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6822148208252360666==" List-Id: --===============6822148208252360666== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, I have modified the subnet for wireguard and enabled the openvpn n2n=20 connection again. I then made two new connections, one for my laptop and the for my=20 android phone. In both cases the connection was successfully made and ping packets were=20 successfully sent and received in both directions. Also can now browse etc through the tunnel. I will now look at testing out the new changes made yesterday. Are these=20 available as an iso that I can install or do I need to clone the changes=20 into a repo on my system and build it? Regards, Adolf. On 06/09/2024 17:03, Michael Tremer wrote: > Just to update the list: We have been able to solve this problem off list. >=20 > OpenVPN was greedy and didn=E2=80=99t allow WG packets to flow. >=20 >> On 5 Sep 2024, at 11:53, Adolf Belka wrote: >> >> Hi Michael, >> >> I renamed the config file to wg0 and the interface was then labelled wg0 b= ut the ping from laptop (192.168.26.37) to IPFire with WG (192.168.200.254) s= till lost all packets. >> >> I have also found that the nmcli command line when creating a connection f= rom scratch as opposed to importing it has the commands to name the interface= and to name the connection so the two can be different. >> >> Regards, >> Adolf. >> >> >> On 05/09/2024 11:27, Adolf Belka wrote: >>> Hi Michael, >>> >>> On 30/08/2024 17:43, Michael Tremer wrote: >>>> Hello, >>>> >>>>> On 29 Aug 2024, at 18:53, Adolf Belka wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> On 29/08/2024 15:53, Michael Tremer wrote: >>>>>> Hello, >>>>>>> On 29 Aug 2024, at 14:36, Adolf Belka wrot= e: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> On 29/08/2024 11:28, Michael Tremer wrote: >>>>>>>> Hello, >>>>>>>>> On 27 Aug 2024, at 13:09, Adolf Belka wr= ote: >>>>>>>>> >>>>>>>>> Hi Michael, >>>>>>>>> >>>>>>>>> On 27/08/2024 12:19, Michael Tremer wrote: >>>>>>>>>> Could you show me the route tables of both systems, please? >>>>>>>>> >>>>>>>>> The laptop has >>>>>>>>> ip route >>>>>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 = metric 600 >>>>>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.3= 7 metric 600 >>>>>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50 >>>>>>>>> >>>>>>>>> and the vm pc on the IPFire green lan has >>>>>>>>> ip route >>>>>>>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.1= 0 metric 1002 >>>>>>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.1= 0 metric 1002 >>>>>>>> So it looks like the routes for Wireguard are missing here. >>>>>>>> Assuming that the interface is called wg0, there should be a route f= or your GREEN subnet on the laptop pointing at wg0. >>>>>>> >>>>>>> As I am having to import the wireguard conf file manually in the comm= and line, maybe I am also expected to set my own routes up on my laptop but I= am not sure what I should set the route command to. >>>>>>> >>>>>>> Normally I do an import of a VPN profile into Network Manager GUI and= it deals with everything but Network Manager cannot do this via the GUI for = Wireguard yet. So I had to just run >>>>>>> >>>>>>> nmcli connection import type wireguard file "$CONF_FILE" >>>>>> NetworkManager should configure everything for you. That is its job in= the end. >>>>>> If you use the wg command to import the configuration, I don=E2=80=99t= know whether it is creating routes or not. It could, but it might also just = care about the tunnel and nothing else. >>>>> I tried using wg-quick to import the config and it came back with: >>>>> >>>>> [#] ip link add tethysvmwg type wireguard >>>>> [#] wg setconf tethysvmwg /dev/fd/63 >>>>> [#] ip -4 address add 10.120.50.1 dev tethysvmwg >>>>> [#] ip link set mtu 1420 up dev tethysvmwg >>>>> [#] resolvconf -a tethysvmwg -m 0 -x >>>>> /usr/bin/wg-quick: line 32: resolvconf: command not found >>>>> [#] ip link delete dev tethysvmwg >>>> >>>> Well, I assumed the interface would be called wg0, but it seems that the= your distro decided to go with the easy to pronounce and really catchy name = of =E2=80=9Ctethysvmwg=E2=80=9D. >>> >>> That naming is nothing to do with the distro. >>> >>> When doing the import with the nmcli command Network Manager takes the na= me of the config file, in my case tethysvmwg, and uses that name for the inte= rface. Whether that is what it should be doing I don't know. >>> >>> Maybe I will try renaming the config file to wg0 and then import it and s= ee what happens then. >>>> >>>>> >>>>>>> where $CONF_FILE contains the path and name of the wireguard config f= ile that I downloaded from the IPFire Wireguard page. >>>>>>> >>>>>>> All the stuff I have read about routing with regard to Wireguard is j= ust a bit to complicated for me to understand what I am supposed to do in my = specific case. >>>>>> You just need a route to the GREEN network on your firewall like so: >>>>>> ip route add 192.168.0.0/24 dev wg > >>>>>> Assuming that your GREEN network is 192.168.0.0./24. >>>>> If by green network you mean the green network on my IPFire vm system t= hen it came back and said >>>>> >>>>> Cannot find device "wg0" >>>>>> What is =E2=80=9Cwg show wg0=E2=80=9D giving you? >>>>> >>>>> That command came back with >>>>> >>>>> Unable to access interface: No such device >>>>> >>>>> so I ran ip address show and the wireguard interface on the laptop is n= amed tethysvmwg which is the name of the conf file I got from IPFire because = that was the connection name I used. >>>>> >>>>> So I then ran wg show tethysvmwg and it responded with >>>>> >>>>> sudo wg show tethysvmwg >>>>> interface: tethysvmwg >>>>> public key: z48rDNDnbG5zH7yZWoY867FlqevmpfjktnlJAqdSIys=3D >>>>> private key: (hidden) >>>>> listening port: 59427 >>>>> >>>>> peer: d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=3D >>>>> preshared key: (hidden) >>>>> endpoint: 192.168.26.200:51820 >>>>> allowed ips: 192.168.200.0/24 >>>>> latest handshake: 1 minute, 39 seconds ago >>>>> transfer: 348 B received, 7.21 KiB sent >>>>> persistent keepalive: every 25 seconds >>>> >>>> So the tunnel is up. >>>> >>>>> I then ran sudo ip route add 192.168.200.0/24 dev tethysvmwg >>>>> >>>>> and ip route then showed >>>>> >>>>> ip route >>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metr= ic 600 >>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 me= tric 600 >>>>> 192.168.200.0/24 dev tethysvmwg scope link >>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50 >>>> >>>> It looks like that route was already there then, but it seems that there= might not be an IP address on the tethysvmwg interface? There should be one = in the downloaded configuration file. >>> >>> Here is the content of the config file that was generated >>> >>> [Interface] >>> PrivateKey =3D xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>> Address =3D 10.120.50.1 >>> DNS =3D 192.168.200.254 >>> >>> [Peer] >>> Endpoint =3D ipfire.local.domain.org:51820 >>> PublicKey =3D d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=3D >>> PresharedKey =3D yyyyyyyyyyyyyyyyyyyyyyyyyy >>> AllowedIPs =3D 192.168.200.0/24 >>> PersistentKeepalive =3D 25 >>> >>> Maybe I didn't fill out the WG WUI page correctly. >>> >>>> >>>> What IP address are you pinging from the firewall? >>> >>> It is the IP address of the laptop and that is 192.168.26.37 >>> >>> Regards, >>> Adolf. >>> >>>> >>>>> but ping to a machine on the IPFire green network or to the IPFire gree= n interface itself still ends up with 100% packet loss. >>>> >>>> -Michael >>>> >>>>> >>>>> Regards, >>>>> Adolf. >>>>> >>>>>> -Michael >>>>>>> >>>>>>> If you can give some hints maybe, then I can have a go at getting it = to work. >>>>>>>>> and the ipfire system has >>>>>>>>> ip route >>>>>>>>> default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 m= etric 1002 >>>>>>>>> 10.110.30.0/24 via 10.110.130.2 dev tun0 >>>>>>>>> 10.110.130.0/24 via 10.110.130.2 dev tun0 >>>>>>>>> 10.110.130.2 dev tun0 proto kernel scope link src 10.110.130.1 >>>>>>>>> 10.120.50.0/24 dev wg0 scope link >>>>>>>> This is the opposite route. >>>>>>>>> 10.120.50.2 dev tun1 proto kernel scope link src 10.120.50.1 >>>>>>>>> 192.168.26.0/24 dev red0 proto dhcp scope link src 192.168.26.200 m= etric 1002 >>>>>>>>> 192.168.120.0/24 via 10.120.50.2 dev tun1 >>>>>>>>> 192.168.200.0/24 dev green0 proto kernel scope link src 192.168.200= .254 >>>>>>>>> 192.168.220.0/24 dev blue0 proto kernel scope link src 192.168.220.= 254 >>>>>>>>> 192.168.240.0/24 dev orange0 proto kernel scope link src 192.168.24= 0.254 >>>>>>>> So I assume that from IPFire you can send packets to your laptop, bu= t they don=E2=80=99t find their way back. >>>>>>> I didn't try the ping from IPFire. I will do that and report back. >>>>>>> I just tried the ping from a machine on the green lan of the IPFire r= unning the wireguard server. >>>>>>> >>>>>>> Regards, >>>>>>> Adolf. >>>>>>> >>>>>>>> -Michael >>>>>>>>> Regards, >>>>>>>>> Adolf. >>>>>>>>>> -Michael >>>>>>>>>>> On 26 Aug 2024, at 13:13, Adolf Belka = wrote: >>>>>>>>>>> >>>>>>>>>>> I tried out netcat to send some traffic through the tunnel. That = confirmed that the tunnel is only working in one direction. >>>>>>>>>>> >>>>>>>>>>> If I put the laptop in listening mode and from a vm on the IPFire= green lan sent some data from /dev/zero through the tunnel, it was received = at the other end. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Setting the vm on the IPFire green lan into listening mode and se= nding the data from the laptop resulted in nothing being sent from the laptop= and obviously nothing received at the green vm. >>>>>>>>>>> >>>>>>>>>>> So it is not just a ping issue. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Adolf. >>>>>>>>>>> >>>>>>>>>>> On 26/08/2024 13:17, Adolf Belka wrote: >>>>>>>>>>>> Hi Michael, >>>>>>>>>>>> >>>>>>>>>>>> Getting back to testing out the WG. >>>>>>>>>>>> >>>>>>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote: >>>>>>>>>>>>> Hello Adolf, >>>>>>>>>>>>> >>>>>>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a b= it tied up with DIY stuff in the house. >>>>>>>>>>>>> >>>>>>>>>>>>> No problem... >>>>>>>>>>>>> >>>>>>>>>>>>>> By manually importing the WG config file created I was able to= successfully connect from my laptop to my IPFire vm system. The WUI showed c= onnected. The config file had my allowed subnets set as 192.168.200.0/255.255= .255.0 which is the green subnet on my vm system. However trying ping over th= e WG tunnel gave failures for the IP of the vm machine, green1, and also for = the green interface of the vm IPFire. >>>>>>>>>>>>> >>>>>>>>>>>>> Okay, connecting should be nice and easy. However, you *should*= be able to transfer some data... >>>>>>>>>>>>> >>>>>>>>>>>>>> Trying to ping with the FQDN for the green1 system resulted in= no resolving of green1's FQDN to a local IP but tried to send it to my main = red interface with my ISP. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you try to ping from either side? The client the firewall a= nd the firewall the client? That should work if the tunnel is up. >>>>>>>>>>>> >>>>>>>>>>>> Tried again to ping from laptop to IPFire green lan, both the IP= Fire green interface and a vm PC on the green lan. In both cases 100% packet = loss. >>>>>>>>>>>> >>>>>>>>>>>> I then tried doing the ping from the vm machine on the green IPF= ire lan to the laptop, as you suggested and in this case I got 100% packet tr= ansmission. >>>>>>>>>>>> >>>>>>>>>>>> In all above tests I used IP's to remove any question about DNS = resolving. >>>>>>>>>>>> >>>>>>>>>>>> So the ping seems to only be working in one direction. Let me kn= ow if there are any other tests or checks I should do based on this result. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Adolf. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> So something appears to be missing or incorrect with the routi= ng but not sure what. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Minor points on the WUI. >>>>>>>>>>>>> >>>>>>>>>>>>> I would like to have the thing working first before we spend an= y time on making the UI look nice, but you are raising very good points. >>>>>>>>>>>>> >>>>>>>>>>>>>> When disconnected the status section that is coloured red is h= uge and the space for the remark is very small but when connected then the st= atus space is large enough to have the connected status word, giving much mor= e room for the remark. >>>>>>>>>>>>> >>>>>>>>>>>>> That should not be. No idea why that is, but I am sure that is = not too hard to fix. >>>>>>>>>>>>> >>>>>>>>>>>>>> When the WG config file is created and you have the page with = the QR code, there is also a message about the WG config file only being show= n this one time as it contains private key material. The message is fine but = the heading for the message is "Oops, something went wrong...". It should rea= lly be something like "Information Note" or equivalent as it is not an actual= error message. >>>>>>>>>>>>> >>>>>>>>>>>>> I think I created a little widget which I used somewhere else t= oo and then added the headline. It certainly does not fit here. >>>>>>>>>>>>> >>>>>>>>>>>>> -Michael >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> See the screenshots attached. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>> --=20 >>>>>>> Sent from my laptop >>>>> >>>>> --=20 >>>>> Sent from my laptop >>>> >>>> >> >> --=20 >> Sent from my laptop >> >=20 --=20 Sent from my laptop --===============6822148208252360666==--