Hi Michael,
Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
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.
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.
So something appears to be missing or incorrect with the routing but not sure what.
Minor points on the WUI.
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.
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.
See the screenshots attached.
Regards,
Adolf.
Hi Michael,
Further feedback on testing with my android phone. I used the QR code and it worked. I got a connected tunnel but again ping was not working. All packets were lost.
Also when I tried to browse to ipfire.org it responded with "www.ipfire.org's DNS address could not be found. Diagnosing the problem" but nothing further happened.
Browsing is working fine on any of the vm machines on the vm green network that the tunnel is connected to.
Interesting result with the WUI, when there is one client connected and the other disconnected. The status box then stays as very large leaving hardly any room for the remark so it has to go to multi lines.
Regards,
Adolf.
On 19/08/2024 13: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.
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.
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.
So something appears to be missing or incorrect with the routing but not sure what.
Minor points on the WUI.
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.
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.
See the screenshots attached.
Regards,
Adolf.
Hello again,
On 19 Aug 2024, at 12:32, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
Further feedback on testing with my android phone. I used the QR code and it worked. I got a connected tunnel but again ping was not working. All packets were lost.
Not good.
What did you use for the client pool? Do you maybe have an address conflict?
Also when I tried to browse to ipfire.org it responded with "www.ipfire.org's DNS address could not be found. Diagnosing the problem" but nothing further happened.
Browsing is working fine on any of the vm machines on the vm green network that the tunnel is connected to.
Interesting result with the WUI, when there is one client connected and the other disconnected. The status box then stays as very large leaving hardly any room for the remark so it has to go to multi lines.
Regards,
Adolf.
On 19/08/2024 13: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.
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.
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.
So something appears to be missing or incorrect with the routing but not sure what.
Minor points on the WUI.
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.
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.
See the screenshots attached.
Regards,
Adolf.
<One Connected one disconnected WUI screen.png>
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.
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>
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>
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>
Could you show me the route tables of both systems, please?
-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>
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
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.
-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>
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>
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"
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.
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>
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.
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 wg0
Assuming that your GREEN network is 192.168.0.0./24.
What is “wg show wg0” giving you?
-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
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
Hello,
On 29 Aug 2024, at 18:53, Adolf Belka adolf.belka@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@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
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”.
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.
What IP address are you pinging from the firewall?
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@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
-- Sent from my laptop
Hi Michael,
On 30/08/2024 17:43, Michael Tremer wrote:
Hello,
On 29 Aug 2024, at 18:53, Adolf Belka adolf.belka@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@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
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@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
-- Sent from my laptop
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@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@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
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@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
-- Sent from my laptop
Just to update the list: We have been able to solve this problem off list.
OpenVPN was greedy and didn’t allow WG packets to flow.
On 5 Sep 2024, at 11:53, Adolf Belka adolf.belka@ipfire.org wrote:
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@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@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
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@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
-- Sent from my laptop
-- Sent from my laptop
Hi All,
I have modified the subnet for wireguard and enabled the openvpn n2n connection again.
I then made two new connections, one for my laptop and the for my android phone.
In both cases the connection was successfully made and ping packets were successfully sent and received in both directions.
Also can now browse etc through the tunnel.
I will now look at testing out the new changes made yesterday. Are these available as an iso that I can install or do I need to clone the changes into a repo on my system and build it?
Regards,
Adolf.
On 06/09/2024 17:03, Michael Tremer wrote:
Just to update the list: We have been able to solve this problem off list.
OpenVPN was greedy and didn’t allow WG packets to flow.
On 5 Sep 2024, at 11:53, Adolf Belka adolf.belka@ipfire.org wrote:
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@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@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
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@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
-- Sent from my laptop
-- Sent from my laptop
-
Adolf Belka -
Michael Tremer