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 wrote: >>> >>> Hi Michael, >>> >>> On 29/08/2024 15:53, Michael Tremer wrote: >>>> Hello, >>>>> On 29 Aug 2024, at 14:36, Adolf Belka wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> On 29/08/2024 11:28, Michael Tremer wrote: >>>>>> Hello, >>>>>>> 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 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 >>>>>>>>> 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 >>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>> screen.png> >>>>>>>>>>> >>>>> >>>>> -- >>>>> Sent from my laptop >>> >>> -- >>> Sent from my laptop >> >> -- Sent from my laptop