Re: Feedback on WG

Re: Feedback on WG

[Michael Tremer]

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

Hello again,

> On 19 Aug 2024, at 12:32, Adolf Belka <adolf.belka(a)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>

Re: Feedback on WG

[Michael Tremer]

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

Hello Adolf,

> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.

No problem...

> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0  which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.

Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...

> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.

Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.

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

Re: Feedback on WG

[Adolf Belka]

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

Hi Michael,

Getting back to testing out the WG.

On 21/08/2024 16:23, Michael Tremer wrote:
> Hello Adolf,
> 
>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
> 
> No problem...
> 
>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0  which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
> 
> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
> 
>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
> 
> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.

Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.

I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.

In all above tests I used IP's to remove any question about DNS resolving.

So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.

Regards,
Adolf.

> 
>> So something appears to be missing or incorrect with the routing but not sure what.
>>
>> Minor points on the WUI.
> 
> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
> 
>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
> 
> That should not be. No idea why that is, but I am sure that is not too hard to fix.
> 
>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
> 
> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
> 
> -Michael
> 
>>
>> See the screenshots attached.
>>
>> Regards,
>>
>> Adolf.
>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
> 

Re: Feedback on WG

[Adolf Belka]

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

I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.

If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.


Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.

So it is not just a ping issue.

Regards,

Adolf.

On 26/08/2024 13:17, Adolf Belka wrote:
> Hi Michael,
>
> Getting back to testing out the WG.
>
> On 21/08/2024 16:23, Michael Tremer wrote:
>> Hello Adolf,
>>
>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi Michael,
>>>
>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>
>> No problem...
>>
>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>
>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>
>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>
>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>
> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>
> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>
> In all above tests I used IP's to remove any question about DNS resolving.
>
> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>
> Regards,
> Adolf.
>
>>
>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>
>>> Minor points on the WUI.
>>
>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>
>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>
>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>
>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>
>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>
>> -Michael
>>
>>>
>>> See the screenshots attached.
>>>
>>> Regards,
>>>
>>> Adolf.
>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>

Re: Feedback on WG

[Michael Tremer]

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

Could you show me the route tables of both systems, please?

-Michael

> On 26 Aug 2024, at 13:13, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
> 
> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
> 
> 
> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
> 
> So it is not just a ping issue.
> 
> Regards,
> 
> Adolf.
> 
> On 26/08/2024 13:17, Adolf Belka wrote:
>> Hi Michael,
>> 
>> Getting back to testing out the WG.
>> 
>> On 21/08/2024 16:23, Michael Tremer wrote:
>>> Hello Adolf,
>>> 
>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>> 
>>> No problem...
>>> 
>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>> 
>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>> 
>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>> 
>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>> 
>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>> 
>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>> 
>> In all above tests I used IP's to remove any question about DNS resolving.
>> 
>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>> 
>> Regards,
>> Adolf.
>> 
>>> 
>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>> 
>>>> Minor points on the WUI.
>>> 
>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>> 
>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>> 
>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>> 
>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>> 
>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>> 
>>> -Michael
>>> 
>>>> 
>>>> See the screenshots attached.
>>>> 
>>>> Regards,
>>>> 
>>>> Adolf.
>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>> 

Re: Feedback on WG

[Adolf Belka]

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

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(a)ipfire.org> wrote:
>>
>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>
>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>
>>
>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>
>> So it is not just a ping issue.
>>
>> Regards,
>>
>> Adolf.
>>
>> On 26/08/2024 13:17, Adolf Belka wrote:
>>> Hi Michael,
>>>
>>> Getting back to testing out the WG.
>>>
>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>> Hello Adolf,
>>>>
>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>
>>>> No problem...
>>>>
>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>
>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>
>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>
>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>
>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>
>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>
>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>
>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>
>>> Regards,
>>> Adolf.
>>>
>>>>
>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>
>>>>> Minor points on the WUI.
>>>>
>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>
>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>
>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>
>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>
>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>
>>>> -Michael
>>>>
>>>>>
>>>>> See the screenshots attached.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Adolf.
>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>
> 

Re: Feedback on WG

[Michael Tremer]

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

Hello,

> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 27/08/2024 12:19, Michael Tremer wrote:
>> Could you show me the route tables of both systems, please?
> 
> The laptop has
> ip route
> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
> 
> and the vm pc on the IPFire green lan has
> ip route
> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002

So it looks like the routes for Wireguard are missing here.

Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.

> 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(a)ipfire.org> wrote:
>>> 
>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>> 
>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>> 
>>> 
>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>> 
>>> So it is not just a ping issue.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>> Hi Michael,
>>>> 
>>>> Getting back to testing out the WG.
>>>> 
>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>> Hello Adolf,
>>>>> 
>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>> 
>>>>>> Hi Michael,
>>>>>> 
>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>> 
>>>>> No problem...
>>>>> 
>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>> 
>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>> 
>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>> 
>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>> 
>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>> 
>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>> 
>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>> 
>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>> 
>>>> Regards,
>>>> Adolf.
>>>> 
>>>>> 
>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>> 
>>>>>> Minor points on the WUI.
>>>>> 
>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>> 
>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>> 
>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>> 
>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>> 
>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>> 
>>>>> -Michael
>>>>> 
>>>>>> 
>>>>>> See the screenshots attached.
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Adolf.
>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>> 

Re: Feedback on WG

[Adolf Belka]

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

Hi Michael,

On 29/08/2024 11:28, Michael Tremer wrote:
> Hello,
> 
>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 27/08/2024 12:19, Michael Tremer wrote:
>>> Could you show me the route tables of both systems, please?
>>
>> The laptop has
>> ip route
>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>
>> and the vm pc on the IPFire green lan has
>> ip route
>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002
> 
> So it looks like the routes for Wireguard are missing here.
> 
> Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.

As I am having to import the wireguard conf file manually in the command 
line, maybe I am also expected to set my own routes up on my laptop but 
I am not sure what I should set the route command to.

Normally I do an import of a VPN profile into Network Manager GUI and it 
deals with everything but Network Manager cannot do this via the GUI for 
Wireguard yet. So I had to just run

nmcli connection import type wireguard file "$CONF_FILE"

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(a)ipfire.org> wrote:
>>>>
>>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>>>
>>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>>>
>>>>
>>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>>>
>>>> So it is not just a ping issue.
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>> Hi Michael,
>>>>>
>>>>> Getting back to testing out the WG.
>>>>>
>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>> Hello Adolf,
>>>>>>
>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>>>
>>>>>> No problem...
>>>>>>
>>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>>>
>>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>>>
>>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>>>
>>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>>>
>>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>>>
>>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>>>
>>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>>>
>>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>>>
>>>>> Regards,
>>>>> Adolf.
>>>>>
>>>>>>
>>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>>>
>>>>>>> Minor points on the WUI.
>>>>>>
>>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>>>
>>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>>>
>>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>>>
>>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>>>
>>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>>>
>>>>>> -Michael
>>>>>>
>>>>>>>
>>>>>>> See the screenshots attached.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Adolf.
>>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>>>
> 

-- 
Sent from my laptop

Re: Feedback on WG

[Michael Tremer]

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

Hello,

> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 29/08/2024 11:28, Michael Tremer wrote:
>> Hello,
>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> On 27/08/2024 12:19, Michael Tremer wrote:
>>>> Could you show me the route tables of both systems, please?
>>> 
>>> The laptop has
>>> ip route
>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>> 
>>> and the vm pc on the IPFire green lan has
>>> ip route
>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002
>> So it looks like the routes for Wireguard are missing here.
>> Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.
> 
> As I am having to import the wireguard conf file manually in the command line, maybe I am also expected to set my own routes up on my laptop but I am not sure what I should set the route command to.
> 
> Normally I do an import of a VPN profile into Network Manager GUI and it deals with everything but Network Manager cannot do this via the GUI for Wireguard yet. So I had to just run
> 
> nmcli connection import type wireguard file "$CONF_FILE"

NetworkManager should configure everything for you. That is its job in the end.

If you use the wg command to import the configuration, I don’t know whether it is creating routes or not. It could, but it might also just care about the tunnel and nothing else.

> 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(a)ipfire.org> wrote:
>>>>> 
>>>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>>>> 
>>>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>>>> 
>>>>> 
>>>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>>>> 
>>>>> So it is not just a ping issue.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Adolf.
>>>>> 
>>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>>> Hi Michael,
>>>>>> 
>>>>>> Getting back to testing out the WG.
>>>>>> 
>>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>>> Hello Adolf,
>>>>>>> 
>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>> 
>>>>>>>> Hi Michael,
>>>>>>>> 
>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>>>> 
>>>>>>> No problem...
>>>>>>> 
>>>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>>>> 
>>>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>>>> 
>>>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>>>> 
>>>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>>>> 
>>>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>>>> 
>>>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>>>> 
>>>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>>>> 
>>>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>>>> 
>>>>>> Regards,
>>>>>> Adolf.
>>>>>> 
>>>>>>> 
>>>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>>>> 
>>>>>>>> Minor points on the WUI.
>>>>>>> 
>>>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>>>> 
>>>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>>>> 
>>>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>>>> 
>>>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>>>> 
>>>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>>>> 
>>>>>>> -Michael
>>>>>>> 
>>>>>>>> 
>>>>>>>> See the screenshots attached.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> Adolf.
>>>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>>>> 
> 
> -- 
> Sent from my laptop

Re: Feedback on WG

[Adolf Belka]

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

Hi Michael,

On 29/08/2024 15:53, Michael Tremer wrote:
> Hello,
> 
>> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 29/08/2024 11:28, Michael Tremer wrote:
>>> Hello,
>>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> On 27/08/2024 12:19, Michael Tremer wrote:
>>>>> Could you show me the route tables of both systems, please?
>>>>
>>>> The laptop has
>>>> ip route
>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>>>
>>>> and the vm pc on the IPFire green lan has
>>>> ip route
>>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002
>>> So it looks like the routes for Wireguard are missing here.
>>> Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.
>>
>> As I am having to import the wireguard conf file manually in the command line, maybe I am also expected to set my own routes up on my laptop but I am not sure what I should set the route command to.
>>
>> Normally I do an import of a VPN profile into Network Manager GUI and it deals with everything but Network Manager cannot do this via the GUI for Wireguard yet. So I had to just run
>>
>> nmcli connection import type wireguard file "$CONF_FILE"
> 
> NetworkManager should configure everything for you. That is its job in the end.
> 
> If you use the wg command to import the configuration, I don’t know whether it is creating routes or not. It could, but it might also just care about the tunnel and nothing else.
I tried using wg-quick to import the config and it came back with:

