From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Feedback on WG Date: Thu, 29 Aug 2024 14:36:31 +0200 Message-ID: <8997c945-d6bd-42eb-a112-d5dac12e7f55@ipfire.org> In-Reply-To: <2994CE99-8171-40C6-8F19-FBB45F880D89@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7835432142356306258==" List-Id: --===============7835432142356306258== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 29/08/2024 11:28, Michael Tremer wrote: > Hello, >=20 >> On 27 Aug 2024, at 13:09, Adolf Belka wrote: >> >> 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.37 metri= c 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.10 metri= c 1002 >> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metri= c 1002 >=20 > So it looks like the routes for Wireguard are missing here. >=20 > Assuming that the interface is called wg0, there should be a route for your= GREEN subnet on the laptop pointing at wg0. As I am having to import the wireguard conf file manually in the command=20 line, maybe I am also expected to set my own routes up on my laptop but=20 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=20 deals with everything but Network Manager cannot do this via the GUI for=20 Wireguard yet. So I had to just run nmcli connection import type wireguard file "$CONF_FILE" where $CONF_FILE contains the path and name of the wireguard config file=20 that I downloaded from the IPFire Wireguard page. All the stuff I have read about routing with regard to Wireguard is just=20 a bit to complicated for me to understand what I am supposed to do in my=20 specific case. If you can give some hints maybe, then I can have a go at getting it to=20 work. >=20 >> and the ipfire system has >> ip route >> default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 metric 1= 002 >> 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 >=20 > This is the opposite route. >=20 >> 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 metric 1= 002 >> 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.240.254 >=20 > 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=20 running the wireguard server. Regards, Adolf. >=20 > -Michael >=20 >> 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 confirm= ed 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 sending t= he data from the laptop resulted in nothing being sent from the laptop and ob= viously 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 wrot= e: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied= up with DIY stuff in the house. >>>>>> >>>>>> No problem... >>>>>> >>>>>>> By manually importing the WG config file created I was able to succes= sfully connect from my laptop to my IPFire vm system. The WUI showed connecte= d. 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 tu= nnel gave failures for the IP of the vm machine, green1, and also for the gre= en interface of the vm IPFire. >>>>>> >>>>>> Okay, connecting should be nice and easy. However, you *should* be abl= e to transfer some data... >>>>>> >>>>>>> Trying to ping with the FQDN for the green1 system resulted in no res= olving of green1's FQDN to a local IP but tried to send it to my main red int= erface with my ISP. >>>>>> >>>>>> Can you try to ping from either side? The client the firewall and the = firewall the client? That should work if the tunnel is up. >>>>> >>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire gr= een 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 IPFire lan= to the laptop, as you suggested and in this case I got 100% packet transmiss= ion. >>>>> >>>>> In all above tests I used IP's to remove any question about DNS resolvi= ng. >>>>> >>>>> So the ping seems to only be working in one direction. Let me know if t= here 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 routing but = not sure what. >>>>>>> >>>>>>> Minor points on the WUI. >>>>>> >>>>>> 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. >>>>>> >>>>>>> When disconnected the status section that is coloured red is huge and= the space for the remark is very small but when connected then the status sp= ace is large enough to have the connected status word, giving much more 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 shown this = one time as it contains private key material. The message is fine but the hea= ding for the message is "Oops, something went wrong...". It should really 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 too and = then added the headline. It certainly does not fit here. >>>>>> >>>>>> -Michael >>>>>> >>>>>>> >>>>>>> See the screenshots attached. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Adolf. >>>>>>> >>>>>> >=20 --=20 Sent from my laptop --===============7835432142356306258==--