Re: Feedback on WG

[Adolf Belka <adolf.belka@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 13043 bytes --]

Hi Michael,

I renamed the config file to wg0 and the interface was then labelled wg0 
but the ping from laptop (192.168.26.37) to IPFire with WG 
(192.168.200.254) still lost all packets.

I have also found that the nmcli command line when creating a connection 
from 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 <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi Michael,
>>>
>>> On 29/08/2024 15:53, Michael Tremer wrote:
>>>> Hello,
>>>>> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> On 29/08/2024 11:28, Michael Tremer wrote:
>>>>>> Hello,
>>>>>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> 
>>>>>>> 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 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.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 GREEN subnet on the laptop pointing at wg0.
>>>>>
>>>>> As I am having to import the wireguard conf file manually in the 
>>>>> command 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’t 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 “tethysvmwg”.
>
> That naming is nothing to do with the distro.
>
> When doing the import with the nmcli command Network Manager takes the 
> name of the config file, in my case tethysvmwg, and uses that name for 
> the interface. 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 see what happens then.
>>
>>>
>>>>> where $CONF_FILE contains the path and name of the wireguard 
>>>>> config file that I downloaded from the IPFire Wireguard page.
>>>>>
>>>>> All the stuff I have read about routing with regard to Wireguard 
>>>>> is just 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 then it came back and said
>>>
>>> Cannot find device "wg0"
>>>> What is “wg show wg0” 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 named 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=
>>>   private key: (hidden)
>>>   listening port: 59427
>>>
>>> peer: d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
>>>   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 
>>> metric 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 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 = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Address = 10.120.50.1
> DNS = 192.168.200.254
>
> [Peer]
> Endpoint = ipfire.local.domain.org:51820
> PublicKey = d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
> PresharedKey = yyyyyyyyyyyyyyyyyyyyyyyyyy
> AllowedIPs = 192.168.200.0/24
> PersistentKeepalive = 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 
>>> green 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 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
>>>>>> 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 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
>>>>>> So I assume that from IPFire you can send packets to your laptop, 
>>>>>> but they don’t 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 running the wireguard server.
>>>>>
>>>>> Regards,
>>>>> Adolf.
>>>>>
>>>>>> -Michael
>>>>>>> Regards,
>>>>>>> Adolf.
>>>>>>>> -Michael
>>>>>>>>> On 26 Aug 2024, at 13:13, Adolf Belka <adolf.belka(a)ipfire.org> 
>>>>>>>>> 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 
>>>>>>>>> sending 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 
>>>>>>>>>>>> <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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 successfully 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 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 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 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 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 
>>>>>>>>>> IPFire lan to the laptop, as you suggested and in this case I 
>>>>>>>>>> got 100% packet transmission.
>>>>>>>>>>
>>>>>>>>>> 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 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 
>>>>>>>>>>>> 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 space 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 heading 
>>>>>>>>>>>> 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.
>>>>>>>>>>>> <Disconnected WUI screen.png><Connected WUI 
>>>>>>>>>>>> screen.png><Error message when WG config file provided..png>
>>>>>>>>>>>
>>>>>
>>>>> -- 
>>>>> Sent from my laptop
>>>
>>> -- 
>>> Sent from my laptop
>>
>>

-- 
Sent from my laptop