Hi Michael,
On 29/08/2024 15:53, Michael Tremer wrote:
Hello,
On 29 Aug 2024, at 14:36, Adolf Belka adolf.belka@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@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
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
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
but ping to a machine on the IPFire green network or to the IPFire green interface itself still ends up with 100% packet loss.
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@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@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