[#] ip link add tethysvmwg type wireguard
[#] wg setconf tethysvmwg /dev/fd/63
[#] ip -4 address add 10.120.50.1 dev tethysvmwg
[#] ip link set mtu 1420 up dev tethysvmwg
[#] resolvconf -a tethysvmwg -m 0 -x
/usr/bin/wg-quick: line 32: resolvconf: command not found
[#] ip link delete dev tethysvmwg

> 
>> 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(a)ipfire.org> wrote:
>>>>>>
>>>>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>>>>>
>>>>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>>>>>
>>>>>>
>>>>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>>>>>
>>>>>> So it is not just a ping issue.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Adolf.
>>>>>>
>>>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> Getting back to testing out the WG.
>>>>>>>
>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>>>> Hello Adolf,
>>>>>>>>
>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>
>>>>>>>>> Hi Michael,
>>>>>>>>>
>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>>>>>
>>>>>>>> No problem...
>>>>>>>>
>>>>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>>>>>
>>>>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>>>>>
>>>>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>>>>>
>>>>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>>>>>
>>>>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>>>>>
>>>>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>>>>>
>>>>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>>>>>
>>>>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Adolf.
>>>>>>>
>>>>>>>>
>>>>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>>>>>
>>>>>>>>> Minor points on the WUI.
>>>>>>>>
>>>>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>>>>>
>>>>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>>>>>
>>>>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>>>>>
>>>>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>>>>>
>>>>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>>>>>
>>>>>>>> -Michael
>>>>>>>>
>>>>>>>>>
>>>>>>>>> See the screenshots attached.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Adolf.
>>>>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>>>>>
>>
>> -- 
>> Sent from my laptop
> 
> 

-- 
Sent from my laptop

Re: Feedback on WG

[Michael Tremer]

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

Hello,

> On 29 Aug 2024, at 18:53, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 29/08/2024 15:53, Michael Tremer wrote:
>> Hello,
>>> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> On 29/08/2024 11:28, Michael Tremer wrote:
>>>> Hello,
>>>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> On 27/08/2024 12:19, Michael Tremer wrote:
>>>>>> Could you show me the route tables of both systems, please?
>>>>> 
>>>>> The laptop has
>>>>> ip route
>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>>>> 
>>>>> and the vm pc on the IPFire green lan has
>>>>> ip route
>>>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
>>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002
>>>> So it looks like the routes for Wireguard are missing here.
>>>> Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.
>>> 
>>> As I am having to import the wireguard conf file manually in the command line, maybe I am also expected to set my own routes up on my laptop but I am not sure what I should set the route command to.
>>> 
>>> Normally I do an import of a VPN profile into Network Manager GUI and it deals with everything but Network Manager cannot do this via the GUI for Wireguard yet. So I had to just run
>>> 
>>> nmcli connection import type wireguard file "$CONF_FILE"
>> NetworkManager should configure everything for you. That is its job in the end.
>> If you use the wg command to import the configuration, I don’t know whether it is creating routes or not. It could, but it might also just care about the tunnel and nothing else.
> I tried using wg-quick to import the config and it came back with:
> 
> [#] ip link add tethysvmwg type wireguard
> [#] wg setconf tethysvmwg /dev/fd/63
> [#] ip -4 address add 10.120.50.1 dev tethysvmwg
> [#] ip link set mtu 1420 up dev tethysvmwg
> [#] resolvconf -a tethysvmwg -m 0 -x
> /usr/bin/wg-quick: line 32: resolvconf: command not found
> [#] ip link delete dev tethysvmwg

Well, I assumed the interface would be called wg0, but it seems that the your distro decided to go with the easy to pronounce and really catchy name of “tethysvmwg”.

> 
>>> 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(a)ipfire.org> wrote:
>>>>>>> 
>>>>>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>>>>>> 
>>>>>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>>>>>> 
>>>>>>> 
>>>>>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>>>>>> 
>>>>>>> So it is not just a ping issue.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Adolf.
>>>>>>> 
>>>>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>>>>> Hi Michael,
>>>>>>>> 
>>>>>>>> Getting back to testing out the WG.
>>>>>>>> 
>>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>>>>> Hello Adolf,
>>>>>>>>> 
>>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Michael,
>>>>>>>>>> 
>>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>>>>>> 
>>>>>>>>> No problem...
>>>>>>>>> 
>>>>>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>>>>>> 
>>>>>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>>>>>> 
>>>>>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>>>>>> 
>>>>>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>>>>>> 
>>>>>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>>>>>> 
>>>>>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>>>>>> 
>>>>>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>>>>>> 
>>>>>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Adolf.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>>>>>> 
>>>>>>>>>> Minor points on the WUI.
>>>>>>>>> 
>>>>>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>>>>>> 
>>>>>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>>>>>> 
>>>>>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>>>>>> 
>>>>>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>>>>>> 
>>>>>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>>>>>> 
>>>>>>>>> -Michael
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> See the screenshots attached.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> 
>>>>>>>>>> Adolf.
>>>>>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>>>>>> 
>>> 
>>> -- 
>>> Sent from my laptop
> 
> -- 
> Sent from my laptop

Re: Feedback on WG

[Adolf Belka]

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

Hi Michael,

On 30/08/2024 17:43, Michael Tremer wrote:
> Hello,
> 
>> On 29 Aug 2024, at 18:53, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 29/08/2024 15:53, Michael Tremer wrote:
>>> Hello,
>>>> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> On 29/08/2024 11:28, Michael Tremer wrote:
>>>>> Hello,
>>>>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> On 27/08/2024 12:19, Michael Tremer wrote:
>>>>>>> Could you show me the route tables of both systems, please?
>>>>>>
>>>>>> The laptop has
>>>>>> ip route
>>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>>>>>
>>>>>> and the vm pc on the IPFire green lan has
>>>>>> ip route
>>>>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
>>>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002
>>>>> So it looks like the routes for Wireguard are missing here.
>>>>> Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.
>>>>
>>>> As I am having to import the wireguard conf file manually in the command line, maybe I am also expected to set my own routes up on my laptop but I am not sure what I should set the route command to.
>>>>
>>>> Normally I do an import of a VPN profile into Network Manager GUI and it deals with everything but Network Manager cannot do this via the GUI for Wireguard yet. So I had to just run
>>>>
>>>> nmcli connection import type wireguard file "$CONF_FILE"
>>> NetworkManager should configure everything for you. That is its job in the end.
>>> If you use the wg command to import the configuration, I don’t know whether it is creating routes or not. It could, but it might also just care about the tunnel and nothing else.
>> I tried using wg-quick to import the config and it came back with:
>>
>> [#] ip link add tethysvmwg type wireguard
>> [#] wg setconf tethysvmwg /dev/fd/63
>> [#] ip -4 address add 10.120.50.1 dev tethysvmwg
>> [#] ip link set mtu 1420 up dev tethysvmwg
>> [#] resolvconf -a tethysvmwg -m 0 -x
>> /usr/bin/wg-quick: line 32: resolvconf: command not found
>> [#] ip link delete dev tethysvmwg
> 
> Well, I assumed the interface would be called wg0, but it seems that the your distro decided to go with the easy to pronounce and really catchy name of “tethysvmwg”.

That naming is nothing to do with the distro.

When doing the import with the nmcli command Network Manager takes the name of the config file, in my case tethysvmwg, and uses that name for the interface. Whether that is what it should be doing I don't know.

Maybe I will try renaming the config file to wg0 and then import it and see what happens then.
> 
>>
>>>> where $CONF_FILE contains the path and name of the wireguard config file that I downloaded from the IPFire Wireguard page.
>>>>
>>>> All the stuff I have read about routing with regard to Wireguard is just a bit to complicated for me to understand what I am supposed to do in my specific case.
>>> You just need a route to the GREEN network on your firewall like so:
>>>    ip route add 192.168.0.0/24 dev wg >
>>> Assuming that your GREEN network is 192.168.0.0./24.
>> If by green network you mean the green network on my IPFire vm system then it came back and said
>>
>> Cannot find device "wg0"
>>> What is “wg show wg0” giving you?
>>
>> That command came back with
>>
>> Unable to access interface: No such device
>>
>> so I ran ip address show and the wireguard interface on the laptop is named tethysvmwg which is the name of the conf file I got from IPFire because that was the connection name I used.
>>
>> So I then ran wg show tethysvmwg and it responded with
>>
>> sudo wg show tethysvmwg
>> interface: tethysvmwg
>>   public key: z48rDNDnbG5zH7yZWoY867FlqevmpfjktnlJAqdSIys=
>>   private key: (hidden)
>>   listening port: 59427
>>
>> peer: d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
>>   preshared key: (hidden)
>>   endpoint: 192.168.26.200:51820
>>   allowed ips: 192.168.200.0/24
>>   latest handshake: 1 minute, 39 seconds ago
>>   transfer: 348 B received, 7.21 KiB sent
>>   persistent keepalive: every 25 seconds
> 
> So the tunnel is up.
> 
>> I then ran sudo ip route add 192.168.200.0/24 dev tethysvmwg
>>
>> and ip route then showed
>>
>> ip route
>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>> 192.168.200.0/24 dev tethysvmwg scope link
>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
> 
> It looks like that route was already there then, but it seems that there might not be an IP address on the tethysvmwg interface? There should be one in the downloaded configuration file.

Here is the content of the config file that was generated

[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.120.50.1
DNS = 192.168.200.254

[Peer]
Endpoint = ipfire.local.domain.org:51820
PublicKey = d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
PresharedKey = yyyyyyyyyyyyyyyyyyyyyyyyyy
AllowedIPs = 192.168.200.0/24
PersistentKeepalive = 25

Maybe I didn't fill out the WG WUI page correctly.

> 
> What IP address are you pinging from the firewall?

It is the IP address of the laptop and that is 192.168.26.37

Regards,
Adolf.

> 
>> but ping to a machine on the IPFire green network or to the IPFire green interface itself still ends up with 100% packet loss.
> 
> -Michael
> 
>>
>> Regards,
>> Adolf.
>>
>>> -Michael
>>>>
>>>> If you can give some hints maybe, then I can have a go at getting it to work.
>>>>>> and the ipfire system has
>>>>>> ip route
>>>>>> default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 metric 1002
>>>>>> 10.110.30.0/24 via 10.110.130.2 dev tun0
>>>>>> 10.110.130.0/24 via 10.110.130.2 dev tun0
>>>>>> 10.110.130.2 dev tun0 proto kernel scope link src 10.110.130.1
>>>>>> 10.120.50.0/24 dev wg0 scope link
>>>>> This is the opposite route.
>>>>>> 10.120.50.2 dev tun1 proto kernel scope link src 10.120.50.1
>>>>>> 192.168.26.0/24 dev red0 proto dhcp scope link src 192.168.26.200 metric 1002
>>>>>> 192.168.120.0/24 via 10.120.50.2 dev tun1
>>>>>> 192.168.200.0/24 dev green0 proto kernel scope link src 192.168.200.254
>>>>>> 192.168.220.0/24 dev blue0 proto kernel scope link src 192.168.220.254
>>>>>> 192.168.240.0/24 dev orange0 proto kernel scope link src 192.168.240.254
>>>>> So I assume that from IPFire you can send packets to your laptop, but they don’t find their way back.
>>>> I didn't try the ping from IPFire. I will do that and report back.
>>>> I just tried the ping from a machine on the green lan of the IPFire running the wireguard server.
>>>>
>>>> Regards,
>>>> Adolf.
>>>>
>>>>> -Michael
>>>>>> Regards,
>>>>>> Adolf.
>>>>>>> -Michael
>>>>>>>> On 26 Aug 2024, at 13:13, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>
>>>>>>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>>>>>>>
>>>>>>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>>>>>>>
>>>>>>>>
>>>>>>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>>>>>>>
>>>>>>>> So it is not just a ping issue.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Adolf.
>>>>>>>>
>>>>>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>>>>>> Hi Michael,
>>>>>>>>>
>>>>>>>>> Getting back to testing out the WG.
>>>>>>>>>
>>>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>>>>>> Hello Adolf,
>>>>>>>>>>
>>>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Michael,
>>>>>>>>>>>
>>>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>>>>>>>
>>>>>>>>>> No problem...
>>>>>>>>>>
>>>>>>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>>>>>>>
>>>>>>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>>>>>>>
>>>>>>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>>>>>>>
>>>>>>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>>>>>>>
>>>>>>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>>>>>>>
>>>>>>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>>>>>>>
>>>>>>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>>>>>>>
>>>>>>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Adolf.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>>>>>>>
>>>>>>>>>>> Minor points on the WUI.
>>>>>>>>>>
>>>>>>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>>>>>>>
>>>>>>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>>>>>>>
>>>>>>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>>>>>>>
>>>>>>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>>>>>>>
>>>>>>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>>>>>>>
>>>>>>>>>> -Michael
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> See the screenshots attached.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Adolf.
>>>>>>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>>>>>>>
>>>>
>>>> -- 
>>>> Sent from my laptop
>>
>> -- 
>> Sent from my laptop
> 
> 

Re: Feedback on WG

[Adolf Belka]

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

Hi Michael,

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

I have also found that the nmcli command line when creating a connection 
from scratch as opposed to importing it has the commands to name the 
interface and to name the connection so the two can be different.

Regards,
Adolf.


On 05/09/2024 11:27, Adolf Belka wrote:
> Hi Michael,
>
> On 30/08/2024 17:43, Michael Tremer wrote:
>> Hello,
>>
>>> On 29 Aug 2024, at 18:53, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi Michael,
>>>
>>> On 29/08/2024 15:53, Michael Tremer wrote:
>>>> Hello,
>>>>> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> On 29/08/2024 11:28, Michael Tremer wrote:
>>>>>> Hello,
>>>>>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> On 27/08/2024 12:19, Michael Tremer wrote:
>>>>>>>> Could you show me the route tables of both systems, please?
>>>>>>>
>>>>>>> The laptop has
>>>>>>> ip route
>>>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 
>>>>>>> 192.168.26.37 metric 600
>>>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 
>>>>>>> 192.168.26.37 metric 600
>>>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>>>>>>
>>>>>>> and the vm pc on the IPFire green lan has
>>>>>>> ip route
>>>>>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 
>>>>>>> 192.168.200.10 metric 1002
>>>>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 
>>>>>>> 192.168.200.10 metric 1002
>>>>>> So it looks like the routes for Wireguard are missing here.
>>>>>> Assuming that the interface is called wg0, there should be a 
>>>>>> route for your GREEN subnet on the laptop pointing at wg0.
>>>>>
>>>>> As I am having to import the wireguard conf file manually in the 
>>>>> command line, maybe I am also expected to set my own routes up on 
>>>>> my laptop but I am not sure what I should set the route command to.
>>>>>
>>>>> Normally I do an import of a VPN profile into Network Manager GUI 
>>>>> and it deals with everything but Network Manager cannot do this 
>>>>> via the GUI for Wireguard yet. So I had to just run
>>>>>
>>>>> nmcli connection import type wireguard file "$CONF_FILE"
>>>> NetworkManager should configure everything for you. That is its job 
>>>> in the end.
>>>> If you use the wg command to import the configuration, I don’t know 
>>>> whether it is creating routes or not. It could, but it might also 
>>>> just care about the tunnel and nothing else.
>>> I tried using wg-quick to import the config and it came back with:
>>>
>>> [#] ip link add tethysvmwg type wireguard
>>> [#] wg setconf tethysvmwg /dev/fd/63
>>> [#] ip -4 address add 10.120.50.1 dev tethysvmwg
>>> [#] ip link set mtu 1420 up dev tethysvmwg
>>> [#] resolvconf -a tethysvmwg -m 0 -x
>>> /usr/bin/wg-quick: line 32: resolvconf: command not found
>>> [#] ip link delete dev tethysvmwg
>>
>> Well, I assumed the interface would be called wg0, but it seems that 
>> the your distro decided to go with the easy to pronounce and really 
>> catchy name of “tethysvmwg”.
>
> That naming is nothing to do with the distro.
>
> When doing the import with the nmcli command Network Manager takes the 
> name of the config file, in my case tethysvmwg, and uses that name for 
> the interface. Whether that is what it should be doing I don't know.
>
> Maybe I will try renaming the config file to wg0 and then import it 
> and see what happens then.
>>
>>>
>>>>> where $CONF_FILE contains the path and name of the wireguard 
>>>>> config file that I downloaded from the IPFire Wireguard page.
>>>>>
>>>>> All the stuff I have read about routing with regard to Wireguard 
>>>>> is just a bit to complicated for me to understand what I am 
>>>>> supposed to do in my specific case.
>>>> You just need a route to the GREEN network on your firewall like so:
>>>>    ip route add 192.168.0.0/24 dev wg >
>>>> Assuming that your GREEN network is 192.168.0.0./24.
>>> If by green network you mean the green network on my IPFire vm 
>>> system then it came back and said
>>>
>>> Cannot find device "wg0"
>>>> What is “wg show wg0” giving you?
>>>
>>> That command came back with
>>>
>>> Unable to access interface: No such device
>>>
>>> so I ran ip address show and the wireguard interface on the laptop 
>>> is named tethysvmwg which is the name of the conf file I got from 
>>> IPFire because that was the connection name I used.
>>>
>>> So I then ran wg show tethysvmwg and it responded with
>>>
>>> sudo wg show tethysvmwg
>>> interface: tethysvmwg
>>>   public key: z48rDNDnbG5zH7yZWoY867FlqevmpfjktnlJAqdSIys=
>>>   private key: (hidden)
>>>   listening port: 59427
>>>
>>> peer: d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
>>>   preshared key: (hidden)
>>>   endpoint: 192.168.26.200:51820
>>>   allowed ips: 192.168.200.0/24
>>>   latest handshake: 1 minute, 39 seconds ago
>>>   transfer: 348 B received, 7.21 KiB sent
>>>   persistent keepalive: every 25 seconds
>>
>> So the tunnel is up.
>>
>>> I then ran sudo ip route add 192.168.200.0/24 dev tethysvmwg
>>>
>>> and ip route then showed
>>>
>>> ip route
>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 
>>> metric 600
>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 
>>> metric 600
>>> 192.168.200.0/24 dev tethysvmwg scope link
>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>
>> It looks like that route was already there then, but it seems that 
>> there might not be an IP address on the tethysvmwg interface? There 
>> should be one in the downloaded configuration file.
>
> Here is the content of the config file that was generated
>
> [Interface]
> PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Address = 10.120.50.1
> DNS = 192.168.200.254
>
> [Peer]
> Endpoint = ipfire.local.domain.org:51820
> PublicKey = d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
> PresharedKey = yyyyyyyyyyyyyyyyyyyyyyyyyy
> AllowedIPs = 192.168.200.0/24
> PersistentKeepalive = 25
>
> Maybe I didn't fill out the WG WUI page correctly.
>
>>
>> What IP address are you pinging from the firewall?
>
> It is the IP address of the laptop and that is 192.168.26.37
>
> Regards,
> Adolf.
>
>>
>>> but ping to a machine on the IPFire green network or to the IPFire 
>>> green interface itself still ends up with 100% packet loss.
>>
>> -Michael
>>
>>>
>>> Regards,
>>> Adolf.
>>>
>>>> -Michael
>>>>>
>>>>> If you can give some hints maybe, then I can have a go at getting 
>>>>> it to work.
>>>>>>> and the ipfire system has
>>>>>>> ip route
>>>>>>> default via 192.168.26.254 dev red0 proto dhcp src 
>>>>>>> 192.168.26.200 metric 1002
>>>>>>> 10.110.30.0/24 via 10.110.130.2 dev tun0
>>>>>>> 10.110.130.0/24 via 10.110.130.2 dev tun0
>>>>>>> 10.110.130.2 dev tun0 proto kernel scope link src 10.110.130.1
>>>>>>> 10.120.50.0/24 dev wg0 scope link
>>>>>> This is the opposite route.
>>>>>>> 10.120.50.2 dev tun1 proto kernel scope link src 10.120.50.1
>>>>>>> 192.168.26.0/24 dev red0 proto dhcp scope link src 
>>>>>>> 192.168.26.200 metric 1002
>>>>>>> 192.168.120.0/24 via 10.120.50.2 dev tun1
>>>>>>> 192.168.200.0/24 dev green0 proto kernel scope link src 
>>>>>>> 192.168.200.254
>>>>>>> 192.168.220.0/24 dev blue0 proto kernel scope link src 
>>>>>>> 192.168.220.254
>>>>>>> 192.168.240.0/24 dev orange0 proto kernel scope link src 
>>>>>>> 192.168.240.254
>>>>>> So I assume that from IPFire you can send packets to your laptop, 
>>>>>> but they don’t find their way back.
>>>>> I didn't try the ping from IPFire. I will do that and report back.
>>>>> I just tried the ping from a machine on the green lan of the 
>>>>> IPFire running the wireguard server.
>>>>>
>>>>> Regards,
>>>>> Adolf.
>>>>>
>>>>>> -Michael
>>>>>>> Regards,
>>>>>>> Adolf.
>>>>>>>> -Michael
>>>>>>>>> On 26 Aug 2024, at 13:13, Adolf Belka <adolf.belka(a)ipfire.org> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I tried out netcat to send some traffic through the tunnel. 
>>>>>>>>> That confirmed that the tunnel is only working in one direction.
>>>>>>>>>
>>>>>>>>> If I put the laptop in listening mode and from a vm on the 
>>>>>>>>> IPFire green lan sent some data from /dev/zero through the 
>>>>>>>>> tunnel, it was received at the other end.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Setting the vm on the IPFire green lan into listening mode and 
>>>>>>>>> sending the data from the laptop resulted in nothing being 
>>>>>>>>> sent from the laptop and obviously nothing received at the 
>>>>>>>>> green vm.
>>>>>>>>>
>>>>>>>>> So it is not just a ping issue.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Adolf.
>>>>>>>>>
>>>>>>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>>>>>>> Hi Michael,
>>>>>>>>>>
>>>>>>>>>> Getting back to testing out the WG.
>>>>>>>>>>
>>>>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>>>>>>> Hello Adolf,
>>>>>>>>>>>
>>>>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka 
>>>>>>>>>>>> <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Michael,
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was 
>>>>>>>>>>>> a bit tied up with DIY stuff in the house.
>>>>>>>>>>>
>>>>>>>>>>> No problem...
>>>>>>>>>>>
>>>>>>>>>>>> By manually importing the WG config file created I was able 
>>>>>>>>>>>> to successfully connect from my laptop to my IPFire vm 
>>>>>>>>>>>> system. The WUI showed connected. The config file had my 
>>>>>>>>>>>> allowed subnets set as 192.168.200.0/255.255.255.0 which is 
>>>>>>>>>>>> the green subnet on my vm system. However trying ping over 
>>>>>>>>>>>> the WG tunnel gave failures for the IP of the vm machine, 
>>>>>>>>>>>> green1, and also for the green interface of the vm IPFire.
>>>>>>>>>>>
>>>>>>>>>>> Okay, connecting should be nice and easy. However, you 
>>>>>>>>>>> *should* be able to transfer some data...
>>>>>>>>>>>
>>>>>>>>>>>> Trying to ping with the FQDN for the green1 system resulted 
>>>>>>>>>>>> in no resolving of green1's FQDN to a local IP but tried to 
>>>>>>>>>>>> send it to my main red interface with my ISP.
>>>>>>>>>>>
>>>>>>>>>>> Can you try to ping from either side? The client the 
>>>>>>>>>>> firewall and the firewall the client? That should work if 
>>>>>>>>>>> the tunnel is up.
>>>>>>>>>>
>>>>>>>>>> Tried again to ping from laptop to IPFire green lan, both the 
>>>>>>>>>> IPFire green interface and a vm PC on the green lan. In both 
>>>>>>>>>> cases 100% packet loss.
>>>>>>>>>>
>>>>>>>>>> I then tried doing the ping from the vm machine on the green 
>>>>>>>>>> IPFire lan to the laptop, as you suggested and in this case I 
>>>>>>>>>> got 100% packet transmission.
>>>>>>>>>>
>>>>>>>>>> In all above tests I used IP's to remove any question about 
>>>>>>>>>> DNS resolving.
>>>>>>>>>>
>>>>>>>>>> So the ping seems to only be working in one direction. Let me 
>>>>>>>>>> know if there are any other tests or checks I should do based 
>>>>>>>>>> on this result.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Adolf.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> So something appears to be missing or incorrect with the 
>>>>>>>>>>>> routing but not sure what.
>>>>>>>>>>>>
>>>>>>>>>>>> Minor points on the WUI.
>>>>>>>>>>>
>>>>>>>>>>> I would like to have the thing working first before we spend 
>>>>>>>>>>> any time on making the UI look nice, but you are raising 
>>>>>>>>>>> very good points.
>>>>>>>>>>>
>>>>>>>>>>>> When disconnected the status section that is coloured red 
>>>>>>>>>>>> is huge and the space for the remark is very small but when 
>>>>>>>>>>>> connected then the status space is large enough to have the 
>>>>>>>>>>>> connected status word, giving much more room for the remark.
>>>>>>>>>>>
>>>>>>>>>>> That should not be. No idea why that is, but I am sure that 
>>>>>>>>>>> is not too hard to fix.
>>>>>>>>>>>
>>>>>>>>>>>> When the WG config file is created and you have the page 
>>>>>>>>>>>> with the QR code, there is also a message about the WG 
>>>>>>>>>>>> config file only being shown this one time as it contains 
>>>>>>>>>>>> private key material. The message is fine but the heading 
>>>>>>>>>>>> for the message is "Oops, something went wrong...". It 
>>>>>>>>>>>> should really be something like "Information Note" or 
>>>>>>>>>>>> equivalent as it is not an actual error message.
>>>>>>>>>>>
>>>>>>>>>>> I think I created a little widget which I used somewhere 
>>>>>>>>>>> else too and then added the headline. It certainly does not 
>>>>>>>>>>> fit here.
>>>>>>>>>>>
>>>>>>>>>>> -Michael
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> See the screenshots attached.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Adolf.
>>>>>>>>>>>> <Disconnected WUI screen.png><Connected WUI 
>>>>>>>>>>>> screen.png><Error message when WG config file provided..png>
>>>>>>>>>>>
>>>>>
>>>>> -- 
>>>>> Sent from my laptop
>>>
>>> -- 
>>> Sent from my laptop
>>
>>

-- 
Sent from my laptop

Re: Feedback on WG

[Michael Tremer]

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

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(a)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(a)ipfire.org> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>> On 29/08/2024 15:53, Michael Tremer wrote:
>>>>> Hello,
>>>>>> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>> 
>>>>>> Hi Michael,
>>>>>> 
>>>>>> On 29/08/2024 11:28, Michael Tremer wrote:
>>>>>>> Hello,
>>>>>>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>> 
>>>>>>>> Hi Michael,
>>>>>>>> 
>>>>>>>> On 27/08/2024 12:19, Michael Tremer wrote:
>>>>>>>>> Could you show me the route tables of both systems, please?
>>>>>>>> 
>>>>>>>> The laptop has
>>>>>>>> ip route
>>>>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>>>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>>>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>>>>>>> 
>>>>>>>> and the vm pc on the IPFire green lan has
>>>>>>>> ip route
>>>>>>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
>>>>>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002
>>>>>>> So it looks like the routes for Wireguard are missing here.
>>>>>>> Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.
>>>>>> 
>>>>>> As I am having to import the wireguard conf file manually in the command line, maybe I am also expected to set my own routes up on my laptop but I am not sure what I should set the route command to.
>>>>>> 
>>>>>> Normally I do an import of a VPN profile into Network Manager GUI and it deals with everything but Network Manager cannot do this via the GUI for Wireguard yet. So I had to just run
>>>>>> 
>>>>>> nmcli connection import type wireguard file "$CONF_FILE"
>>>>> NetworkManager should configure everything for you. That is its job in the end.
>>>>> If you use the wg command to import the configuration, I don’t know whether it is creating routes or not. It could, but it might also just care about the tunnel and nothing else.
>>>> I tried using wg-quick to import the config and it came back with:
>>>> 
>>>> [#] ip link add tethysvmwg type wireguard
>>>> [#] wg setconf tethysvmwg /dev/fd/63
>>>> [#] ip -4 address add 10.120.50.1 dev tethysvmwg
>>>> [#] ip link set mtu 1420 up dev tethysvmwg
>>>> [#] resolvconf -a tethysvmwg -m 0 -x
>>>> /usr/bin/wg-quick: line 32: resolvconf: command not found
>>>> [#] ip link delete dev tethysvmwg
>>> 
>>> Well, I assumed the interface would be called wg0, but it seems that the your distro decided to go with the easy to pronounce and really catchy name of “tethysvmwg”.
>> 
>> That naming is nothing to do with the distro.
>> 
>> When doing the import with the nmcli command Network Manager takes the name of the config file, in my case tethysvmwg, and uses that name for the interface. Whether that is what it should be doing I don't know.
>> 
>> Maybe I will try renaming the config file to wg0 and then import it and see what happens then.
>>> 
>>>> 
>>>>>> where $CONF_FILE contains the path and name of the wireguard config file that I downloaded from the IPFire Wireguard page.
>>>>>> 
>>>>>> All the stuff I have read about routing with regard to Wireguard is just a bit to complicated for me to understand what I am supposed to do in my specific case.
>>>>> You just need a route to the GREEN network on your firewall like so:
>>>>>    ip route add 192.168.0.0/24 dev wg >
>>>>> Assuming that your GREEN network is 192.168.0.0./24.
>>>> If by green network you mean the green network on my IPFire vm system then it came back and said
>>>> 
>>>> Cannot find device "wg0"
>>>>> What is “wg show wg0” giving you?
>>>> 
>>>> That command came back with
>>>> 
>>>> Unable to access interface: No such device
>>>> 
>>>> so I ran ip address show and the wireguard interface on the laptop is named tethysvmwg which is the name of the conf file I got from IPFire because that was the connection name I used.
>>>> 
>>>> So I then ran wg show tethysvmwg and it responded with
>>>> 
>>>> sudo wg show tethysvmwg
>>>> interface: tethysvmwg
>>>>   public key: z48rDNDnbG5zH7yZWoY867FlqevmpfjktnlJAqdSIys=
>>>>   private key: (hidden)
>>>>   listening port: 59427
>>>> 
>>>> peer: d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
>>>>   preshared key: (hidden)
>>>>   endpoint: 192.168.26.200:51820
>>>>   allowed ips: 192.168.200.0/24
>>>>   latest handshake: 1 minute, 39 seconds ago
>>>>   transfer: 348 B received, 7.21 KiB sent
>>>>   persistent keepalive: every 25 seconds
>>> 
>>> So the tunnel is up.
>>> 
>>>> I then ran sudo ip route add 192.168.200.0/24 dev tethysvmwg
>>>> 
>>>> and ip route then showed
>>>> 
>>>> ip route
>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>>> 192.168.200.0/24 dev tethysvmwg scope link
>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>> 
>>> It looks like that route was already there then, but it seems that there might not be an IP address on the tethysvmwg interface? There should be one in the downloaded configuration file.
>> 
>> Here is the content of the config file that was generated
>> 
>> [Interface]
>> PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Address = 10.120.50.1
>> DNS = 192.168.200.254
>> 
>> [Peer]
>> Endpoint = ipfire.local.domain.org:51820
>> PublicKey = d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
>> PresharedKey = yyyyyyyyyyyyyyyyyyyyyyyyyy
>> AllowedIPs = 192.168.200.0/24
>> PersistentKeepalive = 25
>> 
>> Maybe I didn't fill out the WG WUI page correctly.
>> 
>>> 
>>> What IP address are you pinging from the firewall?
>> 
>> It is the IP address of the laptop and that is 192.168.26.37
>> 
>> Regards,
>> Adolf.
>> 
>>> 
>>>> but ping to a machine on the IPFire green network or to the IPFire green interface itself still ends up with 100% packet loss.
>>> 
>>> -Michael
>>> 
>>>> 
>>>> Regards,
>>>> Adolf.
>>>> 
>>>>> -Michael
>>>>>> 
>>>>>> If you can give some hints maybe, then I can have a go at getting it to work.
>>>>>>>> and the ipfire system has
>>>>>>>> ip route
>>>>>>>> default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 metric 1002
>>>>>>>> 10.110.30.0/24 via 10.110.130.2 dev tun0
>>>>>>>> 10.110.130.0/24 via 10.110.130.2 dev tun0
>>>>>>>> 10.110.130.2 dev tun0 proto kernel scope link src 10.110.130.1
>>>>>>>> 10.120.50.0/24 dev wg0 scope link
>>>>>>> This is the opposite route.
>>>>>>>> 10.120.50.2 dev tun1 proto kernel scope link src 10.120.50.1
>>>>>>>> 192.168.26.0/24 dev red0 proto dhcp scope link src 192.168.26.200 metric 1002
>>>>>>>> 192.168.120.0/24 via 10.120.50.2 dev tun1
>>>>>>>> 192.168.200.0/24 dev green0 proto kernel scope link src 192.168.200.254
>>>>>>>> 192.168.220.0/24 dev blue0 proto kernel scope link src 192.168.220.254
>>>>>>>> 192.168.240.0/24 dev orange0 proto kernel scope link src 192.168.240.254
>>>>>>> So I assume that from IPFire you can send packets to your laptop, but they don’t find their way back.
>>>>>> I didn't try the ping from IPFire. I will do that and report back.
>>>>>> I just tried the ping from a machine on the green lan of the IPFire running the wireguard server.
>>>>>> 
>>>>>> Regards,
>>>>>> Adolf.
>>>>>> 
>>>>>>> -Michael
>>>>>>>> Regards,
>>>>>>>> Adolf.
>>>>>>>>> -Michael
>>>>>>>>>> On 26 Aug 2024, at 13:13, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>> 
>>>>>>>>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>>>>>>>>> 
>>>>>>>>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>>>>>>>>> 
>>>>>>>>>> So it is not just a ping issue.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> 
>>>>>>>>>> Adolf.
>>>>>>>>>> 
>>>>>>>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>>>>>>>> Hi Michael,
>>>>>>>>>>> 
>>>>>>>>>>> Getting back to testing out the WG.
>>>>>>>>>>> 
>>>>>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>>>>>>>> Hello Adolf,
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Michael,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>>>>>>>>> 
>>>>>>>>>>>> No problem...
>>>>>>>>>>>> 
>>>>>>>>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>>>>>>>>> 
>>>>>>>>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>>>>>>>>> 
>>>>>>>>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>>>>>>>>> 
>>>>>>>>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>>>>>>>>> 
>>>>>>>>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>>>>>>>>> 
>>>>>>>>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>>>>>>>>> 
>>>>>>>>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>>>>>>>>> 
>>>>>>>>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>>>>>>>>> 
>>>>>>>>>>> Regards,
>>>>>>>>>>> Adolf.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Minor points on the WUI.
>>>>>>>>>>>> 
>>>>>>>>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>>>>>>>>> 
>>>>>>>>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>>>>>>>>> 
>>>>>>>>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>>>>>>>>> 
>>>>>>>>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>>>>>>>>> 
>>>>>>>>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>>>>>>>>> 
>>>>>>>>>>>> -Michael
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> See the screenshots attached.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Adolf.
>>>>>>>>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>>>>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Sent from my laptop
>>>> 
>>>> -- 
>>>> Sent from my laptop
>>> 
>>> 
> 
> -- 
> Sent from my laptop
> 

Re: Feedback on WG

[Adolf Belka]

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

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(a)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(a)ipfire.org> wrote:
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> On 29/08/2024 15:53, Michael Tremer wrote:
>>>>>> Hello,
>>>>>>> On 29 Aug 2024, at 14:36, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> On 29/08/2024 11:28, Michael Tremer wrote:
>>>>>>>> Hello,
>>>>>>>>> On 27 Aug 2024, at 13:09, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>
>>>>>>>>> Hi Michael,
>>>>>>>>>
>>>>>>>>> On 27/08/2024 12:19, Michael Tremer wrote:
>>>>>>>>>> Could you show me the route tables of both systems, please?
>>>>>>>>>
>>>>>>>>> The laptop has
>>>>>>>>> ip route
>>>>>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>>>>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>>>>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>>>>>>>>
>>>>>>>>> and the vm pc on the IPFire green lan has
>>>>>>>>> ip route
>>>>>>>>> default via 192.168.200.254 dev enp0s3 proto dhcp src 192.168.200.10 metric 1002
>>>>>>>>> 192.168.200.0/24 dev enp0s3 proto dhcp scope link src 192.168.200.10 metric 1002
>>>>>>>> So it looks like the routes for Wireguard are missing here.
>>>>>>>> Assuming that the interface is called wg0, there should be a route for your GREEN subnet on the laptop pointing at wg0.
>>>>>>>
>>>>>>> As I am having to import the wireguard conf file manually in the command line, maybe I am also expected to set my own routes up on my laptop but I am not sure what I should set the route command to.
>>>>>>>
>>>>>>> Normally I do an import of a VPN profile into Network Manager GUI and it deals with everything but Network Manager cannot do this via the GUI for Wireguard yet. So I had to just run
>>>>>>>
>>>>>>> nmcli connection import type wireguard file "$CONF_FILE"
>>>>>> NetworkManager should configure everything for you. That is its job in the end.
>>>>>> If you use the wg command to import the configuration, I don’t know whether it is creating routes or not. It could, but it might also just care about the tunnel and nothing else.
>>>>> I tried using wg-quick to import the config and it came back with:
>>>>>
>>>>> [#] ip link add tethysvmwg type wireguard
>>>>> [#] wg setconf tethysvmwg /dev/fd/63
>>>>> [#] ip -4 address add 10.120.50.1 dev tethysvmwg
>>>>> [#] ip link set mtu 1420 up dev tethysvmwg
>>>>> [#] resolvconf -a tethysvmwg -m 0 -x
>>>>> /usr/bin/wg-quick: line 32: resolvconf: command not found
>>>>> [#] ip link delete dev tethysvmwg
>>>>
>>>> Well, I assumed the interface would be called wg0, but it seems that the your distro decided to go with the easy to pronounce and really catchy name of “tethysvmwg”.
>>>
>>> That naming is nothing to do with the distro.
>>>
>>> When doing the import with the nmcli command Network Manager takes the name of the config file, in my case tethysvmwg, and uses that name for the interface. Whether that is what it should be doing I don't know.
>>>
>>> Maybe I will try renaming the config file to wg0 and then import it and see what happens then.
>>>>
>>>>>
>>>>>>> where $CONF_FILE contains the path and name of the wireguard config file that I downloaded from the IPFire Wireguard page.
>>>>>>>
>>>>>>> All the stuff I have read about routing with regard to Wireguard is just a bit to complicated for me to understand what I am supposed to do in my specific case.
>>>>>> You just need a route to the GREEN network on your firewall like so:
>>>>>>     ip route add 192.168.0.0/24 dev wg >
>>>>>> Assuming that your GREEN network is 192.168.0.0./24.
>>>>> If by green network you mean the green network on my IPFire vm system then it came back and said
>>>>>
>>>>> Cannot find device "wg0"
>>>>>> What is “wg show wg0” giving you?
>>>>>
>>>>> That command came back with
>>>>>
>>>>> Unable to access interface: No such device
>>>>>
>>>>> so I ran ip address show and the wireguard interface on the laptop is named tethysvmwg which is the name of the conf file I got from IPFire because that was the connection name I used.
>>>>>
>>>>> So I then ran wg show tethysvmwg and it responded with
>>>>>
>>>>> sudo wg show tethysvmwg
>>>>> interface: tethysvmwg
>>>>>    public key: z48rDNDnbG5zH7yZWoY867FlqevmpfjktnlJAqdSIys=
>>>>>    private key: (hidden)
>>>>>    listening port: 59427
>>>>>
>>>>> peer: d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
>>>>>    preshared key: (hidden)
>>>>>    endpoint: 192.168.26.200:51820
>>>>>    allowed ips: 192.168.200.0/24
>>>>>    latest handshake: 1 minute, 39 seconds ago
>>>>>    transfer: 348 B received, 7.21 KiB sent
>>>>>    persistent keepalive: every 25 seconds
>>>>
>>>> So the tunnel is up.
>>>>
>>>>> I then ran sudo ip route add 192.168.200.0/24 dev tethysvmwg
>>>>>
>>>>> and ip route then showed
>>>>>
>>>>> ip route
>>>>> default via 192.168.26.254 dev wlp2s0 proto dhcp src 192.168.26.37 metric 600
>>>>> 192.168.26.0/24 dev wlp2s0 proto kernel scope link src 192.168.26.37 metric 600
>>>>> 192.168.200.0/24 dev tethysvmwg scope link
>>>>> 192.168.200.0/24 dev tethysvmwg proto static scope link metric 50
>>>>
>>>> It looks like that route was already there then, but it seems that there might not be an IP address on the tethysvmwg interface? There should be one in the downloaded configuration file.
>>>
>>> Here is the content of the config file that was generated
>>>
>>> [Interface]
>>> PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>> Address = 10.120.50.1
>>> DNS = 192.168.200.254
>>>
>>> [Peer]
>>> Endpoint = ipfire.local.domain.org:51820
>>> PublicKey = d1K8s4kPc8W0OybR9BnAD2IKUdfXVdyKlyuQf+UuPj4=
>>> PresharedKey = yyyyyyyyyyyyyyyyyyyyyyyyyy
>>> AllowedIPs = 192.168.200.0/24
>>> PersistentKeepalive = 25
>>>
>>> Maybe I didn't fill out the WG WUI page correctly.
>>>
>>>>
>>>> What IP address are you pinging from the firewall?
>>>
>>> It is the IP address of the laptop and that is 192.168.26.37
>>>
>>> Regards,
>>> Adolf.
>>>
>>>>
>>>>> but ping to a machine on the IPFire green network or to the IPFire green interface itself still ends up with 100% packet loss.
>>>>
>>>> -Michael
>>>>
>>>>>
>>>>> Regards,
>>>>> Adolf.
>>>>>
>>>>>> -Michael
>>>>>>>
>>>>>>> If you can give some hints maybe, then I can have a go at getting it to work.
>>>>>>>>> and the ipfire system has
>>>>>>>>> ip route
>>>>>>>>> default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 metric 1002
>>>>>>>>> 10.110.30.0/24 via 10.110.130.2 dev tun0
>>>>>>>>> 10.110.130.0/24 via 10.110.130.2 dev tun0
>>>>>>>>> 10.110.130.2 dev tun0 proto kernel scope link src 10.110.130.1
>>>>>>>>> 10.120.50.0/24 dev wg0 scope link
>>>>>>>> This is the opposite route.
>>>>>>>>> 10.120.50.2 dev tun1 proto kernel scope link src 10.120.50.1
>>>>>>>>> 192.168.26.0/24 dev red0 proto dhcp scope link src 192.168.26.200 metric 1002
>>>>>>>>> 192.168.120.0/24 via 10.120.50.2 dev tun1
>>>>>>>>> 192.168.200.0/24 dev green0 proto kernel scope link src 192.168.200.254
>>>>>>>>> 192.168.220.0/24 dev blue0 proto kernel scope link src 192.168.220.254
>>>>>>>>> 192.168.240.0/24 dev orange0 proto kernel scope link src 192.168.240.254
>>>>>>>> So I assume that from IPFire you can send packets to your laptop, but they don’t find their way back.
>>>>>>> I didn't try the ping from IPFire. I will do that and report back.
>>>>>>> I just tried the ping from a machine on the green lan of the IPFire running the wireguard server.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Adolf.
>>>>>>>
>>>>>>>> -Michael
>>>>>>>>> Regards,
>>>>>>>>> Adolf.
>>>>>>>>>> -Michael
>>>>>>>>>>> On 26 Aug 2024, at 13:13, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I tried out netcat to send some traffic through the tunnel. That confirmed that the tunnel is only working in one direction.
>>>>>>>>>>>
>>>>>>>>>>> If I put the laptop in listening mode and from a vm on the IPFire green lan sent some data from /dev/zero through the tunnel, it was received at the other end.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Setting the vm on the IPFire green lan into listening mode and sending the data from the laptop resulted in nothing being sent from the laptop and obviously nothing received at the green vm.
>>>>>>>>>>>
>>>>>>>>>>> So it is not just a ping issue.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Adolf.
>>>>>>>>>>>
>>>>>>>>>>> On 26/08/2024 13:17, Adolf Belka wrote:
>>>>>>>>>>>> Hi Michael,
>>>>>>>>>>>>
>>>>>>>>>>>> Getting back to testing out the WG.
>>>>>>>>>>>>
>>>>>>>>>>>> On 21/08/2024 16:23, Michael Tremer wrote:
>>>>>>>>>>>>> Hello Adolf,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 19 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Michael,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No problem...
>>>>>>>>>>>>>
>>>>>>>>>>>>>> By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Okay, connecting should be nice and easy. However, you *should* be able to transfer some data...
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you try to ping from either side? The client the firewall and the firewall the client? That should work if the tunnel is up.
>>>>>>>>>>>>
>>>>>>>>>>>> Tried again to ping from laptop to IPFire green lan, both the IPFire green interface and a vm PC on the green lan. In both cases 100% packet loss.
>>>>>>>>>>>>
>>>>>>>>>>>> I then tried doing the ping from the vm machine on the green IPFire lan to the laptop, as you suggested and in this case I got 100% packet transmission.
>>>>>>>>>>>>
>>>>>>>>>>>> In all above tests I used IP's to remove any question about DNS resolving.
>>>>>>>>>>>>
>>>>>>>>>>>> So the ping seems to only be working in one direction. Let me know if there are any other tests or checks I should do based on this result.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Adolf.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So something appears to be missing or incorrect with the routing but not sure what.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Minor points on the WUI.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to have the thing working first before we spend any time on making the UI look nice, but you are raising very good points.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That should not be. No idea why that is, but I am sure that is not too hard to fix.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I created a little widget which I used somewhere else too and then added the headline. It certainly does not fit here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Michael
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See the screenshots attached.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adolf.
>>>>>>>>>>>>>> <Disconnected WUI screen.png><Connected WUI screen.png><Error message when WG config file provided..png>
>>>>>>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Sent from my laptop
>>>>>
>>>>> -- 
>>>>> Sent from my laptop
>>>>
>>>>
>>
>> -- 
>> Sent from my laptop
>>
> 

-- 
Sent from my laptop