From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Feedback on WG Date: Thu, 29 Aug 2024 11:28:51 +0200 Message-ID: <2994CE99-8171-40C6-8F19-FBB45F880D89@ipfire.org> In-Reply-To: <8ead5ecc-a635-446d-a0cf-22f299421c60@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8977288417556049472==" List-Id: --===============8977288417556049472== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 27 Aug 2024, at 13:09, Adolf Belka wrote: >=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 metric 6= 00 > 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 for your G= REEN subnet on the laptop pointing at wg0. > and the ipfire system has > ip route > default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 metric 10= 02 > 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 metric 10= 02 > 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 So I assume that from IPFire you can send packets to your laptop, but they do= n=E2=80=99t find their way back. -Michael > Regards, > Adolf. >> -Michael >>> On 26 Aug 2024, at 13:13, Adolf Belka wrote: >>>=20 >>> I tried out netcat to send some traffic through the tunnel. That confirme= d 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 l= an sent some data from /dev/zero through the tunnel, it was received at the o= ther end. >>>=20 >>>=20 >>> Setting the vm on the IPFire green lan into listening mode and sending th= e data from the laptop resulted in nothing being sent from the laptop and obv= iously 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 bit tied = up with DIY stuff in the house. >>>>>=20 >>>>> No problem... >>>>>=20 >>>>>> By manually importing the WG config file created I was able to success= fully connect from my laptop to my IPFire vm system. The WUI showed connected= . The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 w= hich is the green subnet on my vm system. However trying ping over the WG tun= nel gave failures for the IP of the vm machine, green1, and also for the gree= n 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 reso= lving of green1's FQDN to a local IP but tried to send it to my main red inte= rface with my ISP. >>>>>=20 >>>>> Can you try to ping from either side? The client the firewall and the f= irewall the client? That should work if the tunnel is up. >>>>=20 >>>> Tried again to ping from laptop to IPFire green lan, both the IPFire gre= en interface and a vm PC on the green lan. In both cases 100% packet loss. >>>>=20 >>>> 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 transmissi= on. >>>>=20 >>>> In all above tests I used IP's to remove any question about DNS resolvin= g. >>>>=20 >>>> So the ping seems to only be working in one direction. Let me know if th= ere 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 routing but n= ot sure what. >>>>>>=20 >>>>>> Minor points on the WUI. >>>>>=20 >>>>> I would like to have the thing working first before we spend any time o= n making the UI look nice, but you are raising very good points. >>>>>=20 >>>>>> 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 spa= ce is large enough to have the connected status word, giving much more room f= or the remark. >>>>>=20 >>>>> That should not be. No idea why that is, but I am sure that is not too = hard to fix. >>>>>=20 >>>>>> When the WG config file is created and you have the page with the QR c= ode, there is also a message about the WG config file only being shown this o= ne time as it contains private key material. The message is fine but the head= ing for the message is "Oops, something went wrong...". It should really be s= omething like "Information Note" or equivalent as it is not an actual error m= essage. >>>>>=20 >>>>> I think I created a little widget which I used somewhere else too and t= hen added the headline. It certainly does not fit here. >>>>>=20 >>>>> -Michael >>>>>=20 >>>>>>=20 >>>>>> See the screenshots attached. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>> >>>>>=20 --===============8977288417556049472==--