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.
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.
-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>