From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Feedback on WG Date: Fri, 06 Sep 2024 17:03:03 +0200 Message-ID: <68C1404A-2023-4E82-AD49-F067B258E8A7@ipfire.org> In-Reply-To: <2e70cbd5-ea29-479c-9665-fb0a27a92385@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0256622406432726029==" List-Id: --===============0256622406432726029== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just to update the list: We have been able to solve this problem off list. OpenVPN was greedy and didn=E2=80=99t allow WG packets to flow. > On 5 Sep 2024, at 11:53, Adolf Belka wrote: >=20 > Hi Michael, >=20 > I renamed the config file to wg0 and the interface was then labelled wg0 bu= t the ping from laptop (192.168.26.37) to IPFire with WG (192.168.200.254) st= ill lost all packets. >=20 > I have also found that the nmcli command line when creating a connection fr= om scratch as opposed to importing it has the commands to name the interface = and to name the connection so the two can be different. >=20 > Regards, > Adolf. >=20 >=20 > On 05/09/2024 11:27, Adolf Belka wrote: >> Hi Michael, >>=20 >> On 30/08/2024 17:43, Michael Tremer wrote: >>> Hello, >>>=20 >>>> On 29 Aug 2024, at 18:53, Adolf Belka wrote: >>>>=20 >>>> Hi Michael, >>>>=20 >>>> On 29/08/2024 15:53, Michael Tremer wrote: >>>>> Hello, >>>>>> On 29 Aug 2024, at 14:36, Adolf Belka wrote: >>>>>>=20 >>>>>> Hi Michael, >>>>>>=20 >>>>>> On 29/08/2024 11:28, Michael Tremer wrote: >>>>>>> Hello, >>>>>>>> On 27 Aug 2024, at 13:09, Adolf Belka wro= te: >>>>>>>>=20 >>>>>>>> Hi Michael, >>>>>>>>=20 >>>>>>>> On 27/08/2024 12:19, Michael Tremer wrote: >>>>>>>>> Could you show me the route tables of both systems, please? >>>>>>>>=20 >>>>>>>> The laptop has >>>>>>>> ip route >>>>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 m= etric 600 >>>>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37= metric 600 >>>>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50 >>>>>>>>=20 >>>>>>>> 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.10= metric 1002 >>>>>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10= 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 fo= r your GREEN subnet on the laptop pointing at wg0. >>>>>>=20 >>>>>> As I am having to import the wireguard conf file manually in the comma= nd 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. >>>>>>=20 >>>>>> 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 W= ireguard yet. So I had to just run >>>>>>=20 >>>>>> 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 c= are about the tunnel and nothing else. >>>> I tried using wg-quick to import the config and it came back with: >>>>=20 >>>> [#] 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 >>>=20 >>> 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 o= f =E2=80=9Ctethysvmwg=E2=80=9D. >>=20 >> That naming is nothing to do with the distro. >>=20 >> When doing the import with the nmcli command Network Manager takes the nam= e of the config file, in my case tethysvmwg, and uses that name for the inter= face. Whether that is what it should be doing I don't know. >>=20 >> Maybe I will try renaming the config file to wg0 and then import it and se= e what happens then. >>>=20 >>>>=20 >>>>>> where $CONF_FILE contains the path and name of the wireguard config fi= le that I downloaded from the IPFire Wireguard page. >>>>>>=20 >>>>>> All the stuff I have read about routing with regard to Wireguard is ju= st a bit to complicated for me to understand what I am supposed to do in my s= pecific 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 th= en it came back and said >>>>=20 >>>> Cannot find device "wg0" >>>>> What is =E2=80=9Cwg show wg0=E2=80=9D giving you? >>>>=20 >>>> That command came back with >>>>=20 >>>> Unable to access interface: No such device >>>>=20 >>>> so I ran ip address show and the wireguard interface on the laptop is na= med tethysvmwg which is the name of the conf file I got from IPFire because t= hat was the connection name I used. >>>>=20 >>>> So I then ran wg show tethysvmwg and it responded with >>>>=20 >>>> sudo wg show tethysvmwg >>>> interface: tethysvmwg >>>> public key: z48rDNDnbG5zH7yZWoY867FlqevmpfjktnlJAqdSIys=3D >>>> private key: (hidden) >>>> listening port: 59427 >>>>=20 >>>> 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 >>>=20 >>> So the tunnel is up. >>>=20 >>>> I then ran sudo ip route add 192.168.200.0/24 dev tethysvmwg >>>>=20 >>>> and ip route then showed >>>>=20 >>>> ip route >>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metri= c 600 >>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 met= ric 600 >>>> 192.168.200.0/24 dev tethysvmwg scope link >>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50 >>>=20 >>> 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 i= n the downloaded configuration file. >>=20 >> Here is the content of the config file that was generated >>=20 >> [Interface] >> PrivateKey =3D xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >> Address =3D 10.120.50.1 >> DNS =3D 192.168.200.254 >>=20 >> [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 >>=20 >> Maybe I didn't fill out the WG WUI page correctly. >>=20 >>>=20 >>> What IP address are you pinging from the firewall? >>=20 >> It is the IP address of the laptop and that is 192.168.26.37 >>=20 >> Regards, >> Adolf. >>=20 >>>=20 >>>> but ping to a machine on the IPFire green network or to the IPFire green= interface itself still ends up with 100% packet loss. >>>=20 >>> -Michael >>>=20 >>>>=20 >>>> Regards, >>>> Adolf. >>>>=20 >>>>> -Michael >>>>>>=20 >>>>>> If you can give some hints maybe, then I can have a go at getting it t= o work. >>>>>>>> and the ipfire system has >>>>>>>> ip route >>>>>>>> default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 me= tric 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 me= tric 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.2= 54 >>>>>>>> 192.168.240.0/24 dev orange0 proto kernel scope link src 192.168.240= .254 >>>>>>> So I assume that from IPFire you can send packets to your laptop, but= 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 ru= nning the wireguard server. >>>>>>=20 >>>>>> Regards, >>>>>> Adolf. >>>>>>=20 >>>>>>> -Michael >>>>>>>> Regards, >>>>>>>> Adolf. >>>>>>>>> -Michael >>>>>>>>>> On 26 Aug 2024, at 13:13, Adolf Belka w= rote: >>>>>>>>>>=20 >>>>>>>>>> I tried out netcat to send some traffic through the tunnel. That c= onfirmed that the tunnel is only working in one direction. >>>>>>>>>>=20 >>>>>>>>>> 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 a= t the other end. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Setting the vm on the IPFire green lan into listening mode and sen= ding the data from the laptop resulted in nothing being sent from the laptop = and obviously nothing received at the green vm. >>>>>>>>>>=20 >>>>>>>>>> So it is not just a ping issue. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Adolf. >>>>>>>>>>=20 >>>>>>>>>> On 26/08/2024 13:17, Adolf Belka wrote: >>>>>>>>>>> Hi Michael, >>>>>>>>>>>=20 >>>>>>>>>>> Getting back to testing out the WG. >>>>>>>>>>>=20 >>>>>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote: >>>>>>>>>>>> Hello Adolf, >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bi= t tied up with DIY stuff in the house. >>>>>>>>>>>>=20 >>>>>>>>>>>> No problem... >>>>>>>>>>>>=20 >>>>>>>>>>>>> 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 co= nnected. 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 the= WG tunnel gave failures for the IP of the vm machine, green1, and also for t= he green interface of the vm IPFire. >>>>>>>>>>>>=20 >>>>>>>>>>>> Okay, connecting should be nice and easy. However, you *should* = be able to transfer some data... >>>>>>>>>>>>=20 >>>>>>>>>>>>> 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 r= ed interface with my ISP. >>>>>>>>>>>>=20 >>>>>>>>>>>> Can you try to ping from either side? The client the firewall an= d the firewall the client? That should work if the tunnel is up. >>>>>>>>>>>=20 >>>>>>>>>>> Tried again to ping from laptop to IPFire green lan, both the IPF= ire green interface and a vm PC on the green lan. In both cases 100% packet l= oss. >>>>>>>>>>>=20 >>>>>>>>>>> I then tried doing the ping from the vm machine on the green IPFi= re lan to the laptop, as you suggested and in this case I got 100% packet tra= nsmission. >>>>>>>>>>>=20 >>>>>>>>>>> In all above tests I used IP's to remove any question about DNS r= esolving. >>>>>>>>>>>=20 >>>>>>>>>>> So the ping seems to only be working in one direction. Let me kno= w if there are any other tests or checks I should do based on this result. >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Adolf. >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> So something appears to be missing or incorrect with the routin= g but not sure what. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Minor points on the WUI. >>>>>>>>>>>>=20 >>>>>>>>>>>> I would like to have the thing working first before we spend any= time on making the UI look nice, but you are raising very good points. >>>>>>>>>>>>=20 >>>>>>>>>>>>> When disconnected the status section that is coloured red is hu= ge and the space for the remark is very small but when connected then the sta= tus space is large enough to have the connected status word, giving much more= room for the remark. >>>>>>>>>>>>=20 >>>>>>>>>>>> That should not be. No idea why that is, but I am sure that is n= ot too hard to fix. >>>>>>>>>>>>=20 >>>>>>>>>>>>> When the WG config file is created and you have the page with t= he QR code, there is also a message about the WG config file only being shown= this one time as it contains private key material. The message is fine but t= he heading for the message is "Oops, something went wrong...". It should real= ly be something like "Information Note" or equivalent as it is not an actual = error message. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think I created a little widget which I used somewhere else to= o and then added the headline. It certainly does not fit here. >>>>>>>>>>>>=20 >>>>>>>>>>>> -Michael >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> See the screenshots attached. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Adolf. >>>>>>>>>>>>> >>>>>>>>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Sent from my laptop >>>>=20 >>>> --=20 >>>> Sent from my laptop >>>=20 >>>=20 >=20 > --=20 > Sent from my laptop >=20 --===============0256622406432726029==--