From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Feedback on WG Date: Tue, 27 Aug 2024 13:09:37 +0200 Message-ID: <8ead5ecc-a635-446d-a0cf-22f299421c60@ipfire.org> In-Reply-To: <937303A2-EDA0-4207-B553-D7BC01B5550C@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2340865467380501873==" List-Id: --===============2340865467380501873== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 metric 6= 00 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 metric 1= 002 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1= 002 and the ipfire system has ip route default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 metric 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 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 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.240.254 Regards, Adolf. >=20 > -Michael >=20 >> 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 la= n sent some data from /dev/zero through the tunnel, it was received at the ot= her end. >> >> >> Setting the vm on the IPFire green lan into listening mode and sending the= data from the laptop resulted in nothing being sent from the laptop and obvi= ously 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 bit tied u= p with DIY stuff in the house. >>>> >>>> No problem... >>>> >>>>> By manually importing the WG config file created I was able to successf= ully 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 wh= ich is the green subnet on my vm system. However trying ping over the WG tunn= el 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 resol= ving of green1's FQDN to a local IP but tried to send it to my main red inter= face with my ISP. >>>> >>>> Can you try to ping from either side? The client the firewall and the fi= rewall the client? That should work if the tunnel is up. >>> >>> Tried again to ping from laptop to IPFire green lan, both the IPFire gree= n 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 t= o the laptop, as you suggested and in this case I got 100% packet transmissio= n. >>> >>> 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 know if the= re 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 no= t 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 t= he space for the remark is very small but when connected then the status spac= e is large enough to have the connected status word, giving much more room fo= r the remark. >>>> >>>> That should not be. No idea why that is, but I am sure that is not too h= ard to fix. >>>> >>>>> When the WG config file is created and you have the page with the QR co= de, there is also a message about the WG config file only being shown this on= e time as it contains private key material. The message is fine but the headi= ng for the message is "Oops, something went wrong...". It should really be so= mething like "Information Note" or equivalent as it is not an actual error me= ssage. >>>> >>>> I think I created a little widget which I used somewhere else too and th= en added the headline. It certainly does not fit here. >>>> >>>> -Michael >>>> >>>>> >>>>> See the screenshots attached. >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>> >=20 --===============2340865467380501873==--